Im just interested, what do you guys think about p...

# github-workflows-kt

[Oleg Yukhnevich]

Im just interested, what do you guys think about providing gradle/maven plugin, which will generate yaml files based on kts files in github/workflows folder? with some task like syncWorkflows?

[Oleg Yukhnevich]

or some prebuilt executable, which could be run on precommit hook?

[Piotr Krzemiński]

Looks like related to https://kotlinlang.slack.com/archives/C02UUATR7RC/p1648134455789169?thread_ts=1648134455.789169&cid=C02UUATR7RC

[Piotr Krzemiński]

The idea makes sense in general, I'm open to contributions :) I don't have bandwidth to implement it myself

[jmfayard]

actually already possible with some ugly syntax, I opened a ticket on this

[jmfayard]

https://youtrack.jetbrains.com/issue/KT-53707/The-Kotlin-Gradle-plugin-should-allow-to-wrap-a-Kotlin-script-inside-a-Gradle-task#focus=Co[…]0271.0-0

[jmfayard]

now the question is: in which plugin would it make more sense to make this easier?
and frankly JetBrains Kotlin Plugin is the right answer for me

[Oleg Yukhnevich]

I was thinking about something like this:
• gradle (may be also maven) plugin - for gradle it's settings plugin
• include in it boolean flag like preCommitHook - if true, hook will be automatically installed on current local machine (can be skipped on CI by default)
• new task, like syncKotlinWorkflows which will automatically take all kts workflows in github/workflows and generate yaml (also we can sync version of plugin to dependency used in scripts and update it)
• under the hood, better will be if both hook and task just call some executable, created via jlink or graal(better), so it will run just super fast, and gradle will be not involved in precommit hook at all.
• this plugin/executable can also be used to convert yaml files to kotlin on first use.
So in this case, adoption of library will be super easy
WDYT?
I can create 2 issues if needed: one for gradle/maven plugin and one for some sort of small CLI with graal?

[jmfayard]

git commit hooks are a good idea with a terrible implementation but I get your point

[jmfayard]

so actually I don't get your point, you want to have a Gradle wrapper task but then you say you want to avoid Gradle to make it fast?
why bother with Gradle in the first place then?
how does it make life simpler for people using typescript or python, but who also dislike YAML,
to have to install irrelevant stuff like Gradle, jiling or graal?

[jmfayard]

I would say the simpler solution is to not code but documentation

Explain how you can copy/paste a shell script .github/workflows/bootstrap.sh written by us that would
• detekt if Kotlin is already installed, else tels you to open https://kotlinlang.org/docs/command-line.html
• list all .github/workflows/*.kts available
• maybe automatically chmod +x because this shit is boring
• check which input and output files have changed
• runs the one that needs to be modified
• maybe install itself as a pre-push hook?
The drawback of course is that someone (meaning: not me 🙂 )
has to write that some awful Bash shit to have the bootstrap.sh thing working

[Oleg Yukhnevich]

what I had in my mind, is that not everyone will want to use hook, and for those, there will be manual task, that will convert yaml to kts, or update version in file (which can have breaking changes) or there could be some other tasks

and for precommit hook, gradle is not needed at all

regarding those who not use gradle, still executable/bash script is really something usefull and still, I think, that just an executable will be simplier - both to develop and use

[jmfayard]

so you mean basically a Kotlin script who will do the same thing that the hypothetical Bash script I described
but we don't have to copy/paste the ugly Bash script in every repository?
that sounds good yes
actually easy to do too
I'm sold to the idea

[jmfayard]

I created an issue @Oleg Yukhnevich
feel free to comment
https://github.com/krzema12/github-actions-kotlin-dsl/issues/464

[Oleg Yukhnevich]

Cool!
Will take a look tomorrow

[Javier]

I think the task shouldn’t be calling a kts file

[Javier]

The library should have an API which exposes a generate function

[Javier]

so you call it directly inside the Gradle task

[Javier]

and you generate the DSL in a normal kt files with the DSL and you pass it to Gradle in some way

[jmfayard]

@Javier comments get lost in Slack, can you provide feedback in the issue I created instead? (see above)

[Javier]

Yeah

[jmfayard]

Thanks, you rock!

[Javier]

Added, feedback is welcome 😛

[Piotr Krzemiński]

thanks folks for driving it! I simply have no time to dig deeper into all of this, but I’m happy to read some final idea for a CLI or a Gradle plugin 🙂 I’d be also happy to host it in the main repo