Unique Build Number for CI Build Artifacts about toolkit

[ericsciple]

fyi run ID is being added probably will land sometime in January

[nathany]

git rev-list --count HEAD is a suitable solution for our needs

[liskin]

It would really be awesome if in addition to GITHUB_RUN_ID and GITHUB_RUN_NUMBER there was a GITHUB_JOB_ID (https://developer.github.com/v3/actions/workflow-jobs/#get-a-job-for-a-workflow-run) available as well which is unique for each parallel job invocation. 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.

[nathany]

We would like a build number for publishing docker images. This is an example for Elixir/Phoenix apps:

mix docker.publish --tag "{mix-version}B${CIRCLE_BUILD_NUM}"

($CIRCLE_PREVIOUS_BUILD_NUM also came in handy)

For now I'm using $GITHUB_SHA, but something shorter would be nice.

UPDATE: our particular toolchain supports {git-count} (see https://hexdocs.pm/mix_docker/readme.html). That may be a more reliable value than a build number -- the number of commits won't change from one job to the next in a multi-job build. The more general version of this is something along these lines:

export VERSION="$(cat VERSION)B$(git rev-list --count HEAD)"

[bahmutov]

We would love to have a unique id generated for each action run - and shared across jobs and parallel steps. In our case, we run end-to-end Cypress tests in https://github.com/cypress-io/github-action where multiple machines can split the test load - because API can "detect" that all machines are running for the same action.

name: Parallel Cypress Tests

on: [push]

jobs:
  test:
    name: Cypress run
    runs-on: ubuntu-latest
    strategy:
      matrix:
        # run 3 copies of the current job in parallel
        containers: [1, 2, 3]
    steps:
      - name: Checkout
        uses: actions/checkout@v1

      # because of "record" and "parallel" parameters
      # these containers will load balance all found tests among themselves
      - name: Cypress run
        uses: cypress-io/github-action@v1
        with:
          record: true
          parallel: true
          group: 'Actions example'
        env:
          # pass the Dashboard record key as an environment variable
          CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}

Currently we use commit SHA as a workflow id - but this breaks when the users click "re-run checks", a better id (like Azure BuildID) would be ideal

[chrispat]

We are working on an Actions API that will be out for preview later this month. As part of that effort we have added a concept of RunId which is unique per workflow run across the repo.

[joernahrens]

I had the same problem and for now I'm using a small Firebase project (Cloud Function + Database) as a hack for that. You can create a free Firebase project, upload the cloud function and use something like this in your workflow:

$ export APP_VERSION_CODE=`curl https://us-central1-yourproject-id.cloudfunctions.net/inc/someIdYouChoose`

Of course your build process has to use the env variable then. Kind of a weird idea, but works well for us.. 😉

This is the project: https://github.com/joernahrens/autoinc

[ivailop]

As the GitHub Actions' docs state:

GitHub Actions use the Checks API to output statuses, results, and logs for a workflow. GitHub creates a new check suite for each workflow run. The check suite contains a check run for each job in the workflow, and each job includes steps. GitHub Actions are run as a step in a workflow.

Having the check-suite-id available as an environment variable could provide an appropriate for the purpose number.

Notice, that could currently be obtained in a very awkward way:

GITHUB_CHECK_SUITE_ID=`curl -H 'Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' -H 'Accept: application/vnd.github.antiope-preview+json' -s https://api.github.com/repos/${GITHUB_REPOSITORY}/commits/${GITHUB_SHA}/check-suites?app_id=15368 | jq -r '.check_suites[0].id'`
BUILD_NUMBER=$GITHUB_CHECK_SUITE_ID

---

In addition, having the check-suite-id a 3rd party service could construct a so called link-back-to-origin BUILD_URL (available in any CI service, I know of, out there):

GITHUB_WORKFLOW_URL=https://github.com/$GITHUB_REPOSITORY/commit/$GITHUB_SHA/checks?check_suite_id=$GITHUB_CHECK_SUITE_ID

[dominicroessner]

@chrispat I also just noticed the run_id now being part of the github context object. This appears to be the same as the run id in the new GitHub Actions API – https://developer.github.com/v3/actions/workflow_runs/#get-a-workflow-run.

We are using Cypress and as @bahmutov pointed out above, we're looking for a unique identifier across all jobs in a workflow. The run_id is almost what we're looking for as it is unique across all jobs per workflow run, but when re-running a workflow, this run_id remains the same (so does the run_number).

Is there something else we can use to make it truly unique? Couldn't find anything in the new GitHub Actions API.

[zs-dima]

@joebowbeer
No
github.run_attempt is not unique for the different branches

[ivailop]

It does not have to be strictly a "build number" concept. All that needs to be provided is a unique-workflow-number:

• should be loosely incremental (not GUID) so that a later workflow would have a greater number (doesn't have be strict, i.e. 1, 2, 3)
• could be per-repo unique (I personally don't think there is any inter-repo relation regarding that)

As I stated above, simply providing the associated check-suite-id (and/or check-run-id) could serve the desired purpose.

[chrispat]

@JoseHernandezTR yes that will give you a unique number per run of that workflow. The docs updates are rolling out as part of the API beta that shipped today.

[liskin]

@ericsciple That doesn't solve my problem at all:

1. It is still not unique across workflow re-runs (the documentation for both GITHUB_RUN_ID and GITHUB_RUN_NUMBER explicitly mentions that “This number does not change if you re-run the workflow run.”)

2. It doesn't identify the job run, in other words there's no way for an external system to link back to this particular job in this particular run. So if your job submits the test results or coverage info to some other cloud service (which is a reasonable thing to do as GitHub doesn't provide any such service within GitHub Actions), there's currently no way for this external service to provide a hyperlink back to the job that produced the results.

And as I said before, there already is an ID in the GitHub API (and the user-facing URLs use this ID as well) that satisfies all these requirements. It is the :job_id that is mentioned here: https://developer.github.com/v3/actions/workflow-jobs/#get-a-job-for-a-workflow-run. All you need to do is to expose this ID as a context variable and an environment variable.

[sohhamm]

How can I have unique build number for every workflow/branch

[damccorm]

How or where can I get a unique build number to append build Artifacts with a unique CI version

We don't have this right now, not sure if this is on the roadmap or not, @chrispat would know better than me.

Sorry, if this is not the right place to ask for help & feedback on GitHub Actions. If so can you point me to the right place .

This is a great place 😄

[mohsenoid]

nice hack!
I will check and maybe do it till we get the build number feature in GitHub Actions CI.

[ivailop]

@ericsciple, could you please clarify what is a run ID? Is that related to check-run-id?

As I pointed above, the docs state that a workflow is identified with a check-suite and each job in it with a check-run.

Depending on the needs a "build number" could be:

• job specific and different for each job
• workflow specific and same for all jobs

To support both use cases, should there be provided both check-suite-id and check-run-id?

[dominicroessner]

Similar to the previous post, our solution is to generate a GUID and set it as an output parameter on the job, then use it in other jobs. This will be a unique id across all jobs in a run and will generate a different unique id across all jobs when re-running the workflow.

jobs:
  unique_id:
    runs-on: ubuntu-latest
    steps:
      - name: Generate unique id
        id: unique_id
        run: echo "::set-output name=id::$(uuidgen)"
    outputs:
      unique_id: ${{ steps.unique_id.outputs.id }}

  test:
    runs-on: ubuntu-latest
    needs: [unique_id]
    strategy:
      matrix:
        containers: [1, 2, 3, 4]

    steps:
      - name: Print unique id
        run: echo ${{needs.unique_id.outputs.unique_id}}

[liskin]

Hope I won't jinx it, but it looks like this might finally get implemented: https://news.ycombinator.com/item?id=28472454 :-)

[warrenbuckley]

I was hoping there was something I could use from an environment variable to use as the build number, but I can't see anything that increments for each run, listed there currently.

However I did notice the debug output of the actions/upload-artifact does print/output a run number. As the src of this is not available due to it being a plugin. Are you able to tell me how or where to obtain the same build/run number please?

##[debug]Input 'artifactName': ''
##[debug]Input 'name': 'package-artifacts'
##[debug]Input 'path': 'output'
Uploading artifact 'package-artifacts' from 'd:\a\Take-Out-The-Trash\Take-Out-The-Trash\output' for run #36
Uploading 1 files

/cc @damccorm & @chrispat

[warrenbuckley]

I was hoping that the contexts listed here in the docs, would have what I need but I still can't seem to find anything that I can use.

https://help.github.com/en/articles/contexts-and-expression-syntax-for-github-actions#example-printing-context-information-to-the-log-file

The strategy context always seems to have the following:

{
  "fail-fast": true,
  "job-index": 0,
  "job-total": 1,
  "max-parallel": 1
}

[warrenbuckley]

@chrispat any idea on time-frame on when we would be able to get access to a build/run number please?

[chrispat]

Rigth now we don't even have that concpet in the system so it is going to be a ways out. However, having some sort of run number as well as a scheme for letting customers name their runs is an area we do plan to address.

[svartalf]

Build number might also be needed by the code coverage services, for example, see service_number parameter for coveralls and build for codecov.

[mohsenoid]

We migrated from GitLab CI to GitHub actions and we used to use the incremental integer build number as Android app version code but now we have no idea what to do without it. 😞

[bryanmacfarlane]

As @chrispat noted, service doesn't have the concept.

[warrenbuckley]

@ericsciple can you link to docs or implementation details once its rolled out please in this issue, so anyone who comes across this issue in the future can find the info they need.

[blake-newman]

FYI i have a solution for those in need for a temporary workaround.

It's not elegant but it works™️

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

[JoseHernandezTR]

Is there any problem using github.run_number from the github context? It's not mentioned in the documentation but a dump of the github context object reveals it's there. It's also shown in the logs produced by the upload artifacts action. It seems to be exactly what we need, a sequential index that increments for any new run of the workflow.

[JoseHernandezTR]

Awesome news! Thanks!

[ivailop]

Along with the new API, would there be a related Webhook action-run event provided?
Yes, there are check_run/check_suite events but they don't contain (as of now) anything related to the action-run.

[bryanmacfarlane]

@chrispat - is it a bug? it seems like run_number should remain the same but id should change.

[chrispat]

It is a rerun of the same run so I expect them to both be the same.

[Aubron]

@chrispat - love the run_id, but the fact that it doesn't increment on reran workflows makes it useless for our purposes. We have the same scenario as @bahmutov, we need to coordinate with a build parallelization server that needs a guaranteed unique ID. These also need to be rerun, but if using any of the stock github options, we end up appending to the previous run, not start a new one as is desired.

[Aubron]

Another workaround for this - https://github.com/marketplace/actions/uuid-action

[ericsciple]

@liskin GITHUB_JOB will give you the job ID from the yaml file. But if there is a matrix, it's not unique. You would need to disambiguate using info from the matrix, or perhaps the job-index from the strategy context:

on: push
jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
     matrix:
      v: [v1, v2]
    steps:
      - run: |
          printenv|sort
      - name: Dump strategy context
        env:
          STRATEGY_CONTEXT: ${{ toJson(strategy) }}
        run: echo "$STRATEGY_CONTEXT"

[mpdude]

How can I obtain the run_id...?

const github = require('@actions/github');
const runId = github....?

[jtomaszewski]

Check this out: https://medium.com/attest-engineering/adding-a-unique-github-build-identifier-7aa2e83cadca . A smart and simple idea that is basically: before any of your job that requires a build id, do a job that produces a build_id output that is basically the current timestamp. ( date +%s )

[thylux]

@mpdude They aren't available in github object yet, but you can get them from env vars:
process.env.GITHUB_RUN_ID
process.env.GITHUB_RUN_NUMBER

Default Environment Variables

[joebowbeer]

With addition of github.run_attempt can this now be closed?

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

[mnaser]

I'm working around with the following:

${{ github.run_id }}-${{ github.run_attempt }}

That's good enough in my case to be able to have a unique number.