Open warrenbuckley opened 5 years ago
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 😄
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
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.
The strategy
context always seems to have the following:
{
"fail-fast": true,
"job-index": 0,
"job-total": 1,
"max-parallel": 1
}
@chrispat any idea on time-frame on when we would be able to get access to a build/run number please?
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)"
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.
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. 😞
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
nice hack! I will check and maybe do it till we get the build number feature in GitHub Actions CI.
git rev-list --count HEAD
is a suitable solution for our needs
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
As @chrispat noted, service doesn't have the concept.
It does not have to be strictly a "build number" concept. All that needs to be provided is a unique-workflow-number
:
incremental
(not GUID) so that a later workflow would have a greater number (doesn't have be strict, i.e. 1, 2, 3)As I stated above, simply providing the associated check-suite-id
(and/or check-run-id
) could serve the desired purpose.
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
fyi run ID is being added probably will land sometime in January
@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.
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
@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:
To support both use cases, should there be provided both check-suite-id
and check-run-id
?
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.
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 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.
Awesome news! Thanks!
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
.
@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.
@chrispat - is it a bug? it seems like run_number should remain the same but id should change.
It is a rerun of the same run so I expect them to both be the same.
@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.
Another workaround for this - https://github.com/marketplace/actions/uuid-action
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.
@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"
@ericsciple That doesn't solve my problem at all:
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.”)
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.
How can I obtain the run_id
...?
const github = require('@actions/github');
const runId = github....?
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
)
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}}
@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
Hope I won't jinx it, but it looks like this might finally get implemented: https://news.ycombinator.com/item?id=28472454 :-)
With addition of github.run_attempt
can this now be closed?
@joebowbeer No github.run_attempt is not unique for the different branches
How can I have unique build number for every workflow/branch
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.
Using Actions as CI
How or where can I get a unique build number to append build Artifacts with a unique CI version
/cc @damccorm