-
Notifications
You must be signed in to change notification settings - Fork 267
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
false positive truthy failure on travis files #158
Comments
Hi @ssbarnea, I confirm the behavior, and it's described in the documentation. Values like echo '
true: 1
on: 2
yes: 3
' | python -c 'import sys, yaml; print(yaml.load(sys.stdin))' It will produce:
|
Thanks for the update, now we need to find a way to fix this because having it documented does not make the user experience better. So far the only place I found to be conflicting is travis.yaml and to be honest I cannot find any reasom for blaming its syntax here. Maybe we need an option to look for truthy only for leaf-keys or to disable it for travis files. I am open to suggestions. Fixing this is not an urgency as I disabled the truthy feature completely for the moment on that small project. Still, we should look for a way to address this in the default tool behaviour, so the user experience will be good and he will not encounter this false-positive. |
For people that read the documentation, it does 😉 I'm open to proposals and contributions. Also, feel free to explain what you mean by "travis keys": a clear example of your specific problem would help. |
My mistake to not give an example, https://github.com/pycontribs/tendo/blob/master/.travis.yml#L78 We are lucky the the "on" condition (which is similar to I don't know what is the right approach to take here but I know how to describe the desired user experience: when user enables yamllint they should not get a false-positive on a travis.yaml file. |
What about a new option for the @pdericson any thoughts? |
What about a special case for |
This issue is not limited to name: Pull request based on master
on:
pull_request:
branches:
- master
# ... yamllint is throwing |
Hi, While waiting for someone to contribute a new ---
extends: default
rules:
truthy: disable ... or allow ---
extends: default
rules:
truthy:
allowed-values: ['true', 'false', 'on'] |
An easy workaround here, add: # yamllint disable-line rule:truthy to any ci lines that use 'on' which avoids having to fully disable truthy (personally I like this rule for Ansible roles and don't want to disable it due to a bug). Relevant docs page: https://yamllint.readthedocs.io/en/stable/disable_with_comments.html |
Picking up hack from adrienverge/yamllint#158 (comment)
See adrienverge/yamllint#158 for some more discussion
* Add workaround for 'truthy' warnings in yaml See adrienverge/yamllint#158 for some more discussion * Check each yamllint line length warning and clearly markup those which cannot be easily folded into shorter lines
Is this issue fixed? Im still getting that warning on |
To fix this just add this to your rules:
truthy:
allowed-values: ['true', 'false']
check-keys: false |
edit: The paragraph below seems to make a bad assumption about the way key text is interpreted. adrienverge I've now seen all the dupes and have a bit more context so I figured I'd I leave my original comment unedited for context and explain what else I came across below for any future readers. If you think this is just noise though we can delete it. Is there a reason not to make Well, after looking into this more it seems like keys are values that (sometimes?) follow the same rules as non-key values when they are interpreted. For example; I took and example from the yamllint docs that refers to keys being interpreted as bool and converted it to JSON using an online converter. It didn't result in
Conversions on https://onlineyamltools.com/convert-yaml-to-json I still think the behavior with |
Otherwise, yamllint complains with: ``` 2:1 warning truthy value should be one of [false, true] (truthy) ``` Alternative: Adding the following comment in all GHA YAML files: ``` ``` See also: adrienverge/yamllint#158 (comment)
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
It seems that yamllint chokes complaining about not using truthy values for travis keys.
Just to be clear: this is about keys not values with name "on".. When used as a key, on have a total different sense than the "on" as a value, which I find acceptable to trigger a warning.
The text was updated successfully, but these errors were encountered: