Show workflow_dispatch input parameters in UI

[ahvigil]

Select Topic Area

Product Feedback

Body

For workflows with a workflow_dispatch trigger that take inputs, it would be nice to be able to see the branch and input parameters that a workflow run was executed with. This was previously raised at https://github.com/orgs/community/discussions/8303 and the accepted answer there provides a workaround by putting params of interest into run-name for display in the action summary view, but this becomes cumbersome for workflows with more than a small number of relatively simple inputs that easily fit into a short text field.

Would be great if there was some way to inspect params for a particular workflow execution under https://github.com/<org>/<repo>/actions/runs/<run_id>/. Perhaps a panel under Run details?

[Wouter-Vugt-Shell]

It is a rather big gap for such a product to not be able to list which values are used to drive automation. Anybody working at any serious level with GHA will need this and that it is missing really stumps my brain. Is there effort underway to add this? Can I provide such effort myself?

Thanks!

[austinpray-mixpanel]

It's worth noting that jenkins has this capability

We have resorted to echoing out the important workflow dispatch parameters in each workflow. It's very tedious

[cellard0or]

Having the same problem. This needs to change, non-reproducible builds are a no-go.

[priley86]

Agreed. Very odd these are not yet visible in the UX.

[jeroenhabets]

W00t! Seems like a Table Stake and Quick Win combo to me!

Not just Jenkins but any build tool I know over the last 25 years has this info readily available as it's essential for build/deploy management, hence Table Stake.

Adding the info that triggered the job in the UI should be readily available and hence cannot be a major story, hence I assume this is a Quick Win.

This and more fine-grained UAC are the only key impediments for fully embracing GHA.

[LanderV-Vintecc]

I need this as well.

[deepbrook]

If this is implemend, please, please pleeeeeease also implement the option to declare a value as sensitive, so its value isnt leaked this way. thanks.

[austinpray-mixpanel]

Pretty sure this is covered by https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#masking-a-value-in-a-log

[deepbrook]

It isn't by default, if inputs are to be visible in the UI, I'd assume. Unless I misunderstand "UI" in the context of the posts above.

[ahvigil]

github already masks things in the env that seem like they could be sensitive when looking at task logs, so I assume they could use the same mechanism here. I agree that there needs to be a way to explicitly mask these too.

[nnellanspdl]

This seems like basic functionality. We'd like to see the input values that were used to run a particular instance of a workflow.

[klalumiere]

Something a bit more subtle: you can start the workflow with a step like

- name: Parameters
  env:
    PARAMETERS: "${{ tojson(inputs) }}"
  run: echo See env for the parameters

and then the parameters will be available in the logs. I use an environment variable because of this blog post.

[harsha549]

It doesn't make any sense as basic as this is ignored. I wish I could see an update about it.

[prabhatkgupta]

Yes this is highly needed. There is a genuine need & a lot of developers are asking for it. Can someone share an update?

[Mr-Saikiran]

It's been an year, and am still following this thread to check the updates..

Edit:

For my problem, I solved it with a workaround using choice type in inputs using workflow_dispatch.

This gives an UI to pass inputs but all the values should be added before in the options. Doesn't satisfy fully but atleast somewhat UI.

name: Config

on:
  workflow_dispatch:
    inputs:
      environment:
        type: choice
        required: true
        default: 'qa'
        options: 
          - qa
          - dev
      apihost:
        type: choice
        required: true
        default: 'fqdn-qa'
        options:
          - https://fqdn-qa
          - https://fqdn-dev

permissions:
    id-token: write
    contents: read
    packages: read

jobs:
  config:
    uses: org/config.yaml@v1
    secrets: inherit
    with:
      apihost: ${{ github.event.inputs.apihost }}

[fyelci]

I need this as well. It would be great to prioritise

[nghongphuong94]

Please add this feature. Even we can workaround by print the inputs out in one step, it's really painful that you can not see the params from the list of runs, but you have to click into one to check the params, then go back to the list if it's not the run you finding for 🤷‍♂️.

Such a very bad experience.

[shayki5]

Any news please? it's super basic feature...

[shayki5]

I've created a simple action which log the inputs to the UI and add them to the summary:
https://github.com/marketplace/actions/print-workflow-dispatch-inputs-and-env-vars

[jeroenhabets]

I've created a simple action which log the inputs to the UI and add them to the summary: https://github.com/marketplace/actions/print-workflow-dispatch-inputs-and-env-vars

Thank you @shayki5 for sharing yet another workaround but note as others have said many times before: this table stake should finally be readily supported by GitHub Actions @grandmas-favorite

[shayki5]

I've created a simple action which log the inputs to the UI and add them to the summary: https://github.com/marketplace/actions/print-workflow-dispatch-inputs-and-env-vars

Thank you @shayki5 for sharing yet another workaround but note as others have said many times before: this table stake should finally be readily supported by GitHub Actions @grandmas-favorite

I totally agree!

[tpesout]

Agreed, this is a necessary feature

[aswen]

It would be very useful to have this feature.

[elgehelge]

I think this at the beginning of every job, but not sure.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[nebuk89]

ooh I missed commenting on this one!
This is cool feedback and we are aware 🙏 thank you for all the patience and ongoing engagement.

We are going to do a batch of improvements to workflow_dispatch this year and I will ensure this one is included in the list of potential improvements

[dzuelke]

Lovely to hear that workflow_dispatch is getting some love, @nebuk89! May I suggest adding multi-choice inputs to the list? ;) See discussion at actions/runner#2076 (and specific example at actions/runner#2076 (comment))

[mmedvedtoken]

Looked at the roadmap up above, no issue that seems related. @nebuk89 can you reply with ETA/issue on roadmap?
Just printing to the build log seems simple and really should've been part of MVP. Having a UI would be a fast follow on.

[rbarad]

Hi, is there any ETA for this? When it will be available for enterprise users? This will be a very helpful feature

[dsixdkt]

@nebuk89
Thank you for taking this issue into account. It would be a great improvement for everyone.
Do you have any news on this subject?

[aviborg]

Not sure if I'm missing out something here but isn't this available with workflow_dispathc as this:

on:
  workflow_dispatch:
    inputs:
      runner_label:
        description: 'Specify runner to run this workflow on'
        required: true
        default: 'corp'
      os_image:
        description: 'Specify base OS image'
        required: true
        default: ubuntu:latest

Then you get this dialog box when you click the Run workflow dropdown:

Then you access the variables like this:

      - name: Get variables
        run: |
          echo "${{ github.event.inputs.runner_label }}"
          echo "${{ github.event.inputs.os_image }}" 

[aviborg]

Perhaps a maintainer could consider close #49648

[ahvigil]

@aviborg no, that is the UI for starting a new workflow via workflow dispatch. Once the workflow has been triggered, there is no way to see what parameters a running or completed workflow was triggered with so this issue is still relevant

[jeroenhabets]

@aviborg careful reading of this issue would have shown a) what it is actually about (thanks @ahvigil), and even there that b) many workarounds have been available but those are not the proper solution, hence the many 👎 .

[dannoso]

Any update on this? I find very odd a such huge product may miss this basic feature. I was puzzled at the beginning and I blamed myself for not finding the inputs This is an unbelievable miss for Github developers and QA team. Also i cannot believe it took 3 years just to be inserted into the backlog. Please fix this ASAP because it is very hard and time consuming digging into the logs especially when you do not own the pipeline itself and cannot use any workaround to show the inputs. Thanks.

[TommasoPetrolito]

please add this feature

[nhockcuncon77]

That’s a really thoughtful suggestion and I totally agree that having visibility into the input parameters used in a workflow_dispatch run would make debugging and traceability much easier. The workaround of embedding inputs into the run name is clever, but not scalable once workflows have multiple or nested inputs.

Having a dedicated section under the Run details view (maybe a small “Inputs” panel next to Environment or Summary) would be perfect for teams that rely on manual triggers or parameterized CI/CD workflows. It would also improve auditability for compliance workflows where teams need to verify exactly what parameters were used.

It might also be nice if the run metadata were exposed via the Actions API so we could programmatically list or filter runs by input combinations.

[robbertkandy-create]

That’s a really valid point — having direct visibility into input parameters for each workflow run would make debugging and auditing much easier, especially in larger projects with multiple contributors. The current workaround through run-name definitely helps, but it’s not scalable once you start dealing with complex configurations or dynamic inputs.

It would be great if GitHub added a dedicated panel under “Run details” to show this data cleanly, perhaps even exportable for CI/CD tracking. I came across a similar case while optimizing some background processes (https://7brewssecretmenu.com/)
— transparency in parameters really does simplify automation management.