"on:" as keyword becomes "true:"

[omgnuts]

What steps did you take:
Using ytt data values to generate github actions templates, and the "on:" key becomes "true:".

[template.yml]
#@ load("@ytt:data", "data")
---
name: #@ data.values.action_name
on:
  push:
    branches: #@ data.values.action_branch
    paths: #@ data.values.action_paths
...

What happened:
The "on:" key was replaced by "true:"

[ytt-output]
name: Some name to publish
true: <------------------ expected on: instead of true:
  push:
    branches:
    - master
    paths:
    - .github/workflows/some-docker-image.yml

What did you expect:
Expected the "on:" key to remain

[ytt-output]
name: Some name to publish
on: <------------------ expected on: as the correct output
  push:
    branches:
    - master
    paths:
    - .github/workflows/some-docker-image.yml

Anything else you would like to add:
I figure "on:" might be recognized as a boolean flag somewhere. So I tried "off:" as a keyword to test, and it became "false:" as well. Is there a way to tell ytt to preserve certain keywords as is? Eg.

In the meantime, I'm using sed to replace the piped output before generating the output files.

"on":

to become

on:

Environment:

• ytt version v0.31.0 release
• Windows 10

[danielhelfand]

Thanks for reporting this. I can confirm being able to reproduce this. As you point out, on and off are interpreted by YAML as boolean values leading to the issue above:

ytt -f /tmp/action/workflow.yml -f /tmp/action/values.yml -s

ytt: Error: Unmarshaling YAML template 'workflow.yml': yaml:
  Strict parsing:
    Found 'on' ambigious (could be !!str or !!bool)

It does look like "on": with quotes around it is still interpreted correctly by actions as a temporary workaround.

Can look a bit further on what the appropriate way to get around this scenario is.

[danielhelfand]

Going to close this out as it seems to be a duplicate of #146.

The recommended workaround is to have the on key be a string for now ("on":), but we are going to look into prioritizing this as it appears this has come up quite a few times.