Add build number?

First, just because other CI providers have a feature doesn’t necessarily mean that it should be implemented in Actions.

That said, it would be very helpful to have a build number, or maybe even a build.job number, similar to Travis.

Recently I wanted to look over the results of several builds, and there is no easy way to determine what is what (or what the order was).  If the ‘number’ appeared early in the html title, one could see it on the browser tab, which is very helpful…


Hello @msp-greg

Thank you for your feedback! We’re always working to improve GitHub and the GitHub Community Forum, and we consider every suggestion we receive. I’ve logged your feedback in our internal feature request list.

Though I can’t guarantee anything or share a timeline for this, I can tell you that it’s been shared with the appropriate teams for consideration.

Once again, thank you for your input!

Greatly appreciated,


1 Like

I’ve been using the build number as part of my version numbers ( which makes it easy to know when the deployment happened, and which build it’s from. This is one of the last things stopping me from moving all of my builds over to actions.


I have posted the same thing here over on the GitHub actions/toolkit repo as an issue as I am stil unsure where the best place is to discuss with the GitHub team and give feedback.

Is it on issuses or here in this forum?

Thanks @xt0rted and @warrenbuckley for being here! This is the right place for this type of feedback as the team who directly works in actions is here and interacts with users. I can tell you that although as you know this is not available as yet, there is an internal discussion to add this feature to GitHub Actions and your feedback has been added to it.


CI build ID would be helpful. I recently added integration for GitHub Actions into my ruby gem knapsack_pro for automated tests split across parallel jobs. The CI build ID is needed to allow to run a few CI build at the same time for the same git commit. 

Here is more about my integration with GitHub Actions

I’ve made a simple action to generate sequential build numbers, . Would love for it to be made obsolete by GitHub implementing this natively, but until then I use it so I can continue the same versioning scheme I used on my old CI/CD system. I don’t think there’s any way right now to make the build number appear in the list of workflow runs though, that would be great if that was possible.


I think having check-suite-id (and check-run-id) available as environment variables would provide approptiate for the purpose number. 


Looking forward for this implementation.


Here is my workaround using pushed time for build number.

- name: set build number
        run: |
          mkdir ../build
          echo $(( ($PUSHED_TIME - 1572572000) / 10 )) > ../build/FULTTER_VERSION_CODE_BY_PUSHED_TIME
          echo "flutter.versionCode=$(cat ../build/FULTTER_VERSION_CODE_BY_PUSHED_TIME)" >>
          PUSHED_TIME: ${{ toJson(github.event.repository.pushed_at) }}

Here is our solution to this issue:


On the github context there’s now a run_id and run_number  property that’s available to be passed into your actions. I’m not sure if you can get to this from one of the environment variables, but it’s available through the context at least.

There doesn’t seem to be docs on this yet but you can see it if you dump the context out like so:

- name: Dump GitHub context
    GITHUB_CONTEXT: ${{ toJson(github) }}
  run: echo "$GITHUB_CONTEXT"

run_id is the unique id of each run

run_number looks to be an auto incrementing value specific to each workflow. This value doesn’t increment if you rerun the workflow.


Is this not what $GITHUB_RUN_NUMBER is for?

1 Like

Both are also available as environment variables.


Also it wouldn’t be a full solution without adding the name and number in the UI under the Actions tab. Today only the workflow name exists in each row.




The 2 env variables that were introduced are still not unique :frowning: The number does not change if you re-run the workflow run.

* GITHUB_RUN_ID A unique number for each run within a repository. This number does not change if you re-run the workflow run.
* GITHUB_RUN_NUMBER A unique number for each run of a particular workflow in a repository. This number begins at 1 for the workflow’s first run, and increments with each new run. This number does not change if you re-run the workflow run.

When someone reruns workflow I need to run a new split of tests between parallel jobs in knapsack pro tool on Github Actions. If I would use GITHUB_RUN_ID and someone reruns the workflow then my API would assume tests were already split for this GITHUB_RUN_ID. I would need GITHUB_UNIQUE_RUN_ID that would be always unique even for re-run workflow. This is how most CI providers generate CI build ID (it should be unique). Any chance you would introduce GITHUB_UNIQUE_RUN_ID ? Thank you.

1 Like

I could use something like that as well: services such as coveralls accept a unique job id in their input and it would be good if they could link back to the specific job that generated the coverage.
I’d suggest to name it GITHUB_JOB_ID and expose the job id that is already available through the API: