The workflows in kotlin-python are the main inspiration to me to create https://github.com/krzema12/github-actions-kotlin-dsl/.
That's why I'd like to use it in this project, so that we have a real-life scenario and "customer zero".
I'm migrating just one workflow as an experiment, and once it's merged, I'll do the same with the other one. By having them in the same Kotlin file or sharing common Kotlin file, we'll manage to remove some across-workflows duplication.
Testing
I compared workflows in runtime, before and after this change:
I also checked how it works in case of forgetting to regenerate the YAML. It now fails at runtime:
and in the future we can e.g. add auto-generated job that regenerates the YAML. The golden grail is GitHub supporting such Kotlin DSL, without any (semi)manual generation steps.
Part of https://github.com/krzema12/github-actions-kotlin-dsl/issues/3.
The workflows in kotlin-python are the main inspiration to me to create https://github.com/krzema12/github-actions-kotlin-dsl/. That's why I'd like to use it in this project, so that we have a real-life scenario and "customer zero".
I'm migrating just one workflow as an experiment, and once it's merged, I'll do the same with the other one. By having them in the same Kotlin file or sharing common Kotlin file, we'll manage to remove some across-workflows duplication.
Testing
I compared workflows in runtime, before and after this change:
pythonTest
: before and aftermicroPythonTest
: before and afterI also checked how it works in case of forgetting to regenerate the YAML. It now fails at runtime:
and in the future we can e.g. add auto-generated job that regenerates the YAML. The golden grail is GitHub supporting such Kotlin DSL, without any (semi)manual generation steps.