Ability to change a run name dynamically (after the run starts)

[alainrodz]

Select Topic Area

Product Feedback

Body

There is the "run-name" which allows an input/constant, but once the workflow jobs starts, you cannot change the workflow name, If the name gets resolved as part of a job action, you are out of luck. There is no api endpoint to rename a workflow run name either. This is very useful. Say you are using GitVersion to resolve the build semantic version, imagine you wanted rename the build to this semantic version. Thanks!

[deadlydog]

You can use the run-name element to dynamically set the workflow run name. It is very limited though as it is only able to access the github and inputs contexts.

I came here to make a similar request as this, to be able to rename the workflow run from a job step. My use case is we want to include the version number (which is determined dynamically during the build workflow run) in our build and deployment workflow run names. Having to click into every workflow run to find out which version it is for (assuming you output it in one of your workflow steps) is a real pain.

+1 to be able to include arbitrary information in the workflow run name from a job step.

[vinmassaro]

Also looking for this feature to add version number to the run name, or other metadata to a run.

[salvianreynaldi]

It'd be fantastic if we can use values from reusable workflow's job outputs in the run-name

[tuyen-vuduc]

It's a +1 from me too. We can change the build number in Azure DevOps. I hope we can do it the same for run-name in GitHub Actions.

[grant-allan-ctct]

I am really hoping for this too.

For my case, I would be able to dynamically change the run-name (so that my runs show up more meaningfully in the Actions tab) if I could

1. while defining run-name, perform string-splitting operations on the input arguments used to trigger the run, or
2. have the ability to tweak the run-name later on while the workflow in progress (and relying on something within the workflow to do the string splitting instead)

But we have neither ability 😞 .

One thing that does save me a little bit of digging as far into the results, based on this technique, was this:

• get my existing job (which is a reusable / "called" workflow) to output the information that I wanted to make more visible
• in my "caller" workflow, create an additional job, and make it dependent on my existing job using the needs keyword
• set the name property of the new job, using the new outputs from my existing job

This makes the useful information visible in the call graph, because the new job is showing the useful information in its name.

[Pablo-Grisafi-Despegar]

If the run name is immutable for some reason, having some way to add info to the Actions screen (lets say a 3rd line, after the run name and the automatic details 'Some workflow #62: Commit [02db591 pushed by someone' ) would be great

[michihuber]

Yes please, want to see the release version that is determined as part of the run in the run list

[GMZwinge]

A multi-line or wrap-around run-name could be useful too when more than one truncated line of information on the run needs to be displayed.

[man0s]

+1 on this one..

[Phisicalist]

+1 on this one. Really looking for this since it is possible in Azure DevOps

[Pawel-608]

+1

[christophwille]

+1 in our project we have a convoluted way of determining the version that is then surfaced as a step output variable, and we'd like to surface that version number in the workflow runs overview.

[kieranedwards]

+1, would love to not need to dig into the different runs to work out which run's for which build. Thanks!

[Larswa]

Yes please! Missing this from the good ole' Azure Devops days 😂
And I know we could probably fiddle with github api calls or something, but this should really be a built in feature, right?

[fred-gagnon]

Incredible how many people are requesting this feature across different posts and nowhere there's an answer as to if/when this feature will be available.

[grant-allan-ctct]

Maybe we are not in the right place? 🤔

Or maybe the right people are not in the same place as us? 😎

[garbelini]

Probably the same reason nothing else is done or is even in the roadmap:

Only work done is enterprise and runner options.

GitHub Public Roadmap (view)

[rover770]

+1

[kogratte]

+1...

[singhr007]

+1

[alpha7b]

+1

[marknitek]

+1

[david-v-pierce-usps]

This would really be useful for us as well - our deployment workflow creates a Change Request reference in ServiceNow, and being able to include the CHG number in the workflow run title would be very helpful.

[Weslley-Stein]

+1

[AdamGoto]

+1

[tommy-couzens]

+1

This is the main missing feature from github actions compared to be previous CI/CD tools I've used like jenkins and teamcity. This is one of the main things I am considering right now in our choice of CI/CD platform going forward.

[hellcoderGIT]

frustrating to come here after a migration to github actions and see it's not possible :/

[ML-Marco]

Two years already and no one from the GitHub team bothered to reply.

[grant-allan-ctct]

I think that a post from Github to this discussion would be a professional and courteous move. Let's keep hoping...

[kogratte]

Guys, how the hell are we supposed to know which run build which image?!

[Burwin]

[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 have never commented here. Solidly on the backlog for this calendar year. Not before April at this point, but lets see where we get to around then <3 But yes, I am watching and listening here 👀

[grant-allan-ctct]

Thank you for the response. Please feel free to give an update on progress at regular intervals 😎 .

[SyedShaheerHussain]

You’re correct on all points — and this is a real limitation of GitHub Actions today.

Current behavior (as designed)

• run-name is evaluated once, at workflow dispatch time.
• It can only reference:
• workflow inputs
• static expressions
• context available before any jobs run
• Once the workflow starts, the run name is immutable.
• There is no REST or GraphQL API to rename a workflow run after creation.

So if the value you want (for example, a semantic version from GitVersion) is only known during a job, you’re out of luck for naming the run itself.

You’re not missing an endpoint or a trick — it simply doesn’t exist.

Why this is painful (and you’re right)

Your GitVersion example is a perfect illustration:

• The most meaningful identifier for a run (the resolved semantic version) is only known after checkout and execution.
• That information would be extremely valuable:
• in the Actions UI
• in notifications
• when scanning historical runs
• Instead, users are forced to rely on:
• job names
• step summaries
• artifacts
• commit SHAs (which are much less human-friendly)

This makes workflow runs harder to reason about at a glance, especially in active repositories.

Common workarounds (none are perfect)

1. Put the version in the job name

Job names can be dynamic:

jobs:
  build:
    name: Build ${{ steps.gitversion.outputs.semVer }}

This helps inside the run, but the workflow run name remains unchanged in the Actions list.

2. Use run-name with best-effort precomputed values

If you can approximate or partially compute the version before jobs start (for example via inputs or tags),
you can use:

run-name: Build ${{ github.ref_name }}

But this doesn’t work for tools like GitVersion that need repository state and execution.

3. Emit the version prominently elsewhere

Many teams settle for:

• Step Summary ($GITHUB_STEP_SUMMARY)
• Artifacts named with the version
• Commit status / check run titles

Useful, but still not a replacement for renaming the run itself.

Bottom line

What you’re asking for is both reasonable and broadly useful, and your analysis is accurate:

• Workflow run names are resolved too early
• They cannot be changed later
• There is no API to do so
• This blocks common, legitimate use cases like semantic versioning

If GitHub ever allows:

• updating run-name during execution, or
• resolving it from job outputs, or
• renaming runs via API

it would be a meaningful DX improvement.

Until then, the limitation is real, and your frustration is justified.