Is

result

missing in

Job

? I'm trying to rewrite this in Kotlin, and I don't find how to do so properly.

yes, it's missing from somewhere, but not sure if in

Job

since there's

needs.

in front. It's something new to me, it's in fact an unsupported context. As a short-term approach, try

needs.${yourJob.id}.result

. Long-term, please create a feature request to add support for

needs

context (so far we support these contexts).

Job indeed feels like the right place from a first look.

adding

result

- probably yes, should be added to

Job

to return an expression

"${this.id}.result"

. @louiscad do you fancy adding it?

Yup, I can send a PR. Also, can I add Action Bindings for the

nexus-actions

you see referenced in what I originally linked (in a separate PR)?

sure!

should be added to

Job

to return an expression

"${this.id}.result"

. @louiscad do you fancy adding it?

Not

needs.${this.id}.result

? Can you otherwise refer to the job result besides within

needs

?

not sure here if

needs

should be implicit

Don't you need

needs

for all use cases where another job is referred to?

That was exactly my question 🙂

Let's summon @mbonnin for that

Don't you need

needs

for all use cases where another job is referred to?

I can imagine a case where I want to access e.g. jobs ID somewhere in the logic

for yaml ? 😅

so I'd prefer to keep

needs

explicit for now

That said, I don't expect those actions to ever be touched again, so I'm not sure it's worth the complication. Maven Central / Nexus bureaucracy hasn't changed in years and years, probably since the beginning.

I can imagine a case where I want to access e.g. jobs ID somewhere in the logic

But that would be

job.id

, wouldn't it? Not

job.result

which then is

${job/this.id}.result

Ah, that's very cool, I'm surprised this isn't a first party thing actually

We too 🙂

Created this for tracking https://github.com/nexus-actions/create-nexus-staging-repo/issues/7. I'm a bit under the waters right now but we'll add that eventually

Would also be nice to finally have 1st level support for alternate DSLs, so that you don't need to generate the YAMLs from the Kotlins with this library but it would happen automatically on run

@mbonnin I can submit the PRs while you're sous l'eau. Will you have some time to review, merge & release? I'll do my best to avoid errors so review is aussi simple que possible.

Sounds like a plan!

❤️

we'll have another action with typings, yay!

I'm also thinking about making higher level stuff going forward, so one can call a function, easily change a few parameters, and get a full workflow for complicated stuff like publishing to Maven Central

do you mean adding such workflow builders to the lib, or having it in your project?

In a dedicated project, be it in the Splitties GitHub organization, or in typesafegithub.

please also check a case where you print out

job-id.result

in some job's step

> regarding having

needs

- I think what we need to check is if it's possible to use

my-job-id.result

alone, without

needs.

Yes, that was exactly my question, and my guess is, that it is not. Because if you don't

needs

it, it is also not guaranteed that it run before and finished already. And within the same job it also does not make sense. But we will see what Louis' experiments show. > I'm also thinking about making higher level stuff going forward, so one can call a function, easily change a few parameters, and get a full workflow for complicated stuff like publishing to Maven Central If you need some inspiration from excessive usage, you can have a look at https://github.com/Vampire/setup-wsl/blob/master/.github/workflows/test.main.kts 🙂

Mother-Of-God.jpg

@Vampire you should finally update the lib to 1.x

Yes, probably, but hey, it works. 😄

https://docs.github.com/en/actions/learn-github-actions/contexts#needs-context Should I make an enum?

How do we have it for step results?

An enum is probably not so ideal since it's not possible to override

==

and

!=

without a compiler plugin

You don't actually compare in Kotlin anyway, so that shouldn't be relevant?

It's about how typesafe and how cumbersome it is.

You could tackle that alongside 🙂

Not really

😭

That would break the API alongside

I meant adding step outcome context while adding job result context 😄

I don't like how everything is a String in there, and a solution is probably possible

As long as you can also just get the context reference string like I need it in that test workflow I linked. 🙂

I was thinking make a

Result

class and have

isSuccess()

,

isNotSuccess()

,

wasSkipped()

,

wasNotSkipped()

, etc

As long as it is flexible enough to also be used low-level as GitHub also likes to change this sometimes, or maybe add some status, or you might need it outside a

condition

like here: https://github.com/Vampire/setup-wsl/blob/master/.github/workflows/test.main.kts#L241

NEQ, EQ could work

But that's ugly 😄

Sorry, too much topics in this thread :D open to changes, but how about having separate threads?

Still the same topic

Not really many topics, just about how to nicely do outcome / result

Ah, ok

Alright, here is the PR: https://github.com/typesafegithub/github-workflows-kt/pull/1109

thanks, enqueued

infix didn't work out?

I didn't try. You want infix ``||`` & ``!=`` or just make

eq

and

neq

infix? @Vampire

🤷‍♂️

Let's try

eq

and

neq

for now

Thanks for the PR @louiscad! @Piotr Krzemiński is a new tag required for the action for the generator to pick up the typings? Is the DSL generator version-aware ?

I need to fix a few things @mbonnin, sorry I didn't check in my fork before sending the PR

No worries at all

Yes, at least in the current state you can have v1, v2, ... versions for the action. Hopefully you have a vX tag or branch that points to the release and not only vX.Y.Z, otherwise the action disqualifies anyway 😄

@Vampire yea, we haven't been the most rigourous in our release process so far so we have only tags and no specific convention 😕

The

v1

tag should probably be renamed to

v1.0

and

v1

recreated to point to whatever the latest is

I'm against branches in GitHub actions

I was talking tags @mbonnin

👍 was just realizing that 🙂

@mbonnin Can you undo my commit so I can re-send a proper PR?

just redo a pr on top of main?

Oh my... Is GitHub actually recommending referencing a moving tag? Isn't that breaking build reproducibility 100%?

GitHub acquired npm…

I mean they came up with yaml so I shouldn't be surprised I guess 😂

Exactly.

updating the workflows is cumbersome

It's a pet peeve of mine 😄

Nice!

Did some shuffling in tags and releases. Tags should be all good now: https://github.com/nexus-actions/create-nexus-staging-repo/releases/tag/v1.3.0

Alright, last 2 PRs done on my side : https://github.com/nexus-actions/drop-nexus-staging-repo/pull/3 https://github.com/nexus-actions/release-nexus-staging-repo/pull/4

Need to go AFK for ~30min, will do the merging and release in a bit

@mbonnin I think you're missing the

v1.3

tag

I'm against branches in GitHub actions

Oh my... Is GitHub actually recommending referencing a moving tag? Isn't that breaking build reproducibility 100%?

@mbonnin exactly and imho that is a total no-go. That's why I do not have a rolling tag for the major version, but a branch for the major version and made Piotr accept that for this action too. 🙂 I also don't like having build results in VCS. So I indeed have a branch for the major version and on release merge

master

into that branch, and add the build artifacts only in that branch which is at least a bit cleaner imho than a rolling tag and having the build artifacts in the normal branches. You can have a look at https://github.com/Vampire/setup-wsl if you like 🙂

I think you're missing the

v1.3

tag

Is that useful? I only kept

v1.1

and

v1.2

for backward compat but I don't think they should be actually used anymore. Just use the path version

vx.y.z

or the current major

v1

. Is there a need for the current minor as well?

Depends on your users, and / or your backwards compatibility policy 🙂

Oh I see, maybe it's not needed and v1 is enough, yes

backwards compatibility policy is semver

Then probably not

a branch for the major version and made Piotr accept that for this action too

nice! I switched to that as well

If I one day start a blog finally, I should write a post about how to properly version GitHub actions 😄

Alright, last 2 PRs done on my side

And all PRs should be merged and tags/branches pushed. Hope I didn't mess things up 🤞

Sorry for being not really active here, crazy time here! I see everything's going forward nicely :D

Alright, my 2PRs are there, your move ♟️ 😄

Thanks! Will review soon-ish

@Piotr Krzemiński I searched and reviewed the GitHub Workflows documentation, and needs is the only thing there for

result

of a

job

, and my previous workflow runs in publishing (or failing to) several projects to Maven Central confirm it is working as documented, so I see no point in trying a made-up, undocumented way. However, one interesting thing would be to check that the job looking at the result of another job indeed depends on said former job (via

needs

) when generating the YAML. If you have ideas on how to implement this, let me know, but what we have in the PR is already better than the status quo IMO.

@louiscad sorry, I didn't get what you meant here https://kotlinlang.slack.com/archives/C02UUATR7RC/p1700233748033889?thread_ts=1700111531.986899&cid=C02UUATR7RC - could you rephrase, give more context?

Upgrading is a bit cumbersome though, and commit hashes are less friendly than version numbers. So, yes, github-workflows-kt already supports version pinning, and yet, it's only part of the story to make it easy.

Client-side bindings generation will eventually let you refer to any ref of a given action, let it be a tag, a branch or commit hash :) Currently this mode supports only major version tags/branches