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/[email protected]
      - ... 

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: https://github.com/actions/runner/issues/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: https://github.com/actions/checkout/blob/96f53100ba2a5449eb71d2e6604bbcd94b9449b5/src/input-helper.ts#L59

• 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: https://github.com/actions/checkout/blob/96f53100ba2a5449eb71d2e6604bbcd94b9449b5/src/git-source-provider.ts#L133

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/[email protected] 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/[email protected], actions/[email protected] and actions/[email protected] 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 ?