GitHub Actions | Show Parameters in Preview

[brettrowberry]

I have a GitHub Actions workflow that defines a workflow_dispatch that takes some inputs, e.g.

name: CICDon: push: branches: - master - cicd-*workflow_dispatch: inputs: deployment_git_rev: description: 'SHA or ref (branch, tag, other named thing) to deploy'required: truedefault: ''target_release_channel: description: 'Release channel (`Pre-prod` or `Prod`)'required: truedefault: 'Pre-prod'services: description: 'Space-separated list of services to deploy (e.g. dog cat). ALL to deploy all services'required: truedefault: '' ...

When I run it, I can see the workflow name, run number, and that it was manually run by me. All very helpful!

I wish I could see the branch it was run on and the parameters passed to the workflow run. Is there a way to do this, or would a change need to be made?

[ethomson]

Hi @brettrowberry - now that you mention it, we don't surface this information very easily. I'll look into how to make this easier for you. This is great feedback, I appreciate it.

[jpcastberg]

This is much needed context when viewing a workflow run. How can I debug a failed workflow when I can't even see the arguments passed to it??

[matosjoa]

Any news? really need this one

[kota65535]

Any progress? This feature is highly needed

[Wouter-Vugt-Shell]

No progress, but a rather important need. We need to know what values are used to start a workflow to find why it broke. This seems rudimentary and very very basic.

[harsha549]

Did we ever get an update about it

[ashwinv11]

Any update on this feature? This is sorely missed and one of the biggest reasons why we're not considering moving deployment workloads from Jenkins to GHA.

Sort of related to having better visibility into the inputs provided into a workflow_dispatch run but, Jenkins has a rebuilder plugin that we use heavily to re-run a job with the same set of inputs. It also allows us to edit specific inputs before re-running, that way we can override just one input but not need to fill out the entire input form each time we're trying to trigger a run.

This plugin plays nicely with Jenkins "parameters" where we can view the inputs provided to the run:

[ChristopherHX]

GitHub recently added the run-name property (https://github.blog/changelog/2022-09-26-github-actions-dynamic-names-for-workflow-runs), which allows you to add the inputs and branch name to the run name displayed in the UI

For example:

on: workflow_dispatch: inputs: test: type: choiceoptions: - mychoice - a - bb: type: booleanpush: run-name: ${{github.event_name == 'workflow_dispatch' && format('CI/CD-{0}-branch-{1}', tojson(inputs), github.ref_name) || '' }}jobs: testa: runs-on: ubuntu-lateststeps: - run: ${{tojson(inputs)}}shell: cat{0} - run: ${{tojson(github.event.inputs)}}shell: cat{0}

This is the result

|| '' in the run-name expression means use the default run name for other workflow events

[ahvigil]

cool workaround but its pretty gross that you have to stuff json into a name to workaround github action UI limitations

[kota65535]

Should this be marked as resolved? Frankly, this is a dirty workaround.

[brettrowberry]

I did something like the snippet below and it’s perfect (and no JSON displayed):

run-name: ${{github.event_name == 'workflow_dispatch' && format('Manual{0} |{1} |{2}', inputs.deployment_git_rev, inputs.environments, inputs.services) || '' }}

which can produce something like:

Manual my-branch | dev stage | adder subtracter

[brettrowberry]

I filed this as an issue and a feature was added that perfectly meets the need I expressed.

[ahvigil]

I've opened a separate discussion for cases where using run-name is not an acceptable solution

[brettrowberry]

@ethomson@ChristopherHX The run-name property meets my needs. I consider this resolved.

@ashwinv11 Pre-filling with previous inputs feels like a separate concern.

[Alex17Li]

Another possible workaround is to log the parameters as an output after you click into a job

jobs: setup: runs-on: ubuntu-latest steps: - name: Display parameters shell: bash run: echo "${{format('<h1>Parameters</h1><p>{0}</p>', tojson(inputs)) }}" > "$GITHUB_STEP_SUMMARY" ... other steps 

Here's an example of what it might look like.

[Alex17Li]

Also, if you would like to format it as a table, you can install the jq library and change the output format into markdown table syntax with the following steps.

 - name: Install jq run : | apt update apt install -y jq - name: Display parameters this workflow was called with shell: bash run: printf '|Parameter|Value|\n|------|------|\n' >> $GITHUB_STEP_SUMMARY && jq -r 'to_entries | map("|\(.key)|\(.value)|") | join("\n") | @text' <<< '${{tojson(inputs)}}' | sed 's/\\n/\n/g' >> $GITHUB_STEP_SUMMARY 

We just print the markdown table header, then parse key value pairs with jq and format them with the markdown table | character separating them. Then we join the lines with \n and convert to text to remove the quotes. Finally we convert literal '\n' that appear in some versions of bash to actual newlines. You can modify this to, e.g. print one parameter per line without a table if you prefer.

Example output:

[shayki5]

You can use my action which print the inputs to the logs and can add them to the summary:
Print Workflow Dispatch Inputs

[m-s-abeer]

You can use this simple re-usable action to directly print the input params to the GHA summary:-

steps: - name: Update GHA Summary with Workflow Inputs uses: m-s-abeer/update-gha-summary-with-workflow-inputs@v1

Marketplace link:- https://github.com/marketplace/actions/update-gha-summary-with-workflow-dispatch-input-params
Example SS:-

https://github.com/marketplace/actions/update-gha-summary-with-workflow-dispatch-input-params

[jumarko]

I think this should be re-opened.
It's an important troubleshooting facility and, as far as I can see, none of the approaches mentioned here is really native / satisfactory.

[SmithStevenO]

This seems like a pretty glaring omission in the github workflow product design, and encouraging this kind of shoddy workaround and ugly third party addins isn't really acceptable in a product which claims to be professional-grade. I mean, if it were a free open source thing maintained by volunteers I'd kind of sympathize, but you have paying customers and a paid engineering team, and I think it's reasonable to have higher expectations.

[ahvigil]

I felt the same way and opened a separate discussion for this long ago at https://github.com/orgs/community/discussions/49648. Sadly it remains unresolved but at least its still open

[r-i-v-a]

I would also like to see this feature supported natively in GHA.