Hello guys! Just started playing around with this ...

# github-workflows-kt

[LeoColman]

Hello guys!
Just started playing around with this project, and I find it very nice!

I'm having some troubles to understand why this action is failing. Perhaps you can help me?
https://github.com/LeoColman/Petals/blob/main/.github/workflows/release.main.kts

Error: Cannot locate a Gradle wrapper properties file at '/home/runner/work/Petals/Petals/gradle/wrapper/gradle-wrapper.properties'. Specify 'gradle-version' or 'gradle-executable' for projects without Gradle wrapper configured.

https://github.com/LeoColman/Petals/runs/7214100461?check_suite_focus=true

[Piotr Krzemiński]

Hi Leonardo, thanks for the nice words!

About the failure, did you experience it as well before introducing the Kotlin DSL? at first glance on the go, I don't have a clue why it fails

[LeoColman]

No, although it's a new pipeline.

Maybe I can try to convert a simpler one first, such as the release one

[Piotr Krzemiński]

I'd start debugging it from YAML, not Kotlin DSL

[LeoColman]

I migrated the linter script to check if the issue is there, and it's not.
https://github.com/LeoColman/Petals/commit/8a71cbd7b8f8c1f2c1372ea5dc52e49a13cf08d0

[Vampire]

In your job you setup java and then execute gradle, but you don't checkout the code, so no gradle files are present and the action complains

[LeoColman]

Ah, there you go, that's it

[Piotr Krzemiński]

We could try emitting some kind of warning if the user doesn't checkout the repo first, but then some false positives may appear

[Vampire]

If you do, please make it at least disableable for the false positive cases

[LeoColman]

I think what we could do is if you try to build without checking out

[LeoColman]

Running a GradleBuild necesserily means checking out the code first

[Vampire]

Usually, yes.
But you could also have an action that generates a build first.
Or you could download the code from somewhere else.
Or whatever.
You could for example checkout the code from SourceForge SVN and then build it, only using GitHub as CI.
Maaaany possible cases.
Just the typical means you need to checkout before you build.

[Vampire]

GHA also does not warn you if you write YAML directly and don't have it.
I'm not sure whether a DSL on top of it should.
And if so, it should at least be disableable.

[LeoColman]

Good point, if GHA don't do it, perhaps we shouldn't do it here

[LeoColman]

Although adding it as a configurable value is interesting, like overriding the system env?

[Vampire]

Not sure what you mean.
I meant if such a warning is displayed, there should be a way to disable it on a case-by-case basis for the false-positive cases.

[LeoColman]

Yes, I was thinking on how to add the disable part.
Perhaps adding it as a system environment variable or as a property

#kotest does this often, adding a sysprop flag to enable/disable something
https://github.com/kotest/kotest/blob/a0b379909e1fa8e74818c01a0dc73e40b8cf1676/kot[…]tlin/io/kotest/engine/config/applyConfigFromSystemProperties.kt

[Vampire]

Overuse of env variables and system properties is not good. And in this case probably wouldn't be appropriate anyway just probably. They are too global for a targeted switch and also may be hard to influence when maybe GitHub eventually adds native integration. But how to add it most appropriately probably depends on where and how the check is made. If for example the Gradle action does the check, it should have an option to disable it. If the job implementation dies the check, that should probably have the option, ...