How are folks dealing with re-generating yaml file...

# github-workflows-kt

[Chris Lee]

How are folks dealing with re-generating yaml files when there’s an update to the lib?
For example, renovate nicely opened a PR for updating to 0.48.0. Merging that PR as-is will (perhaps) break the consistency check (as the yaml files where generated with 0.47.0), and in any event would desire them to be regenerated to match the library version.
There’s of course the manual option - open up each file in the editor and run it (or do that on command line).
I suppose there could be a Gradle target that enumerates these and executes them.

[Vampire]

You mean like https://github.com/Vampire/setup-wsl/blob/master/gradle/build-logic/src/main/kotlin/net/kautler/github_actions.gradle.kts and then calling gw preprocessWorkflows? 🙂

[Chris Lee]

lol you beat me to it, as usual 😉 thank you.

[Vampire]

Actually, I think somwehere else I added

// work-around for <https://youtrack.jetbrains.com/issue/KT-42101>
systemProperty("kotlin.main.kts.compiled.scripts.cache.dir", "")

must have been a different project and I didn't port that change over yet. I need to check whether I did more. But that specific change you only need if you use @file:Import

[Vampire]

No, I think that was the only change I did, besides also adding a readme: https://github.com/Vampire/spock/blob/kotlin-workflow-files/.github/workflows/README.adoc

[Piotr Krzemiński]

Merging that PR as-is will (perhaps) break the consistency check (as the yaml files where generated with 0.47.0)

actually, no 🙂 in this very case, there were no breaking changes (see release notes), I also mark there if you need to regenerate the YAMLs. Later this summer, I’m planning to publish v1.0 after which I’ll avoid breaking changes and hold with them for at least ~half a year (then will bump major version)

[Piotr Krzemiński]

to tackle YAML regeneration for all my workflows, I do this:
• I have this workflow that helps me check if the YAMLs need regeneration
• if they do, I copy the command and run it locally to regenerate the YAMLs
I was thinking about creating a little mechanism to make it easier for library consumers to handle these cases, but as I mentioned, I don’t anticipate many breaking changes/changes that require YAML regeneration going forward

[Chris Lee]

thanks. pretty much matches what @Vampire has done via a Gradle task. Have tied that into a Gradle precommit hook to check/regenerate as needed.

[Vampire]

Git I guess :-D

[Chris Lee]

Sorry, bad terminology. Have a ‘precommit’ Gradle task that does a bunch of stuff (check, ktLint, ) and now check/regenerates the workflow files.

[Vampire]

Ah, I c