Dependency bots (Dependabot/Renovate) don't work well

[krzema12]

If the bot opens a PR that e.g. bumps some action's version from v3 to v4, it will happen only in the YAML, not in the Kotlin script that is actually the source of truth for the workflows.

To adjust the version in the Kotlin script as well, several things have to happen:

1. github-workflows-kt has to support the new version. It now lags up to 2 weeks after a new major version is released.
2. there has to be a mechanism that understands Kotlin script and the library, and knows what to change to update the action
3. CI has to check consistency between the YAML and the Kotlin script

https://github.com/typesafegithub/github-workflows-kt/issues/941 will likely solve the first item. The CI check is also possible to add.

[krzema12]

I can imagine a GitHub action that one could configure to trigger for each Dependabot/Renovate PR. It would analyze the PR, check which actions are updated, and push another commit that makes the same updates in the Kotlin scripts.

[krzema12]

This will be tackled in https://github.com/typesafegithub/github-workflows-kt/issues/941

[sschuberth]

Alternatively, those bots could also be taught how to bump dependencies in the KTS file directly, i.e. bump something like action = CheckoutV3() to action = CheckoutV4() (while disabling updates to the YAML file).

[krzema12]

@sschuberth i thought about it, but I decided to go another way: modeling action dependencies as Maven artifacts.

[sschuberth]

modeling action dependencies as Maven artifacts.

Actually, I was thinking the same at first, as e.g. Renovate bot already supports KTS @file:DependsOn syntax. But you can't just put "fake names" in there that do not match real Maven artifacts, as otherwise Renovate's check if some newer version was published would not work.

Basically, the questions boils down to which of these two alternatives to go for:

• build upon a dependency declaration syntax that Renovate already support, and somehow implement a new update check for it, or
• build up an update check that Renovate already support, and just make Renovate understand another syntax to declare these.

And my guess is that the second option is easier to implement.

[krzema12]

But you can't just put "fake names" in there that do not match real Maven artifacts, as otherwise Renovate's check if some newer version was published would not work.

But we can have a dedicated Maven repo that generates the bindings on the fly! 😊 It's already implemented, just in experimental stage. Please see https://typesafegithub.github.io/github-workflows-kt/user-guide/migrating-to-Maven-based-bindings/ and let me know what you think!

[sschuberth]

But we can have a dedicated Maven repo that generates the bindings on the fly! 😊

While technically a nice achievement, I have to admit that personally I don't like that approach. IMO it involves too much complexity, with the generation of fake artifacts, hosting them, and special rules like replacing slashes with double underscores.

Doing what you did in https://github.com/renovatebot/renovate/pull/16684, but for action updates in the action = <name>V<version>() syntax still sounds more reasonable to me.

[krzema12]

Doing what you did in https://github.com/renovatebot/renovate/pull/16684, but for action updates in the action = <name>V<version>() syntax still sounds more reasonable to me.

It would still require action bindings to be bundled with the library, right? I'd really like to decouple the library from the actions/bindings, and I'm ready to pay the extra cost of the custom infra, it just scales better.

[krzema12]

I'll prepare a detailed comparison of the two approaches, and share it here. In the meantime, we can also discuss on Slack in https://kotlinlang.slack.com/archives/C02UUATR7RC/p1716124506441219 (I feel more people will have a chance to chime in, since not many people actively browse for the issues in the repo, and some people actively participate in the discussions on Slack).