Github action workflow generating a unique id

unique-id-generation-workflow.yml

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 }}

nice one @blake-newman . just needed this.

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.