Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Type-safe Gradle task accessors

Ouverte
#1,350 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
github-actions, kotlin

Piste de recherche

Start with the referenced .github/workflows/release.main.kts lines 45-48 and inspect the output of ./gradlew tasks --all, then compare the Gradle tooling API. The issue names no implementation files or tests; done would require an agreed design for generated project and task accessors, unsafe task references, extra flags, and shared tasks across projects.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement

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:

Backward incompatible changes
  • closeAndReleaseStagingRepository has been renamed to closeAndReleaseStagingRepositories for consistency

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
  • in the GitHub workflow using the Kotlin script, we would have a type-safe wrapper over Gradle that would allow passing only tasks defined in the previous step (+a way to refer to a task in an unsafe, string-based way), along with being able to pass extra arguments like --no-configuration-cache and other free-form arguments
  • sometimes we want to run the same task for several projects, e.g. when we loop across them (ref). Ideally the proposed feature would allow it, e.g. by understanding that if project1 and project2 expose a run task, both projects should probably implement a common interface where run in both cases is the same property in terms of API

Example

Before:

val librariesToPublish = listOf(
    ":shared-internal",
    ":github-workflows-kt",
    ":action-binding-generator",
)

librariesToPublish.forEach { library ->
    run(
        name = "Publish '$library' to Sonatype",
        command = "./gradlew $library:publishToSonatype closeAndReleaseSonatypeStagingRepository --no-configuration-cache",
    )
}

After (rough idea, subject to discussion):

val librariesToPublish = listOf(
    projects.sharedInternal,
    projects.githubWorkflowsKt,
    projects.actionBindingGenerator,
)

librariesToPublish.forEach { library ->
    runGradle(
        name = "Publish '$library' to Sonatype",
        tasks = listOf(
            library.publishToSonatype,
            tasks.closeAndReleaseSonatypeStagingRepository,
        ),
        flags = listOf(noConfigurationCache),
    )
}

[1]

> Task :tasks

------------------------------------------------------------
Tasks runnable from root project 'github-workflows-kt-monorepo'
------------------------------------------------------------

Application tasks
-----------------
automation:code-generator:run - Runs this project as a JVM application
jit-binding-server:run - Runs this project as a JVM application
jit-binding-server:runShadow - Runs this project as a JVM application using the shadow jar
jit-binding-server:startShadowScripts - Creates OS specific scripts to run the project as a JVM application using the shadow jar

Build tasks
-----------
assemble - Assembles the outputs of this project.
action-binding-generator:assemble - Assembles the outputs of this project.
automation:code-generator:assemble - Assembles the outputs of this project.
github-workflows-kt:assemble - Assembles the outputs of this project.
jit-binding-server:assemble - Assembles the outputs of this project.
maven-binding-builder:assemble - Assembles the outputs of this project.
...
Langage dominant
Kotlin
Étoiles
665
Forks
30
Merge moyen
4 j 19 h
PR mergées (30 j)
5

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de typesafegithub/github-workflows-kt

Toutes les issues de typesafegithub/github-workflows-kt

Issues similaires

Plus d'issues Kotlin

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.