https://kotlinlang.org
Join Slack
:github-workflows-kt: <v1.14.0 released!> :star: I encourage you to try out type-safe action binding...
# github-workflows-kt
p
github workflows kt v1.14.0 released! ⭐ I encourage you to try out type-safe action bindings served as Maven artifacts (docs how to migrate), they should give you much better UX than the client-side bindings generation which is now removed in 1.14.0. 📣 The new approach of vending the bindings is likely going to become the only one later in 2024, within the next several months. That's why I kindly ask you to give it a spin and help me improve this feature before I roll out v2.0 of the lib and drop support for bundled bindings. @louiscad @Nikky @Szczepan Wiśniowski and anyone who uses the lib - happy to get feedback from you!
🎉 2
n
since there is now individual artifacts for each action, how do you easily discover the available actions and whatever the latest version is ? anything like refreshVersions work for 
@file:DependsOn
yet ?
p
how do you easily discover the available actions and whatever the latest version is ?
how would you do it without github-workflows-kt, with the YAML approach?
anything like refreshVersions work for 
@file:DependsOn
yet ?
good question, @jmfayard @louiscad ?
n
how do you learn about deprecated versions now? before when it was all bundled with the library.. old versions of actions would be marked as depracted and prompt replacing with a newer version
p
I highly recommend using dependency update bots like Renovate
j
we use the refreshVersions plugin for version management but it doesn't do anything with kts scripts. One issue with kts scripts is that the dependency management is a bit messy and flaky. I liked the old way better where it would just tell you what you are doing is deprecated.
p
or #refreshversions if you use it already and supports Kotlin scripting? one observation regarding `@Deprecated`: there are rare cases where more than one major version is maintained at any given time. So marking the older still maintained major version as deprecated can be a bit shady (overinterpreting)
hmm, maybe we could have the bindings server generate the 
@Deprecated
annotations... I need to think about it, thanks for the feedback
One issue with kts scripts is that the dependency management is a bit messy and flaky.
can you be more specific? it's certainly not the full-fledged dependency management like we get with Gradle, but I think it does the job
j
I've had lots of issues with intellij not fetching dependencies correctly or requiring restarts after editing kts scripts.
another downside is that unless you manually add each module, you have no auto complete for things that might actually be supported
so poor discoverability, no notifications about new versions, etc. reduces the utility of this quite a bit
Maybe a better idea is to have type aliases always pointing to the latest version of modules and then simply let people fall back to older versions explicitly only when they need them
p
I've had lots of issues with intellij not fetching dependencies correctly or requiring restarts after editing kts scripts.
is there a bug for it in YouTrack?
j
I'm sure there are loads of issues related to kts; I think the underlying issue is that there's not a lot of development activity around kts outside of the narrow case of gradle build scripts
n
and idea is eternally confused about dependencies in kts
😲 1
v
hmm, maybe we could have the bindings server generate the 
@Deprecated
annotations... I need to think about it, thanks for the feedback
Probably not a good idea, as you would need to change what you deliver for v1.2.3 as soon as v2 is released.
Maybe a better idea is to have type aliases always pointing to the latest version of modules and then simply let people fall back to older versions explicitly only when they need them
Use a version range?
n
the only way i see this being useful right now .. is if i move this into a gradle subproject to make refreshVersions work in it.. that splits dependencies into the buildscript.. but at least it would not block the editor which editing the dependencies
l
If someone wants to make refreshVersions work for kts well, without Gradle, and its willing to spend the time to do it right, I am happy to help them
n
wish i had the time again
v
Wish my npm PR would be considered 😄
😅 1
p
maven-metadata.xml
is generated based on GitHub branches/tags, so refreshVersions should be able to do its job if it's Kotlin script-aware
l
Yes, I just want to break free from being a Gradle plugin
👍 1
When it's not necessary
p
I don't mean to discredit refreshVersions, but is there any advantage of using rV over bots like Renovate? apart from rV helping with adding a new dependency as well. I just want to understand it
v
Yes, much. 🙂
n
so yeah.. when i can invoke refreshVersions via commandline (or a wrapper tasks in gradle) and use it to maintain versions in the 
.github/workflows/
folder for all contained scripts, i think this could work another thing that would be very useful is a listing of all available artifacts in the maven repo and some codegen to paste into the file as it is.. the IDE support for kts files is a bit (lot) lacking .. editing the dependson annotations kept locking up my editor even when there was no auto-reload enabled
v
• you can even use it with builds where the bot is not available like local builds • you get all newer versions as comments to pick from • you can do it on will when you prefer to do it instead of having some bot do it - this is preferred by some and disliked by others • probably more points I don't have in mind right now
➕ 1
l
You don't pollute PRs
You don't waste CI credits
You don't pollute commits history with lowkey reviewed and individualized version upgrades
v
And often projects are considered unmaintained if there are open PRs that are not immediately cared about
👍 1
l
It can run locally, or in CI, you choose, you are in control, and it's faster to execute than a CI job
Unless your computer is super slow, but then, are you even working?
p
ok, thanks for the thoughts! I'm willing to continue this thread, this discussion probably belongs to #refreshversions, let's get back to the core topic in this thread 😄 what I take from this is that the users of github-workflows-kt mostly don't like dependency updating bots, and it's a really valuable piece of feedback because I assumed otherwise
n
coworkers comment on this change:
i liked seeing the version of the action we were using in the classname
p
summary of this thread so far: • still poor IDE support for Kotlin Scripting, problems with resolving dependencies, need to restart IDE • best if refreshVersions could help with adding/updating the actions • version number and 
@Deprecated
annotations on the binding's class is actually helpful, and people already got used to it
> i liked seeing the version of the action we were using in the classname true, with the YAML approach you do see the version next to the rest of action's coords, so I see that removing e.g. 
V2
can be perceived as a change in a bad direction. This change is a trade-off, allows managing dependencies in a single place and making the library more maintainable
n
the version number on the clas would be less needed if we could actually go into the bindings class and look at the code, but this loops back into IDE support, no way to download the sourcecode in there ... like there would be if it was a gradle dependency
p
@Nikky so the problem is that scrolling up the script's source to see e.g. 
:v3
is problematic, right?
n
this is what you are seeing.. which is a whole lot of not useful
l
I think Piotr meant the dependencies declared at the top of YOUR script
👍 1
Since actions are transformed as Maven dependencies
p
I also tried this approach:
see at the bottom, it's also here - it's displayed on hover
n
i see.. yeah.. that will take getting used to does not help that the popup is big enough to need scrolling in some cases
p
I'm also wondering if shipping the JARs with sources would enable us to see KDoc in this view
I could display the version there so that it's more prominent
n
i hope it does, who knows what that janky maven dependency handling does
p
on a positive note: at least with this approach, poor IDE support with 
@file:Import
becomes less of an issue (but it still is if you consider sharing code between various entry-point scripts)
it's really, really hard to develop this lib on top of in fact incomplete and buggy product which is Kotlin Script. I wish it could get some love from JB one day, I really like it in principle. Until it's more mature, we need to find a balance between good UX for the users and me not spending most of my maintenance time for this lib on updating the action bindings 🙂 I'm planning to talk to JB once Kotlin 2.0 is out and they hopefully have more resources
v
what I take from this is that the users of github-workflows-kt mostly don't like dependency updating bots
Don't just interpolate that from my opinion and one of the maintainers of 
refreshVersions
though. :-D
p
I counted 4 people (all in this thread apart from me) 🙂
v
I know at least one person who prefers Renovate and hopefully some day merges my PR to use the lib 😄
p
Spock? 😛
v
Exactly
p
I thought about creating an IntelliJ plugin that would help manage the Maven-based dependencies on actions - essentially help the way rV would do, plus allow simple browsing of actions in the marketplace and auto-adding 
@file:DependsOn
. It would partially solve the issues you describe here, flaky IDE support for 
@file:DependsOn
still being an issue that cannot be easily worked around
n
that seems like it would be useful
p
regarding JB polishing Kotlin scripting: just found this https://github.com/Kotlin/KEEP/issues/75#issuecomment-1953997256. Not a hard promise, but a sign that they remember about it
3 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by