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,

MChevy422

I’ve been using the build number as part of my version numbers (yyyy.m.d.build) 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?

actions/toolkit#65

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

https://docs.knapsackpro.com/2019/how-to-run-rspec-on-github-actions-for-ruby-on-rails-app-using-parallel-jobs

I’ve made a simple action to generate sequential build numbers, https://github.com/einaregilsson/build-number . 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. 

See https://github.community/t5/GitHub-Actions/Check-Suite-identifier-as-an-environment-variable/m-p/35498#M2240

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)" >> local.properties
        env:
          PUSHED_TIME: ${{ toJson(github.event.repository.pushed_at) }}

https://medium.com/@esplo/using-an-unusual-timestamp-as-an-auto-generated-version-code-for-android-apps-f231b026edbd

Here is our solution to this issue:

https://medium.com/attest-engineering/adding-a-unique-github-build-identifier-7aa2e83cadca

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
  env:
    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?

Great!
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.

exp.

Screen Shot 2020-01-29 at 8.53.55.png1276×124 9.97 KB

Thanks

The 2 env variables that were introduced are still not unique 😦 The 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.

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: https://developer.github.com/v3/actions/workflow-jobs/#get-a-job-for-a-workflow-run

See github.run_attempt et al

https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context