Piotr Krzemiński
12/13/2023, 9:57 AMPiotr Krzemiński
12/16/2023, 8:20 AMPiotr Krzemiński
12/22/2023, 9:54 PMLeoColman
12/23/2023, 1:24 PMLeoColman
12/23/2023, 1:27 PMLeoColman
12/23/2023, 1:28 PMPiotr Krzemiński
01/04/2024, 9:39 PMPiotr Krzemiński
01/06/2024, 8:43 AMlouiscad
01/20/2024, 1:21 AMPiotr Krzemiński
01/20/2024, 9:17 PMPiotr Krzemiński
02/01/2024, 9:33 AMPiotr Krzemiński
02/05/2024, 3:05 PMPiotr Krzemiński
02/16/2024, 10:52 AMPiotr Krzemiński
03/01/2024, 6:50 AMVampire
03/12/2024, 4:39 PMPiotr Krzemiński
03/23/2024, 8:17 AM@file:Import
) that makes working with these even more painful.
An alternative idea, in some ways similar what @Vampire you proposed some time ago: have a separate Maven package for each action, but I'd like to host the packages in a way that allows me to generate the bindings on the server side, once the user requests them. A bit like https://jitpack.io/, but specialized to cover just the action bindings. The expected UX would be like:
// foobar.main.kts
/// ...
@file:Repository("<https://bindings.typesafegithub.io|https://bindings.typesafegithub.io>")
@file:DependsOn("actions:checkout:v4")
// ... more dependencies like:
@file:DependsOn("action-owner:action-name:action-version")
import actions.Checkout
// ...
uses(action = Checkout(...))
// ...
The user would have to create no extra files like _used_actions.yaml
, no extra workflows like generate-action-bindings.main.kts
and call it either locally or in GitHub workflows. If done right, dependency updating bots like Renovate would work as well, since the maven-metadata.xml
would be generated according to what versions a given action publishes. For this to work kinda like JitPack, we'd have to have our own live endpoint that can react on appropriate GET requests, and generate the bindings on the fly.
I'm also thinking about a variation of this idea, to not have to worry about paying for a server, just to start with something: host the pre-built packages somewhere on GitHub. If someone needs a binding for an action that is not yet supported, they would create a GitHub issue in a well-defined place and format that would later be picked up by a GitHub workflow, and it would generate and commit desired bindings. A separate workflow would periodically regenerate the bindings to catch manifest changes. Here's a little working PoC where I manually built the package and committed it to GitHub here, and show below how to consume it:
#!/usr/bin/env kotlin
// If another repo than Maven Central is specified, we need to specify Maven Central explicitly.
@file:Repository("<https://repo1.maven.org/maven2|https://repo1.maven.org/maven2>")
@file:DependsOn("io.github.typesafegithub:github-workflows-kt:1.12.0")
// Dependency on a repo which contains Maven packages with bindings for various action.
@file:Repository("<https://raw.githubusercontent.com/typesafegithub/github-workflows-kt/poc-host-precompiled-bindings/bindings/|https://raw.githubusercontent.com/typesafegithub/github-workflows-kt/poc-host-precompiled-bindings/bindings/>")
@file:DependsOn("actions:checkout:v4")
import actions.Checkout
Checkout(
fetchDepth = Checkout.FetchDepth.Value(10),
)
Let me know your thoughts! Any risks you see etc.Piotr Krzemiński
03/29/2024, 7:45 AMlouiscad
04/01/2024, 10:18 PMPiotr Krzemiński
04/06/2024, 7:42 AMPiotr Krzemiński
04/10/2024, 11:28 AMPiotr Krzemiński
04/11/2024, 10:20 AMPiotr Krzemiński
04/11/2024, 1:11 PMPiotr Krzemiński
04/12/2024, 9:47 AMPiotr Krzemiński
04/17/2024, 7:41 AMmaven-metadata.xml
enumerating the version. Example:
• the original repository of actions/checkout
exposes tags pointing to the same commit (in theory) like v3.5.2
or 4.1.2
, and tags like v3
or v4
tracking newest version for a given major version
• looking at an example Maven package, e.g. versions exposed by github-workflows-kt (see its maven-metadata.xml), one can only release a concrete version and there are no pointers to versions like io.github.typesafegithub:github-workflows-kt:1
would point to the current 1.14.0
Currently the bindings server produces such maven-metadata.xml
file for actions/checkout
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
<groupId>actions</groupId>
<artifactId>checkout</artifactId>
<versioning>
<latest>v4</latest>
<release>v4</release>
<versions>
<version>v1</version>
<version>v2</version>
<version>v3</version>
<version>v4</version>
</versions>
<lastUpdated>20240417073254</lastUpdated>
</versioning>
</metadata>
and you can only request artifacts for these versions.
I started thinking: what if we want to support referring to minor and patch versions of actions, and still allow the dependency update bots to update both just major versions (v1
) and the full versions (v1.2.3
)? Should there even be v
in front (it's not Maven-esque)?
If we wanted to go all Maven:
• we should enumerate only full versions in maven-metadata.xml
, and without v
, so <versions>...<version>3.5.2</version>...</versions>
• if someone really wants to allow the newest version for a given major version (emulate the vN
tags provided by GitHub actions), using Maven version ranges is possible, so instead of the current actions:checkout:v2
one would have to write sth like actions:checkout:[2.0,3.0)
. It's explicit, but arguably ugly 🙂 I haven't seen many usages of version ranges in the JVM world, so maybe then it would encourage users to use the full versions? It would also be a breaking change for what the server currently exposes, but the number of users is still low
thoughts?Piotr Krzemiński
04/17/2024, 6:44 PMv1.2.3
) instead of only major versions. Feel free to give it a spin if there's an action that you couldn't use so far with the bundled bindings 😄Nikky
04/18/2024, 12:12 PMGITHUB_TOKEN
when present in env like so
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
as show in githubs own exampleNikky
04/20/2024, 10:51 PMNikky
04/21/2024, 12:07 PMpublishToMavenLocal
and zip up ~/.m2/respository/....
turn it into a artifact on github,
add a workflow dependency/trigger and a step to the integration tests that loads and unzips it into place before executing the scriptsNikky
04/22/2024, 11:50 AMPiotr Krzemiński
04/25/2024, 6:00 AM