<@U011B6K6345> I really appreciate the discussion ...

# github-workflows-kt

[Piotr Krzemiński]

@Sebastian Schuberth I really appreciate the discussion in Dependency bots (Dependabot/Renovate) don't work well! I think we can also discuss here on Slack since more people can engage, and I'm still planning to gather all the thoughts and arguments and prepare a summary of why I chose the approach of on-demand Maven artifacts generation for the bindings. Of course I allow an option that we'll go forward with another approach, the one I'm describing is not yet stable/primary. We did discuss some pros and cons of various approaches here on Slack, but the discussions can get a bit chaotic sometimes, so the decision log would be still good

[Piotr Krzemiński]

what part of the on-demand Maven artifacts generation is the most shady or unacceptable to you?

[Sebastian Schuberth]

Thanks for asking, but before I reply, let me state that I'm not even using github-workflows-kt (yet). So my remarks are rather academical 😉 That said, I guess I'm mostly concerned about the overall complexity of the solution: Too many "moving parts" and indirections that make things harder to understand and maintain, and error prone.

[Piotr Krzemiński]

Do you mean complexity for a user of github-workflows-kt, or for the library maintainer(s)? I generally agree that the plot twist of having to add a Maven dependency on some action binding is not obvious, and requires some investment from the users to learn how it works. Previously all that was needed was to start typing some action's name, and look forward to get the IDE's autocomplete to do the rest to import a given action's binding. Is it what you mean by harder to understand?

[Piotr Krzemiński]

some related threads for reference:
• https://kotlinlang.slack.com/archives/C02UUATR7RC/p1711181848013639
• https://kotlinlang.slack.com/archives/C02UUATR7RC/p1713339662011959
Worth noting that before this approach was implemented, I planned to go forward with code generation on the client side, and I implemented an MVP. After gathering feedback, it became clear that it was unacceptably complex. So in the decision log, I'll compare at least 3 approaches: (1) the current stable one (bundled bindings), (2) client-side bindings generation, (3) bindings generated as Maven artifacts on demand

[Chris Lee]

Any approach here should consider security best practices for pinning actions to a commit SHA, e.g.

uses: "actions/checkout@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b" # v4.1.5

This works currently with Dependabot (and presumably Renovate, have not tested) - PRs are created to bump actions to the latest tagged version (incl. updating the optional version comment when present).
This also raises an inconsistency between Maven-published artifacts and Github-action artifacts/releases (there isn’t a published artifact per se) :Maven published artifacts have an immutable version, whereas Github-action artifacts use tags which can be removed/repointed at any time reflecting a shifting version.

[Piotr Krzemiński]

Yeah, I have it in mind, and planning to address it at some point. With the bindings as Maven artifacts, we get a possibility to refer by full (major.minor.patch) version already. I need to think how to define the commit hash, perhaps optionally after the version

[Sebastian Schuberth]

Do you mean complexity for a user of github-workflows-kt, or for the library maintainer(s)?

I was primarily thinking about the library maintainer(s). But also for users it could be irritating to use Maven-dependency syntax for something that is not a Maven dependency.

[Sebastian Schuberth]

I don't know if it's feasible, but maybe introducing a new annotation like @file:DependOnGitHubAction could solve at least that potential confusion. Not sure if that's worth the effort, though.

[Piotr Krzemiński]

But also for users it could be irritating to use Maven-dependency syntax for something that is not a Maven dependency.

yeah, it's one of the main challenges - how to integrate these two worlds. Using Maven here is a step towards unifying dependency management, although it has its own challenges

[Piotr Krzemiński]

regarding the custom annotation, it would indeed cost quite a lot of effort, including changes in Kotlin compiler, I'm afraid. As long as Kotlin scripting doesn't support compiler plugins, it's really hard to go with something custom on the script side