Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Core feature request] Add support to Workflow Dispatch Inputs #811

Open
LeoColman opened this issue May 1, 2023 · 4 comments
Open

[Core feature request] Add support to Workflow Dispatch Inputs #811

LeoColman opened this issue May 1, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@LeoColman
Copy link
Contributor

LeoColman commented May 1, 2023

Discussed in Kotlin's Slack: https://app.slack.com/client/T09229ZC6/C02UUATR7RC/thread/C02UUATR7RC-1682902161.628869

What feature do you need?
Workflows Dispatch Inputs:
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatchinputs

Do you have an example usage?

https://github.com/kotest/kotest/blob/80bc809be1e0452dc1f3ee2e67aec2f6c7f6c251/.github/workflows/release_base.yml#L15


env:
   RELEASE_VERSION: ${{ inputs.version }}
   OSSRH_USERNAME: ${{ secrets.OSSRH_USERNAME }}
   OSSRH_PASSWORD: ${{ secrets.OSSRH_PASSWORD }}
   ORG_GRADLE_PROJECT_signingKey: ${{ secrets.SIGNING_KEY }}
   ORG_GRADLE_PROJECT_signingPassword: ${{ secrets.SIGNING_PASSWORD }}
   GRADLE_OPTS: -Dorg.gradle.configureondemand=true -Dorg.gradle.parallel=false -Dkotlin.incremental=false -Dorg.gradle.jvmargs="-Xmx3g -XX:MaxMetaspaceSize=756m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8"

Is there a workaround for not having this feature? If yes, please describe it.

Yes. One can use WorkflowDispatch normally, and use expr { github["event.inputs.XXXX"]!! } to get the value when they need it.

workflow(
  name = "Publish",
  on = listOf(
    WorkflowDispatch(
      mapOf("RELEASE_VERSION" to Input("The release version", true, String))
    )
  ),
  sourceFile = __FILE__.toPath(),
  env = linkedMapOf(
    "OSSRH_USERNAME" to expr { OSSRH_USERNAME },
    "OSSRH_PASSWORD" to expr { OSSRH_PASSWORD },
    "ORG_GRADLE_PROJECT_signingKey" to expr { ORG_GRADLE_PROJECT_signingKey },
    "ORG_GRADLE_PROJECT_signingPassword" to expr { ORG_GRADLE_PROJECT_signingPassword },
    "RELEASE_VERSION" to expr { github["event.inputs.version"]!! }
  )
)
@LeoColman LeoColman added the enhancement New feature or request label May 1, 2023
@krzema12
Copy link
Member

krzema12 commented May 2, 2023

As you've already noticed, some support for it is already in place (I forgot about it when asking you to create this request, sorry!):

public data class WorkflowDispatch(
val inputs: Map<String, Input> = emptyMap(),
override val _customArguments: Map<String, @Contextual Any> = mapOf(),
) : Trigger() {

From what I understand, you're missing a type-safe way of referring to the input values, right? On GitHub, the inputs are available within inputs context, and the library already supports several other contexts, see here. It should be enough to extend the library to support something like:

workflow(
  name = "Publish",
  on = listOf(
    WorkflowDispatch() // After the change, the inputs wouldn't be defined here...
  ),
  sourceFile = __FILE__.toPath(),
) {
    // ...but here instead. It's in line with what's already possible with env vars and secrets.
    val RELEASE_VERSION by Contexts.input(required = true, type = String)

    // ...
    // inside a job that actually uses the secret:
    run(
        name = "Release",
        env = linkedMapOf(
            VERSION to expr { RELEASE_VERSION },
        ),
        command = "./gradlew release",
    )
}

WDYT?

@krzema12
Copy link
Member

krzema12 commented May 2, 2023

@jmfayard do you recall why we originally haven't implemented it this way?

@jmfayard
Copy link
Collaborator

jmfayard commented May 2, 2023

@krzema12 we probably implemented WorkflowDispatch before I implemented the typesafe expressions,
meaning we didn't design typesafe inputs at all

@LeoColman
Copy link
Contributor Author

Yes, I think the syntax you presented seems what I expect @krzema12 . Interesting to know it predates the typesafety

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants