false positive truthy failure on travis files

[ssbarnea]

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.

[adrienverge]

Hi @ssbarnea,

I confirm the behavior, and it's described in the documentation.

Values like on, yes, etc. can be converted to "true", even if they are keys. For example, run the following code:

echo '
true: 1
on: 2
yes: 3
' | python -c 'import sys, yaml; print(yaml.load(sys.stdin))'

It will produce:

{True: 3}

[ssbarnea]

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.

[adrienverge]

having it documented does not make the user experience better.

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.

[ssbarnea]

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 when on ansible) is not very common and is not present in default travis templates. Still, is a core feature which is very old and established so I doubt they will change the file format to pass yamllint-ing.

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.

[adrienverge]

What about a new option for the truthy rule? Something like check-keys: true | false or similar?

@pdericson any thoughts?

[jayvdb]

What about a special case for .travis.yml , or having schemas which define key names which could then be whitelisted if they appear in the correct place in the yaml. e.g. use https://github.com/SchemaStore/schemastore/blob/master/src/schemas/json/travis.json for travis

[ghost]

This issue is not limited to .travis.yml configs. The new GitHub Actions yaml spec has a required on key: https://help.github.com/en/articles/workflow-syntax-for-github-actions#on
E.g.,

name: Pull request based on master
on:
  pull_request:
    branches:
      - master
# ...

yamllint is throwing 2:1 warning truthy value should be one of [false, true] (truthy).

[adrienverge]

Hi,

While waiting for someone to contribute a new check-keys option or something equivalent, an option is to disable the truthy rule in yamllint config:

---
extends: default
rules:
  truthy: disable

... or allow on:

---
extends: default
rules:
  truthy:
    allowed-values: ['true', 'false', 'on']

[jameswilliams1]

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

[oerp-odoo]

Is this issue fixed?

Im still getting that warning on github actions. Should I just use # yamllint disable-line rule:truthy to disable it?

[brettinternet]

To fix this just add this to your .yamllint

rules:
  truthy:
    allowed-values: ['true', 'false']
    check-keys: false

[tshowers-bt]

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 check-keys: false the default? Warning about keys that would be truthy-but-not-idiomatic values if they were values instead of keys seems more like a bug than a feature. Recommending that something: on be replaced by something: true makes sense because they are semantically equivalent but the latter is the more idiomatic way to express it. Recommending that on: something be replaced by true: something seems strange because they're not equivalent and the change has nothing to do with truthiness. The effect of checking keys just seems to be an arbitrary ban on key names, one of which is very common in CI definitions. Maybe I'm misunderstanding the use case but I can't imagine why someone would want to be warned that they used one of these names for a key given that changing the key name isn't even an option if you're using a schema you don't control (like travis or github).

---

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 y, yes, and on colliding but it did result in true and True colliding. It's not just case insensitivity though because on and On don't collide.

This can be useful to prevent surprises from YAML parsers transforming [yes, FALSE, Off] into [true, false, false] or {y: 1, yes: 2, on: 3, true: 4, True: 5} into {y: 1, true: 5}.

Conversions on https://onlineyamltools.com/convert-yaml-to-json

I still think the behavior with check-keys: true is surprising but now I'm thinking it's because the YAML spec is surprising (I'll have to dig into it now to be sure).