-
Notifications
You must be signed in to change notification settings - Fork 266
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
Consider changing truthy
linter's check-keys
default
#559
Comments
No; those all assume that the behavior is a bug needing to be fixed. I understand that it is not a bug, but an option which is enabled by default. My question is: would it make sense to change that default? The numerous issues filed on this subject are strong evidence that the default is confusing. If changing the default is disagreeable, what do you think about the |
I was thinking to suggest using a Switching to |
I think this is very reasonable, either disable check-keys or disable it for files inside of .github/workflows |
TL;DR: For those seeking a quick-win to silent the error on GitHub Actions, here are 4 solutions:
I understand, but changing a default configuration in yamllint would break behavior in processes (e.g. continuous integration) for many users and companies. It is not an option to consider.
This is interesting. But if I understand correctly, your proposition would produce extra "human-friendly" output amongst yamllint regular output (which has a constant pattern). I fear that this also would break tools relying on yamllint's output. |
I'd say we should rather lobby Github to update their workflows, to one of: Suggesting a quoted 'on' or (even better) always interpret the workflow files as YAML 1.1 (maybe that's already what they're doing). A temporary option for yamllint users: # .yamllint
# don't use YAML's yes/no as boolean values (common cause of bugs)
truthy:
level: error
# github action workflows use the key 'on' without quotes
ignore: |
.github/workflows/*.yml |
Specification of YAML ≤ 1.1 has 18 boolean values: true | True | TRUE | false | False | FALSE yes | Yes | YES | no | No | NO on | On | ON | off | Off | OFF Whereas YAML 1.2 spec recognizes only 6: true | True | TRUE | false | False | FALSE For documents that explicit state their YAML spec version at the top of the document, let's adapt the list of forbidden values. In the future, we should: - implement a configuration option to declare the default YAML spec version, e.g. `default-yaml-spec-version: 1.2`, - consider making 1.2 the default in a future release (this would be a slight breaking change, but yamllint always tried to be 1.2-compatible). - consider adapting yamllint to other 1.1 vs. 1.2 differences [^2]. Solves: #587 Related to: #559 #540 #430 #344 #247 #232 #158 [^1]: https://yaml.org/spec/1.2.2/#1032-tag-resolution [^2]: https://yaml.org/spec/1.2.2/ext/changes/#changes-in-version-12-revision-120-2009-07-21
Specification of YAML ≤ 1.1 has 18 boolean values: true | True | TRUE | false | False | FALSE yes | Yes | YES | no | No | NO on | On | ON | off | Off | OFF Whereas YAML 1.2 spec recognizes only 6 [^1]: true | True | TRUE | false | False | FALSE For documents that explicit state their YAML spec version at the top of the document, let's adapt the list of forbidden values. In the future, we should: - implement a configuration option to declare the default YAML spec version, e.g. `default-yaml-spec-version: 1.2`, - consider making 1.2 the default in a future release (this would be a slight breaking change, but yamllint always tried to be 1.2-compatible). - consider adapting yamllint to other 1.1 vs. 1.2 differences [^2]. Solves: #587 Related to: #559 #540 #430 #344 #247 #232 #158 [^1]: https://yaml.org/spec/1.2.2/#1032-tag-resolution [^2]: https://yaml.org/spec/1.2.2/ext/changes/#changes-in-version-12-revision-120-2009-07-21
Specification of YAML ≤ 1.1 has 22 boolean values: y | Y | n | N yes | Yes | YES | no | No | NO true | True | TRUE | false | False | FALSE on | On | ON | off | Off | OFF Whereas YAML 1.2 spec recognizes only 6 [^1]: true | True | TRUE | false | False | FALSE For documents that explicit state their YAML spec version at the top of the document, let's adapt the list of forbidden values. In the future, we should: - implement a configuration option to declare the default YAML spec version, e.g. `default-yaml-spec-version: 1.2`, - consider making 1.2 the default in a future release (this would be a slight breaking change, but yamllint always tried to be 1.2-compatible). - consider adapting yamllint to other 1.1 vs. 1.2 differences [^2]. Solves: #587 Related to: #559 #540 #430 #344 #247 #232 #158 [^1]: https://yaml.org/spec/1.2.2/#1032-tag-resolution [^2]: https://yaml.org/spec/1.2.2/ext/changes/#changes-in-version-12-revision-120-2009-07-21
Specification of YAML ≤ 1.1 has 22 boolean values: y | Y | n | N yes | Yes | YES | no | No | NO true | True | TRUE | false | False | FALSE on | On | ON | off | Off | OFF Whereas YAML 1.2 spec recognizes only 6 [^1]: true | True | TRUE | false | False | FALSE For documents that explicit state their YAML spec version at the top of the document, let's adapt the list of forbidden values. In the future, we should: - implement a configuration option to declare the default YAML spec version, e.g. `default-yaml-spec-version: 1.2`, - consider making 1.2 the default in a future release (this would be a slight breaking change, but yamllint always tried to be 1.2-compatible). - consider adapting yamllint to other 1.1 vs. 1.2 differences [^2]. Solves: #587 Related to: #559 #540 #430 #344 #247 #232 #158 [^1]: https://yaml.org/spec/1.2.2/#1032-tag-resolution [^2]: https://yaml.org/spec/1.2.2/ext/changes/#changes-in-version-12-revision-120-2009-07-21
Specification of YAML ≤ 1.1 has 22 boolean values: y | Y | n | N yes | Yes | YES | no | No | NO true | True | TRUE | false | False | FALSE on | On | ON | off | Off | OFF Whereas YAML 1.2 spec recognizes only 6 [^1]: true | True | TRUE | false | False | FALSE For documents that explicit state their YAML spec version at the top of the document, let's adapt the list of forbidden values. In the future, we should: - implement a configuration option to declare the default YAML spec version, e.g. `default-yaml-spec-version: 1.2`, - consider making 1.2 the default in a future release (this would be a slight breaking change, but yamllint always tried to be 1.2-compatible). - consider adapting yamllint to other 1.1 vs. 1.2 differences [^2]. Solves: #587 Related to: #559 #540 #430 #344 #247 #232 #158 [^1]: https://yaml.org/spec/1.2.2/#1032-tag-resolution [^2]: https://yaml.org/spec/1.2.2/ext/changes/#changes-in-version-12-revision-120-2009-07-21
The default configuration for the
truthy
linter applies it to keys as well as values. The syntax for GitHub Actions definitions uses anon
key to determine what event the workflow applies to.The upshot is that, out of the box, yamllint will blow up on any YAML document configuring a GitHub Action. This certainly can be fixed by disabling
check-keys
, but the presence of that option is non-obvious.Given that GitHub Actions are a very common YAML usecase, do you think it'd be reasonable to disable this linter's
check-keys
option by default?The text was updated successfully, but these errors were encountered: