You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What GitHub Actions topic or product is this about?
Workflow Configuration
Discussion Details
Summary:
Currently, the choice input type for workflow_dispatch events in GitHub Actions supports only a flat list of options. Each entry in the options array serves as both the value displayed in the UI dropdown and the value assigned to inputs.<name> within the workflow.
This design limits usability in cases where a human-friendly label should be shown to users, but a different, machine-friendly value should be passed to the workflow logic.
Proposed Enhancement:
Extend the options field in workflow_dispatch choice inputs to support objects with distinct display and value properties.
Example Syntax
on:
workflow_dispatch:
inputs:
s3-bucket:
description: "Select an S3 bucket to deploy to"type: choiceoptions:
- display: "Development S3 Bucket"value: "s3://dev-bucket-name"
- display: "Production S3 Bucket"value: "s3://prod-bucket-name"
In this example:
The display key defines the text shown in the GitHub UI dropdown.
The value key defines the actual value assigned to inputs.s3-bucket in the workflow run context.
Motivation:
This enhancement would make workflows more intuitive and user-friendly for non-technical users, while retaining flexibility for automation and scripting.
Benefits include:
Improved readability in the Actions UI.
The ability to use descriptive labels for complex or sensitive values (e.g., S3 URIs, environment names, resource IDs).
Reduced risk of user error when selecting workflow inputs.
Current Workaround:
Currently, workflow authors must either:
Use cryptic, machine-oriented values as the only visible option text, or
Parse user-friendly strings into internal values within the workflow logic (e.g., via if statements or lookup maps).
These approaches introduce unnecessary complexity and reduce clarity for workflow users.
ActionsBuild, test, and automate your deployment pipeline with world-class CI/CDProduct FeedbackShare your thoughts and suggestions on GitHub features and improvementsWorkflow ConfigurationTopics about workflow files, YAML setup, job dependencies, and general workflow configuration issuesMiscGeneral discussions about GitHub Actions that don't fit other found themes.
1 participant
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Why are you starting this discussion?
Product Feedback/Feature Request
What GitHub Actions topic or product is this about?
Workflow Configuration
Discussion Details
Summary:
Currently, the
choiceinput type forworkflow_dispatchevents in GitHub Actions supports only a flat list of options. Each entry in the options array serves as both the value displayed in the UI dropdown and the value assigned toinputs.<name>within the workflow.This design limits usability in cases where a human-friendly label should be shown to users, but a different, machine-friendly value should be passed to the workflow logic.
Proposed Enhancement:
Extend the options field in
workflow_dispatchchoice inputs to support objects with distinct display and value properties.Example Syntax
In this example:
The
displaykey defines the text shown in the GitHub UI dropdown.The
valuekey defines the actual value assigned toinputs.s3-bucketin the workflow run context.Motivation:
This enhancement would make workflows more intuitive and user-friendly for non-technical users, while retaining flexibility for automation and scripting.
Benefits include:
Improved readability in the Actions UI.
The ability to use descriptive labels for complex or sensitive values (e.g., S3 URIs, environment names, resource IDs).
Reduced risk of user error when selecting workflow inputs.
Current Workaround:
Currently, workflow authors must either:
Use cryptic, machine-oriented values as the only visible option text, or
Parse user-friendly strings into internal values within the workflow logic (e.g., via if statements or lookup maps).
These approaches introduce unnecessary complexity and reduce clarity for workflow users.
Beta Was this translation helpful? Give feedback.
All reactions