Manually modify GITHUB_RUN_NUMBER for workflow

[Danielku15]

The GITHUB_RUN_NUMBER is currently a nice way of having a build number on your builds. I’m using it to build up a semver like 1.2.3-alpha.{number}. Unfortunately this number resets if you change the workflow name and in some other scenarios. 

This can lead to an issue if you deploy your package to registries like npmjs.com. It would be great if we can manually set the new value of GITHUB_RUN_NUMBER within the repository. I could bump it again from 1 to the number I had before renaming my workflow file. 

Another use case is if I bump my version to 1.2.4 I want to start again with alpha.1. Many CI servers expose this build number/counter and it can be reset manually if needed. GitHub actions seems to be missing this feature so far.

Is there maybe a workaround for this? I would like to avoid spoiling my Git history with constant version bumps from the CI environment just to update the build version within my package.json. 

[Danielku15]

Hi @mscoutermarsh 

Thanks for sharing this insight. GitHub actions still has a huge potential to grow and I have no doubts that sooner or later these scenarios will be covered by some action or via GitHub actions directly. 

I thought also of adopting this early action to my needs. It existed before the official build number and uses git refs/tags to store the build counters. 

[tmorone-rezi]

It would be very useful if we could run a one-time operation to set the current run number for the repo. I am migrating our CI/CD pipeline from bitrise. Since we published releases using the bitrise build number, it becomes troublesome to go “back in time” and using a build number that was already used. I imagine others will have similar problems as they migrate from another system.

[hmartinez82]

Yes. I'm running this exactly problem (coming from Jenkins) in several repos :(

[hopeman15]

We are currently migrating from Travis, this feature request would be a wonderful thing 👍

[mattgodbolt]

This would be an amazing feature to have. On other build systems (e.g. TeamCity) we can edit the “next run number” which lets us do this kind of thing. Having the build number that GH displays in the actions view match up with the build number we put in our binaries would be so handy.

[mlilback]

I just published an action that does what most commenters seem to want. It lets you add a base number to the GITHUB_RUN_NUMBER. I use it to tag docker images and can’t have the number reset. So I just have to update the base number in the workflow when I edit the workflow.

mlilback/build-number action

[Muheli]

Thanks for sharing this clever solution.

[alonbl]

I was too very surprised that the github.run_number depends on the workflow name.

[rajbopched11]

@mscoutermarsh is this issue resolved yet?
It's 2023 and we are still awaiting this feature ¯_(ツ)_/¯

[mscoutermarsh]

I don't work for GitHub anymore. Try emailing support.

[rajbopched11]

Meanwhile, a work-around which serves us well 🛠️ 🥇

steps:
      - name: Set Build Number Environment Variable
        run: |
          echo "BUILD_NUMBER=$((${{ github.run_number }}+${{ github.run_attempt }}))" >> $GITHUB_ENV
          echo $BUILD_NUMBER

[AlexNolasco]

perhaps by adding two numbers?
https://github.com/orgs/community/discussions/25386

Example

      - name: Increase build
        run: |
          echo "GITHUB_RUN_NUMBER_WITH_OFFSET=$(($GITHUB_RUN_NUMBER+1971))" >> $GITHUB_ENV

[silashansen]

It's a clever workround and definitely useful, but I am still missing a formal way of doing this, as this is such a common thing in other CI solutions.

[hmartinez82]

This is what most people are doing. But it sucks because I want to change the run-name based on this calculated values. So none of the two things that Jenkins has supported for ages, changing the next build number and allowing to change the run-name after the build starts, are not supported and I get in this deadlock!

[Amerousful]

Hello!
Is there any update in 2024? I faced the same problem during migration from another CI/CD tool. In the current system, our build/run id is a crucial thing and we have to maintain the same increment order instead of starting anew.

[Vacxe]

We using auto incremented build number on CI for each build. I think its very common approach on many platforms. As well managing run_number is common functionality for any build system. Could you please provide it for GHA in 2024 as well.

[abhilashindulkar]

Would love to see this feature implemented soon. This will help a lot. I can't rename/duplicate workflows every time I mess up with the build.

[ZZero7]

Response#1

[rusik]

Just faced same issue as other commenters in here. Please add this feature asap 🙏

[Danielku15]

Considering all my findings on GHA over the years, nowadays I would phrase my feature request different. While GITHUB_RUN_NUMBER modifications would maybe solve one problem, they don't solve others.

Not sure if its worth opening an on request in favor of this one but just to place it somewhere:

The ability to have an custom persistent key-value store as part of GitHub Actions would solve many use-cases. There is currently now way workflows can store custom variables/values in a deterministic and persistent way. Additionally some new expressions to handle arithmetic operations and type conversions would be needed.

Assuming that such a feature is available, you could simply create your own personal GITHUB_RUN_NUMBER by storing a custom counter in this key-value store.

Theoretically such a store exists with the new "Repository Variables" feature. But you need to use the REST API to get/set them and authenticate with proper permissions. It should be possible to create a custom action incrementing a custom counter as a step in your build scripts. You can prefix it with workflow or job names as desired. Modifying/Resetting values manually can be done via the GitHub UI.

If the feature is very important for anyone, you should be able to create such an easily for your repository. e.g. use github-script to get, increment and store a custom counter. You might also make it available under a environment variable or output for further steps to use. https://docs.github.com/en/rest/actions/variables?apiVersion=2022-11-28

[piotrekkr]

You could try using repository level properties. Kind of hacky but may work as a storage. Problem may be concurrency but if workflow runs are not frequent or in parallel, then it should work okay I think.

You will probably need a fine grained PAT (or GH App token) with "Custom properties" repository permissions (write).

Here is api endpoint you could use to update property for repo.

And here is docs about custom repo properties