Job concurrency does not run latest HEAD

Hi there,

I came across a weird behaviour (at least not as expected) when using the concurrency field. I’m using a fixed concurrency group like concurrency: deploy-request. The related workflow creates a new commit whenever the repository_dispatch event occurs.

If I now trigger two jobs in a row, the first job creates a new commit and the job passes. However, the latter seems to operate on the previous HEAD. The step cat output.log does not contain the value generated by the first job see and git push fails.

As a workaround I run git pull origin main right after the checkout

Is this behaviour intentional / by design?

I had another look and turns out that all is needed is to set the default branch as ref to make the checkout action pull the latest HEAD

- uses: actions/checkout@v2
  with: 
    ref: 'main'

From the checkout docs

The branch, tag or SHA to checkout. When checking out the repository that triggered a workflow, this defaults to the reference or SHA for that event. Otherwise, uses the default branch.

1 Like

I am so glad you posted this. I ran into the same issue thinking the default was to checkout HEAD already.

1 Like

Great to see that posting the solution was already helpful to you :grinning: