Can You Explain Your Project to a 5-Year-Old?
dev.to staff for The DEV Team ・ Se...
For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Is the idea that you use Kotlin and then that generates the YAML workflow? Also how does it work if you are using dependabot to monitor dependencies? For example, you author workflow in Kotlin. Then generate YAML from the Kotlin. Dependabot then comes along at some point and submits a PR to update the version of one of your actions in the YAML of your workflow. The Kotlin that you started with would still have the old version number of the action before the dependabot update. Is there a way of dealing with that?
Yes.
No, it's a known problem that remains unsolved for now. Here's an issue to track it: github.com/typesafegithub/github-w.... The only thing we can have for now is a consistency check in CI to ensure that the Kotlin script and the YAML are in sync, then the automated PR from Dependabot/Renovate won't be automatically merged, giving you a chance to adjust manually. I currently use this technique, and in practice (with my workflows) it's good enough, but I'm open to solving this problem the proper way.
Thanks. I noticed there is a list of supported actions. I maintain a few actions. What's involved to add support for an action?
We have a generator that automates 90% of the work of adding an action from the
action.ymlfile that you already have.What you need to do is to tell us the types of your parameters using a second YAML file
action-types.yml.See here :
github.com/typesafegithub/github-a...
You need to follow semantic versioning and have a major tag that points to the latest release
typesafegithub.github.io/github-wo...
If you are good to go, have a look at CONTRIBUTING.md
It looks straightforward enough. I have 2 more questions.
The contributing instructions indicate:
What commit hash is this looking for? The commit that the current major tag points to? Or something else?
My second question concerns location of
action-types.yml. Is there a preference for whether to simply host it in the action's repo? Or in the repo of github-workflows-kt? It looks like most are in the latter. But I'd think in the action's own repo would be preferred. E.g. less likely to forget about updating it with a new input, etc if it was in the action's repo.I don't know the details of commit-hash to be honest.
We started adding types in our repo because we couldn't just force all action owners on GitHub to do what we want :)
But indeed the type information is best maintained in your own repos so that they evolve together.
Thanks.