Github workflow_dispatch input dynamic values

[Suchit8]

Can we have a feature in the GitHub actions to populate the workflow_dispatch input values dynamically, maybe using some API response or using other GitHub workflow outputs?

Ex: Current workflow
on:
workflow_dispatch:
inputs:
SOURCE_REGION:
type: choice
default:
required: true
options:
- us-west-1
- us-west-2
- us-east-1
- eu-west-1

Ex: Feature looking for-
on:
workflow_dispatch:
inputs:
SOURCE_REGION:
type: choice
default: [ SOME FALLBACK INPUT ]
required: true
options:
- {{ API_RESPONSE[0] }}
- {{ API_RESPONSE[1] }}
- {{ API_RESPONSE[2] }}
- {{ API_RESPONSE[3] }}

[ethomson]

That's a neat idea that I hadn't considered. We'll put this on the backlog. Thanks for the feedback, @Suchit8.

[64J0]

+1. Also asking for updates regarding this feature

[krarjun90]

@ethomson is this really in the backlog?

[kenshin17]

@ethomson Any new news on this feature?

[aidanheerdegen]

@Suchit8 wrote:

This is good to feed an inputs but its not dynamic, it is something that one have to hardcord in your workflow file.

Agreed, but it is related. It is good practice and allows for the hard-coding in one place and the values can be re-used in multiple places in the workflow file, which is our use-case.

[anjalichhabra-clarks]

@ethomson Is this feature now live ?

[allcloud-sahar-hagbi]

Is there a feature request for this?

[pkernevez]

Is there a feature request for this ? (too)

[rgoodwin]

This (or something like it) is really important to support dynamic environments. It's getting pretty common to spin up environments for a single branch or testing of a release. Esp with microservices it can become a lot of work to update N number of workflow dispatch input choices.

While it could be environment variables that would be limiting and in a way bring one back to the same issue. Having to update data somewhere. One thing that might help a lot of users is to support a dynamic environment field in the workflow_dispatch that was dynamically generated from environments declared at the repo level.

[cschleiden]

👋

One thing that might help a lot of users is to support a dynamic environment field in the workflow_dispatch that was dynamically generated from environments declared at the repo level.

Have you seen the type: environment input field - https://github.blog/changelog/2021-11-10-github-actions-input-types-for-manual-workflows/?

[Nokel81]

It also would be very useful to be able to fill out the options of the dropdown based on the tags of some other repository.

[tuhin-sheikh-cmc]

I was looking for something like this too so that we can trigger deployment from the latest tags created.

[amazingandyyy]

this feature is very needed, in our use case, we just want to have a list of option which is the file name listed from the root, for example make the output of ls -l to be input options for a GHA run

[kuczko]

Hello,
I would say we should have release version as one of dynamic choice input types. That way we can have a button for release deployment and we can select release number from drop-down list.

[AmitKatyal-Sophos]

I've a slightly different use-case. Any thoughts on handling the same ?

on:
workflow_dispatch:
inputs:
deployment_env:
type: choice
default:
required: true
options:

• dev
• qa
• prod

deployment_region:
type: choice
default:
required: true
options:
${Region}

Here, ${Region} list should be populated based on the dev/qa and prod env.

[guenoledc]

In the meantime, has anyone tried to update the workflow file (its a yaml after all) from another event, committing it to the repo, so when end-user want to use the workflow_dispatch the values are in there.

I know it is a bit arsh design but would it work ?

[Nokel81]

No. What I ended up doing was using the repository_dispatch event (making sure that I used a child field because GitHub also thought it was a GREAT idea to limit the number of to level field in the payload of that event) and just writing a custom CLI.

[guenoledc]

I see, So to execute the workflow you do not use the github UI, right ?

If so obviously it is simpler to control.

What about a github pages app so it all stays in github ?

[Nokel81]

I don't know about that. This was just work around that found.

[shaypi]

Is there any update on the feature request?

As a result, workflow dispatch will be a much more powerful tool

[camilla-storytel]

This feature would be super useful for me as well!

[bvtk]

+1

[dil-kpogany]

+1

[twskipper]

+1

[jawnclarke]

+1

[MahmoudMabrok]

+1 (missing this feature, is the only feature I miss after migrate from Jenkins to Github action, will be nice to be added)

[fede843]

+1

[mdbollman]

+1

[man0s]

+1

[dautushenka]

+1

[mihran-zoetis]

+1

[nikhilkoduri-fuga]

+1

[humzam]

Hello, any update on this request to set dynamic values for workflow_dispatch? cc @ethomson

[shobaki]

Started learning GHA and workflows just a few hours ago, and now ended up here. Either I'm missing something, or this is a desperately needed feature!

+10

[vishwasc20]

Any update on this feature request would be really helpful. Been looking at this from 2 years 🙂.
If we are able to run script in choice param, would make worflows alot simpler

[maxnorth]

This isn't the most elegant option, but a decent workaround for this would be to have the workflow validate the input, and print the list of valid options on error.

[crcasiswho]

+1

[TristanB1994]

+1

[surya-sigtech]

Any updates on the issue? It appears to be growing in importance for the community's needs.
Any insights or workarounds will be helpful.

[JanisOrlovs]

This feature would be last nail in Jenkins coffin

[Pea1594]

Can we have a feature in the GitHub actions to populate the workflow_dispatch input values dynamically, maybe using some API response or using other GitHub workflow outputs?

Ex: Current workflow on: workflow_dispatch: inputs: SOURCE_REGION: type: choice default: required: true options: - us-west-1 - us-west-2 - us-east-1 - eu-west-1

Ex: Feature looking for- on: workflow_dispatch: inputs: SOURCE_REGION: type: choice default: [ SOME FALLBACK INPUT ] required: true options: - {{ API_RESPONSE[0] }} - {{ API_RESPONSE[1] }} - {{ API_RESPONSE[2] }} - {{ API_RESPONSE[3] }}

[satheesh-raja]

Is there any update on this?

[Mdanford97]

+1