Unique Build Number for CI Build Artifacts

[warrenbuckley]

Using Actions as CI

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

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 .

/cc @damccorm

[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 😄

[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?

[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)"

[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. 😞

[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

[mohsenoid]

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

[nathany]

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

[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