-
-
Save blake-newman/50a4973221925d0cd0f941d741d01691 to your computer and use it in GitHub Desktop.
name: My workflow | |
on: [pull_request] | |
jobs: | |
build_id: | |
steps: | |
- name: 'Set build id' | |
id: build_id | |
# add a step output `steps.build_id.outputs.id` as the unique id | |
run: echo "::set-output name=id::$(date +%s)" | |
tests: | |
# require the build to run after the build_id job | |
needs: build_id | |
name: Cypress run | |
runs-on: ubuntu-latest | |
strategy: | |
matrix: | |
# run 2 copies of the current job in parallel | |
containers: [1, 2] | |
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 | |
env: | |
# pass the Dashboard record key as an environment variable | |
CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }} |
i hate how github doens't have a unique id for each run 😡
actually would ${{ github.run_id }}-${{ github.run_number }}-${{ github.run_attempt }}
suffice for a unique id for the build 🤔
I thought about the combination as well, it however has a flaw with semver if that is where you want to use the number.
You have 5 jobs to start a project. So let's say you get a number like 4-1-12
. Later after a few refactors of the workflows you could get to over 40 job IDs. Then the 41'st could have a generation like 41-1-2
. Perfectly fine if you can separate the numbers like the dash has. However pure concatenation makes them both 4112
. No way to tell where one number starts and ends.
So yes, that is "unique enough" in the cases where separators are allowed. If you want to say generate an NPM version number automatically from it, that still isn't unique enough.
i hate how github doens't have a unique id for each run 😡
same, and github doesn't provide the job_id
neither, that we cannot get the current run url: .../actions/runs/<run_id>/job/<job_id>
inside a run, .../actions/runs/<run_id>
returns always the last attempt.
nice one @blake-newman . just needed this.