when used as part of a reusable workflow the default behaviour is always to checkout "main" branch

[ahmadnassri]

steps to reproduce:

project repository:

on: [pull_request, pull_request_target]

jobs:
  callable-workflow:
    uses: user/actions/.github/workflows/callable-workflow.yml@main

callable workflow:

on: workflow_call

jobs:
  call:
    timeout-minutes: 5
    steps:
      - uses: actions/checkout@v3.5.3
      - ... 

result:

during the "Checking out the ref" step:

/usr/bin/git checkout --progress --force -B master refs/remotes/origin/master

here's a real example: https://github.com/ahmadnassri/template-action-composite/actions/runs/5662593659/job/15342828405

[osdiab]

I too am experiencing this. I think this is the core issue, not in the checkout action but by Github Actions itself: actions/runner#1548

The reporter there is saying that the github context after calling workflow_call (and presumably after workflow_dispatch too) ends up changing from that of the caller.

So actions/checkout just looks at the github context and the branch is wrong. I haven't logged it to see if that's the case, but I'm pretty convinced that's what's going on.

The obvious workaround is to pass ref explicitly, but yeah that's kinda sad

Exploration of the checkout source code

This is probably less relevant since it's fully explained by the above Github Actions issue, but my background from looking around:

Looking at the source code:

checkout/src/input-helper.ts

Line 59 in 96f5310

// Source branch, source version

• looks like it checks for an explicit ref input first
• then if not there it looks at the github context
• according to Github docs it seems like the github context should make it to the reusable workflow:

When a reusable workflow is triggered by a caller workflow, the github context is always associated with the caller workflow. The called workflow is automatically granted access to github.token and secrets.GITHUB_TOKEN.

• it just says also that env vars wouldn't make it through. But again, source doesn't look like it's using env vars here.

Any environment variables set in an env context defined at the workflow level in the caller workflow are not propagated to the called workflow.

• it is stated in the README that:

    # 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.
    ref: ''

• this is where it seems to get the default branch, which it only does if ref or commit aren't there from the previously linked function:

  checkout/src/git-source-provider.ts

  Line 133 in 96f5310

  // Determine the default branch

But yeah pretty sure it's getting it from the github context as expected and just the context contains the wrong values.

[dogmatic69]

I've been having a similar issue but When reverting to actions/checkout@v3.5.3 it works as expected again, checking out the correct hash.

[shermanericts]

agh this got me most of the day today. Thanks for the detail and fix this helped!

[dkirrane]

Hitting this as well with actions/checkout@v4
Seems like a fairly big issue if a reusable workflow is checking out the wrong branch!

I've tried actions/checkout@v3.5.2, actions/checkout@v3.5.3 and actions/checkout@v4.1.1
The reusable workflow always checks out the main branch instead of the PR branch of the caller workflow.

[dkirrane]

I checked the GitHub context in the reusable workflow and can see ref is refs/heads/main, whereas head_ref points to my PR.

Nasty bug IMO.
My workaround is to use github.head_ref if it exists

    - name: Dump GitHub context
      env:
        GITHUB_CONTEXT: ${{ toJson(github) }}
      run: echo "$GITHUB_CONTEXT"    

    - name: Checkout code
      uses: actions/checkout@v4
      with:
        ref: "${{ github.head_ref || github.ref }}"
        

[PavanMudigondaTR]

Hi Github team, we are impacted by this bug. Do you have any ETA or workaround solution for this ?

[marekaf]

We have the same issue, if someone pushes to main meanwhile a long workflow is running, the checkout action checks out new main commit and causes a lot of inconsistencies

EDIT: huh! I managed to create a workflow with push-to-main trigger that calls a reusable workflow and do echo ${{ github.sha }}, sleep
meanwhile the sleep is running I merged a PR to main
sleep finishes and reusable workflow is called, then echo ${{ github.sha }} and the github.sha is set to the same value and not new main HEAD

so for us a workaround is to use checkout action with ref: ${{ github.sha }}
still I'd expect this to be the default behaviour

[y-yash]

Even when I try the workaround suggested by @marekaf , it defaults to the sha of the last commit on the main branch.

In my case, I have a feature branch merging into a non-main branch (a dev branch). So, in this situation main branch is no where referenced and despite this, the reusable workflow defaults to main always. Even when I use an input referencing GITHUB_HEAD_REF it defaults to main.

Anyone still facing this? Or anyone figured out a way out of this?