I'm wondering how many projects/repos use github-w...

# github-workflows-kt

[Piotr Krzemiński]

I'm wondering how many projects/repos use github-workflows-kt and aren't Gradle-based. My hypothesis is that there's only a handful. I'm asking about it because I realized that Kotlin Script limits me in several areas, e. g. I'd like to move action wrappers generation to the client side using KSP or partially or entirely replace runtime consistency check with a build time Gradle check task. I'm not planning this move for v1, rather within a year or so. Kotlin Script would stay as a secondary use case with limited set of features.

Please react with:
• 📜 If you'd like to stay with Kotlin Script way of using the library
• G if you'd be able to use the library from within a Gradle project
• Both if you have both kinds of projects

[Vampire]

How would a build time check help? It could always be that the files were changed since building. And also the check should imho be done before and Gradle build is started.

[Piotr Krzemiński]

I'm making an assumption here that for each commit, the user runs a Gradle build (at least 'check' task on the root project) that will perform consistency check on all registered workflows. If PRs are used to make changes to the project, nothing faulty will enter the GH Actions YAMLs as "PR time" is the moment to learn about the inconsistencies. The only edge case I see is when no PR was made and some inconsistency was introduced to the workflows, then it's too late to report the inconsistency because the workflows could already be triggered. Do you think it would be good enough?

[Piotr Krzemiński]

Runtime consistency check is always the safest option so it would stay, but maybe as an opt-in

[Vampire]

I would prefer first class support by GHA :-D

[Nikky]

i’d prefer not to involve KSP, that limits people to the last version of kotlin that it supports (and we had very mixed experiences with it just randomly breaking our gradle builds)

[Piotr Krzemiński]

good to know, I have 0 experience with KSP actually. I’d like us to think about something higher-level: on-demand wrapper generation, whether it’s KSP or something else. This approach is a trade-off, so for now I’m just planning to experiment - bundled wrappers are not going anywhere soon

[Nikky]

i’d suggest making a custom gradle plugin for this task.. that cuts down on the amount of specific configuration the users will have to do.. and people that already use KSP will not have to puzzle over how to not break their things in a single project.. or be forced to add a subproject just to run the workflow generation tasks.. which nobody will be happy with either

[Nikky]

and retaining the ability to generate the wrappers via command or such would be nice.. that way other buildsystems could .. if someone put the work in, also integrate this

also for testing and such

[Nikky]

in my expereince the less gradle specific things you rely on the better… as it will inevitably break or blow up in your face as they have another hare brained idea and change things around

but gradle tasks are too useful to not use them either 😛

[Piotr Krzemiński]

we can implement whatever interface/entry point we need, I’m planning to expose the core logic as a Gradle module with pure Kotlin API that doesn’t depend on CLI, Gradle or such (in the spirit of DDD/hexagonal architecture)