Manually modify GITHUB_RUN_NUMBER for workflow

Code to Cloud GitHub Actions
#1

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. 

1 Like
#2

Hi @danielku15,

:wave:I’m one of the engineers that worked on the run number. 

There’s currently no way to modify it. One very hacky idea (and I cringe even saying this), is you could hardcode an integer in your workflow and add the run number to it (if you want to increase the value in the workflow).

Thanks for sharing how you’re using it though. We were originally talking about handling these scenarios, but kept the implementation simple initially. Will keep this in mind next time we work on it.

1 Like
#3

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. 

2 Likes
#4

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.

5 Likes
#5

We are currently migrating from Travis, this feature request would be a wonderful thing :+1:

1 Like