[FR] Implement fixes for misconfigurations in user skaffold.yaml #6102
Labels
area/init
area/onboarding
kind/feature-request
kind/todo
implementation task/epic for the skaffold team
planning/Q4-21
Q4 2021 planning
priority/p2
May take a couple of releases
Milestone
Comments
aaron-prindle
added
kind/todo
aaron-prindle
added
area/init
kind/feature-request
priority/p1
aaron-prindle
changed the title
|
After talking to Vic, Few recommendations:
|
aaron-prindle
added a commit
to aaron-prindle/skaffold
that referenced
this issue
Oct 13, 2021
…aml support What is the problem being solved? Part of GoogleContainerTools#6102, adding lint/recommendations for skaffold.yaml files. This PR adds some basic libraries to support linting including: - Basic types for lint logic including: Linter, Rule, & Results (among otherse) - Linter implementations - RegExpLinter & YamlFieldLinter - hidden 'skaffold lint' CLI command plumbed through for skaffold.yaml linting - 'skaffold lint' output formatter supporting json and plain-text Why is this the best approach? This approach is the best approach as it uses the straightforward concept of Linters along with the required parsing approach that yield line numbers for recommendations (regexp and kyaml yaml parsing support line numbers of results). Linters + Lint Rules are a common approach for lint recommendations and the types are extensible to fit many possible rules. The plain-text output format uses golangci-lint as inspiration and is similar in structure. More about this approach can be found at go/skaffold-lint. What other approaches did you consider? For the yaml linting/validation, this is done elsewhere in the code by parsing the skaffold.yaml into SkaffoldConfig structs (from the schema) and introspecting the struct. This will not work for the lint case though as line numbers for fields/values are not stored when decoding. As such, kyaml is required. What side effects will this approach have? There shouldn't be any side effects as the 'skaffold lint' command logic here is "hidden" to users and as such won't be easily discoverable for most users. What future work remains to be done? Future work includes: - adding more lint rules for skaffold.yaml linting - adding support for Dockerfile and k8s manifest linting - adding more complex "Analyzers" to allow for lint rules to introspect more complex skaffold state (eg: build graph, build times, etc.)
aaron-prindle
added a commit
to aaron-prindle/skaffold
that referenced
this issue
Oct 13, 2021
…aml support What is the problem being solved? Part of GoogleContainerTools#6102, adding lint/recommendations for skaffold.yaml files. This PR adds some basic libraries to support linting including: - Basic types for lint logic including: Linter, Rule, & Results (among otherse) - Linter implementations - RegExpLinter & YamlFieldLinter - hidden 'skaffold lint' CLI command plumbed through for skaffold.yaml linting - 'skaffold lint' output formatter supporting json and plain-text Why is this the best approach? This approach is the best approach as it uses the straightforward concept of Linters along with the required parsing approach that yield line numbers for recommendations (regexp and kyaml yaml parsing support line numbers of results). Linters + Lint Rules are a common approach for lint recommendations and the types are extensible to fit many possible rules. The plain-text output format uses golangci-lint as inspiration and is similar in structure. More about this approach can be found at go/skaffold-lint. What other approaches did you consider? For the yaml linting/validation, this is done elsewhere in the code by parsing the skaffold.yaml into SkaffoldConfig structs (from the schema) and introspecting the struct. This will not work for the lint case though as line numbers for fields/values are not stored when decoding. As such, kyaml is required. What side effects will this approach have? There shouldn't be any side effects as the 'skaffold lint' command logic here is "hidden" to users and as such won't be easily discoverable for most users. What future work remains to be done? Future work includes: - adding more lint rules for skaffold.yaml linting - adding support for Dockerfile and k8s manifest linting - adding more complex "Analyzers" to allow for lint rules to introspect more complex skaffold state (eg: build graph, build times, etc.)
aaron-prindle
added a commit
to aaron-prindle/skaffold
that referenced
this issue
Oct 13, 2021
…aml support What is the problem being solved? Part of GoogleContainerTools#6102, adding lint/recommendations for skaffold.yaml files. This PR adds some basic libraries to support linting including: - Basic types for lint logic including: Linter, Rule, & Results (among otherse) - Linter implementations - RegExpLinter & YamlFieldLinter - hidden 'skaffold lint' CLI command plumbed through for skaffold.yaml linting - 'skaffold lint' output formatter supporting json and plain-text Why is this the best approach? This approach is the best approach as it uses the straightforward concept of Linters along with the required parsing approach that yield line numbers for recommendations (regexp and kyaml yaml parsing support line numbers of results). Linters + Lint Rules are a common approach for lint recommendations and the types are extensible to fit many possible rules. The plain-text output format uses golangci-lint as inspiration and is similar in structure. More about this approach can be found at go/skaffold-lint. What other approaches did you consider? For the yaml linting/validation, this is done elsewhere in the code by parsing the skaffold.yaml into SkaffoldConfig structs (from the schema) and introspecting the struct. This will not work for the lint case though as line numbers for fields/values are not stored when decoding. As such, kyaml is required. What side effects will this approach have? There shouldn't be any side effects as the 'skaffold lint' command logic here is "hidden" to users and as such won't be easily discoverable for most users. What future work remains to be done? Future work includes: - adding more lint rules for skaffold.yaml linting - adding support for Dockerfile and k8s manifest linting - adding more complex "Analyzers" to allow for lint rules to introspect more complex skaffold state (eg: build graph, build times, etc.) - documentation for the `skaffold lint` command
aaron-prindle
added a commit
to aaron-prindle/skaffold
that referenced
this issue
Oct 13, 2021
…aml support What is the problem being solved? Part of GoogleContainerTools#6102, adding lint/recommendations for skaffold.yaml files. This PR adds some basic libraries to support linting including: - Basic types for lint logic including: Linter, Rule, & Results (among otherse) - Linter implementations - RegExpLinter & YamlFieldLinter - hidden 'skaffold lint' CLI command plumbed through for skaffold.yaml linting - 'skaffold lint' output formatter supporting json and plain-text Why is this the best approach? This approach is the best approach as it uses the straightforward concept of Linters along with the required parsing approach that yield line numbers for recommendations (regexp and kyaml yaml parsing support line numbers of results). Linters + Lint Rules are a common approach for lint recommendations and the types are extensible to fit many possible rules. The plain-text output format uses golangci-lint as inspiration and is similar in structure. More about this approach can be found at go/skaffold-lint. What other approaches did you consider? For the yaml linting/validation, this is done elsewhere in the code by parsing the skaffold.yaml into SkaffoldConfig structs (from the schema) and introspecting the struct. This will not work for the lint case though as line numbers for fields/values are not stored when decoding. As such, kyaml is required. What side effects will this approach have? There shouldn't be any side effects as the 'skaffold lint' command logic here is "hidden" to users and as such won't be easily discoverable for most users. What future work remains to be done? Future work includes: - adding more lint rules for skaffold.yaml linting - adding support for Dockerfile and k8s manifest linting - adding more complex "Analyzers" to allow for lint rules to introspect more complex skaffold state (eg: build graph, build times, etc.) - documentation for the `skaffold lint` command
aaron-prindle
added a commit
to aaron-prindle/skaffold
that referenced
this issue
Oct 13, 2021
…aml support What is the problem being solved? Part of GoogleContainerTools#6102, adding lint/recommendations for skaffold.yaml files. This PR adds some basic libraries to support linting including: - Basic types for lint logic including: Linter, Rule, & Results (among otherse) - Linter implementations - RegExpLinter & YamlFieldLinter - hidden 'skaffold lint' CLI command plumbed through for skaffold.yaml linting - 'skaffold lint' output formatter supporting json and plain-text Why is this the best approach? This approach is the best approach as it uses the straightforward concept of Linters along with the required parsing approach that yield line numbers for recommendations (regexp and kyaml yaml parsing support line numbers of results). Linters + Lint Rules are a common approach for lint recommendations and the types are extensible to fit many possible rules. The plain-text output format uses golangci-lint as inspiration and is similar in structure. More about this approach can be found at go/skaffold-lint. What other approaches did you consider? For the yaml linting/validation, this is done elsewhere in the code by parsing the skaffold.yaml into SkaffoldConfig structs (from the schema) and introspecting the struct. This will not work for the lint case though as line numbers for fields/values are not stored when decoding. As such, kyaml is required. What side effects will this approach have? There shouldn't be any side effects as the 'skaffold lint' command logic here is "hidden" to users and as such won't be easily discoverable for most users. What future work remains to be done? Future work includes: - adding more lint rules for skaffold.yaml linting - adding support for Dockerfile and k8s manifest linting - adding more complex "Analyzers" to allow for lint rules to introspect more complex skaffold state (eg: build graph, build times, etc.) - documentation for the `skaffold lint` command
tejal29
added
priority/p2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Implement top 2 recommendations for misconfigurations in their skaffold.yaml
The text was updated successfully, but these errors were encountered: