:github-workflows-kt: <v1.5.0 released!>

# github-workflows-kt

[Piotr Krzemiński]

github workflows kt v1.5.0 released!

[Piotr Krzemiński]

so yeah, I encourage you to migrate to the new approach and share your thoughts (together with PRs with a successful migration) on this channel 🙂

[Piotr Krzemiński]

happy to help in case of troubles

[Vampire]

"biding generation" => "binding generation"

[Vampire]

To be honest, from reading the docs I don't like it too much. Of course I understand the intention to need less frequent releases and so on which is also better for consumers with auto-update tools, but
• It increases execution time
• You cannot use different major versions in different places if I got it right
• Why that extra unrunnable workflow? Why not at least giving the actions to the generate call as parameter?
• Current IDE problems with @Import

[Vampire]

Maybe generate to .github/actions/generated instead or make it configurable if it isn't.

[Piotr Krzemiński]

> It increases execution time
in the current implementation, yes. It's the cost of the tradeoff. We can think how to improve it, e.g. keep generated bindings in the repo and have a cheap method of checking if the bindings need to be regenerated

[Piotr Krzemiński]

> You cannot use different major versions in different places if I got it right
for now yes, it's my intended simplification. I didn't want to implement it up front because I wonder if there's any demand for using multiple major versions. If you do have such real-life scenario, let me know. I have some ideas how to implement it

[Piotr Krzemiński]

> Why that extra unrunnable workflow? Why not at least giving the actions to the generate call as parameter?
To support dependency update bots like Dependabot or Renovate. We can consider an alternative API like you suggest, something inside generate-action-bindings.main.kts , for those who don't care about the bots

[Piotr Krzemiński]

> Current IDE problems with @Import
🤷 something has to happen first: either they fix the problems, or someone starts using this feature that will increase the priority of fixing the issues 😄 We can consider waiting longer until it's fixed, but keep in mind that waiting longer impacts mostly me as I need to keep the bundled bindings up-to-date. In a month my life will change to an extent that I may not be able to do it regularly, so this change in the approach is a part of adjusting to the new circumstances.
I keep track of the tickets on the Kotlin side in https://github.com/typesafegithub/github-workflows-kt/issues/1090 - I encourage you to push JB to fix it sooner

[Piotr Krzemiński]

great feedback, thank you 🙇 will ticket all these issues soon

[Vampire]

keep generated bindings in the repo

Don't like that either, generated things have nothing to do in the repo that generates them imho. 🙂
Same for the yaml files, but that's simply not possible right now without the native integration we hope for.

If you do have such real-life scenario

Not right now personally, but I think there are for sure cases where you might need it. 🙂

for those who don't care about the bots

They should at least still notify you about updates I think, as they will find the old versions in the generated yaml workflow files.

I encourage you to push JB to fix it sooner

Unfortunately, nothing I can do besides upvoting which I already did.

[Piotr Krzemiński]

@LeoColman would you be open to trying out the new approach? Open to your feedback as well!

[LeoColman]

Absolutely! I didn't read your convo tho. Let me know what you want to try and I'll do it pronto 😄

[Piotr Krzemiński]

See the release notes :)

[Piotr Krzemiński]

@Vampire here are the tracking tickets for the issues/ideas you pointed out:
• Allow generating bindings for more than one major version
• Calling Kotlin scripts in GitHub Actions is slow
• Add alternative simpler API for listing required actions
• IntelliJ doesn't work with importing other scripts
• Caching for Kotlin scripts is broken if using importing