GitHub Community
Manually modify GITHUB_RUN_NUMBER for workflow #26709
Replies: 10 comments 4 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
We are currently migrating from Travis, this feature request would be a wonderful thing 👍 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for sharing this clever solution. |
Beta Was this translation helpful? Give feedback.
-
|
I was too very surprised that the |
Beta Was this translation helpful? Give feedback.
-
|
@mscoutermarsh is this issue resolved yet? |
Beta Was this translation helpful? Give feedback.
-
|
I don't work for GitHub anymore. Try emailing support. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
perhaps by adding two numbers? Example |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Hello! |
Beta Was this translation helpful? Give feedback.
-
|
We using auto incremented build number on CI for each build. I think its very common approach on many platforms. As well managing |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions