I find the

uses

api not very intuitive (although it follows GitHub convention)

uses(
            name = "Download common artifact",
            action = DownloadArtifactV2(
                name = "common-artifact",
                path = "python",
            )
        )

I was thinking about adding this syntactic sugar

fun step(name: String, condition: String? = null, action: () -> Action)

so that we can do something like this

step("Download common artifact") {
            DownloadArtifactV2(
                name = "common-artifact",
                path = "python",
            )
        }

Is something still missing in my PR? https://github.com/krzema12/github-actions-kotlin-dsl/pull/62

I was surprised how easy it is to break the compiler for Kotlin scripts It throwed two times

error: backend Internal error: Exception during IR lowering

File being compiled: /Users/jmfayard/tignum/backend-tignum-x/.github/workflows/build.main.kts

then you no idea what line is causing the problems and have to ressort to trials and errors In my case it was those two snippets:

fun secret(variable: String): String =
    "\${{ secrets.$variable }}"

and

data class Step(val name: String, val action: Action)

infix fun String.does(action: Action) = Step(this, action)

hi @jmfayard , thanks for implementing all these features you miss in the lib! you're really on fire with the contributions 🔥 please let me know once you think you've got all the features that you need in your workflows, then I'll prepare a release

I plan on migrating our large project to use this library today. Fingers crossed

how does one get/set an id of a specific step?? Can I get outputs of a certain step?

@andylamax do you need any other feature or an action wrapper to support your workflows? I could add them into the next release to speed things up

thinking of adding a utility for multi workflow outputs, could use arguments passed to the script to have it print out the correct workflow and without args it will just write all the yaml files

Hi everyone, I’m trying to setup a workflow to deploy my KMM iOS app. But it’s fail when doing

xcodebuild clean archive

comman, it failed to execute the run script. Do I need to setup something related with Java or gradle on my step?

if we could rename the channel to #github-actions-dsl that would be more clear..

Wild thoughts about supporting reference of other steps/jobs: I think we could have a type wrapping a reference to a previous job or step, with

or

and

and

functions/extensions, plus maybe other operators, and that would allow the library to keep track of which values are referenced, and automatically add the right

needs

clauses.

@jmfayard this might interest you too: https://github.com/krzema12/github-actions-kotlin-dsl/pull/105

Hi everyone, i have question about github actions, but not necessarily the kotlin-dsl thing. sorry if this is not the right place? feel free to let me know where i should discuss this. When setting up actions for iOS, i need to execute

./gradlew assembleXCFrameworks

first and that takes so much time, since I also have to do this on macOS vm, it cost much more as well. Is that common? or is there any work around to cut the time to run that gradle task? Thanks before. 🙏

with kotlin 1.6.20 we can maybe have the user pass

__FILE__

into

toYaml

and

writeToFile

functions.. then we can locate the current script and find the target file no matter what directly the script gets executed from.. too bad there is no good way to get it at runtime in the library..

just asking but the difference bwetween

println(workflow.toYaml())

adding a newline at the end of the file when piped into the yaml and

workflow.writeToFile()

not doing so is not so important right? .. we could make

writeToFile()

add a newline too, just to make it more unified (also some editors show warnings on files without trailing linebreak) i guess its bad form to not have that..

detekt is annoying..

EndToEndTest

is over 600 lines now and that apparently a problem..

annoying that the test report does not show the diff, had to boot into windows, fix the obvious issue (forgot to call the

invariantSeparatorsPathString

in one spot) anyways.. now all the checks pass finally

My Saturday hackathon: Automatically generate your Kotlin script from your existing YAML workflow https://github.com/krzema12/github-actions-kotlin-dsl/pull/117

it would be so cool to have a way for the actions owners to specify typings in action.yml... then as we encourage them to do it, we could get rid of the typings in our wrapper generator, and adding such wrapper generator would mean literally a single line of code. Any thoughts? It's not an easy task, it would mean establishing some kind of standard

Small thing: why does the consistency check contains

sudo snap install --classic kotlin

? Kotlin is installed by default on GitHub actions images

Is it possible to publish a 1.0-SNAPSHOT version of the library to mvaenLocal() and to use it then in a Kotlin script?

just discovered a similar library to mine: https://github.com/nefilim/kotlin-github-actions-dsl - I'm going to talk to the author so that we can unite our forces 🙂

this is probably not the most stble way to use the dsl:

@file:Repository("<https://jitpack.io>")
@file:DependsOn("com.github.nikkyai:github-actions-kotlin-dsl:main-SNAPSHOT")

when merging the jitpack PR i would suggest people to pin their dependency to a commit hash instead of a branch name to avoid the consistency check failing when branch

main

is

moving fast and breaking things

😛

i stumbled over the fact that

job.name

is not the same field as

Job(name=)

as what the dsl calls name is actually the id.. and name can be set as a display property.. maybe something we would like to fix earlier rather than later..

I'm sorry 😅

Based on comments in other channels, a Gradle integration via plugin which has a task which can be configured to be attached to the assemble lifecycle task (optional via prop) plus cacheable can be a feature request. This allow removing the need of having kotlin installed. So having both options, Kotlin and Gradle, would help the adoption of this library