-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(linting): Add support for linting decK files #981
Conversation
5823a9b
to
8540606
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work!
I added a few suggestions and requests in the code. On top of those, can you please make sure to rebase on top of main
and also add some basic test? Something like this should be relatively easy to replicate.
cmd/file_lint.go
Outdated
) | ||
|
||
var ( | ||
cmdLintInputFilename string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These 2 variables are never used.
Also, not passing a statefile and using -
as default doesn't work:
$ ./deck file lint - --ruleset ruleset.yaml
panic: open -: no such file or directory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not clear what lint-file
is in the usage, so this usage appears undefined to me. If we want to allow positional arguments, it seems we need to decide if that is the input state file(s) or the rules file(s). Can the underlying library support multiple rules files? It may make sense to allow a single input state file via -s,--state
and multiple rules files as the positional arguments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can the underlying library support multiple rules files?
The library gets a single input, so it's a matter of implementing the logic in decK to merge the rulesets.
It may make sense to just support a single state file and a single ruleset for starters. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t see a use case for supporting multiple at this point. Users can run the tool multiple times, or use the merge function to generate a single input
cmd/file_lint.go
Outdated
Long: `Long description Here`, | ||
RunE: executeLint, | ||
Short: "Lint a file against a ruleset", | ||
Long: "Lint a file against a ruleset. \n" + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mheap @rspurgeon can you please validate these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still not sure what lint-file
represents in this usage. I think we're using flags for both the state file and the rules file, so what is lint-file
?
As far as help text:
Long: "Lint a file against a ruleset. \n" + | |
Long: "Validate a decK state file against a linting ruleset, reporting any violations or failures. Report output can be returned in JSON, YAML, or human readable format (see --format). \n" + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also think it's important we document the --fail-severity
flag and how it affects the return code of the command. I assume that users of this will want to branch behaviors based on command return code. I think we should provide details here. I would make a suggestion, but I'm not sure at this point how the code works in that regard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion!
Fixed this. 3bdd2fe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would make a suggestion, but I'm not sure at this point how the code works in that regard.
Basically --fail-severity
will gate what returns a non-zero (1) exit code. Feel free to make a suggestion.
Also, is --display-only-failures
expected to care about error
only or it should adapt to the --fail-severity
value? If the --display-only-failures
flag should care only about error
I suggest we change it to --display-only-errors
.
Thoughts? @rspurgeon @mheap
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
--fail-severity
and --display-only-failures
are taken from Spectral, which is the defacto implementation of linting https://docs.stoplight.io/docs/spectral/9ffa04e052cc1-spectral-cli
We should adapt to the --fail-severity
value
From Spectral:
-D, --display-only-failures only output results equal to or greater than --fail-severity [boolean] [default: false]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just adopt what the spectral CLI supports directly? Can we update our usage to be:
-F, --fail-severity results of this level or above will trigger a failure exit code
[string] [choices: "error", "warn", "info", "hint"] [default: "error"]
-D, --display-only-failures only output results equal to or greater than --fail-severity [boolean] [default: false]
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #981 +/- ##
==========================================
- Coverage 33.50% 33.18% -0.33%
==========================================
Files 101 102 +1
Lines 12460 12582 +122
==========================================
Hits 4175 4175
- Misses 7878 8000 +122
Partials 407 407
☔ View full report in Codecov by Sentry. |
Should we output the severity in plaintext mode? It is provided in JSON or YAML format and I think is helpful for adjusting the rules or severity threshold.
Maybe something like:
|
@rspurgeon I think I addressed both your latest comments. Let me know! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, impressive work @mheap and @GGabriele
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. @mheap Do we plan on creating docs for this new feature and give some guidance to users (or even create a few real world examples)?
As discussed with @Tieske , I'd prefer we hold this for a new release version instead of merging into a revision release. We want to bundle this with other APIops related features that are slated for completion the coming weeks. Part of that work includes public docs, blog announcement, etc... |
added a commit to line up the cli args with the other commands. Please review the last commit. |
@rspurgeon this no longer holds right? we can merge once approved? |
Yes, thank you... We are clear to ship incremental (non-breaking) features in minor releases. We should provide sufficient documentation both in product and on public docs site before merging, however. |
Adds support for linting declarative configurations.
Example usage:
You can control what's considered an error:
Or only show errors:
It supports JSON and YAML output in addition to a human readable default:
Tested with the following input files:
Usage:
Jira: APIOPS-53
edit: added jira link