Open krzema12 opened 7 months ago
Discussion along with some suggestions: https://kotlinlang.slack.com/archives/C02UUATR7RC/p1712389327584009
New take on the API:
projects.fooBar.baz.someTask
projects["foo-bar"]["baz"]["task"]
, and if someone attempts to access a project/task that doesn't exist, it would fail at Kotlin script runtime, so still better than GitHub workflow runtime
Problem
Currently, the only way of calling a specific Gradle task is to give it as string, e.g.: https://github.com/typesafegithub/github-workflows-kt/blob/7f4b41b5156d811a0d129ade49ebb64569d85ded/.github/workflows/release.main.kts#L48
It requires great attention to type them correctly. It's also risky to keep these as strings with regards to automatic dependency updates. E.g. see https://github.com/gradle-nexus/publish-plugin/releases/tag/v2.0.0:
In this particular example, we don't call the task that was renamed, but if we did, Renovate would allow merging such change. The worst thing is that it would be caught at the moment of running the release workflow, which currently e.g. for github-workflows-kt happens once a month.
Idea
In the spirit of https://docs.gradle.org/current/userguide/kotlin_dsl.html#type-safe-accessors.
Rough notes, nothing formal:
./gradlew tasks --all
returns a list of tasks in a format like [1], there's also Gradle tooling API. We could extract the task hierarchy from there, and generate Kotlin type-safe accessors, e.g.jit-binding-server:run
would map to such Kotlin code:jitBindingServer.run
--no-configuration-cache
and other free-form argumentsproject1
andproject2
expose arun
task, both projects should probably implement a common interface whererun
in both cases is the same property in terms of APIExample
Before:
After (rough idea, subject to discussion):
[1]