--affected failing to resolve main even on full checkout

[chris-olszewski]

Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

https://github.com/amannn/next-intl

What package manager are you using / does the bug impact?

pnpm

What operating system are you using?

Linux

Which canary version will you have in your reproduction?

2.2.3

Describe the Bug

Using --affected results in the following log line:

Failed to resolve base ref 'main' from GitHub Actions event: git error: fatal: ambiguous argument 'main': unknown revision or path not in the working tree.

example in GH Actions

Expected Behavior

We shouldn't have get an ambiguous argument when testing out main. Especially with fetch-depth: 0

To Reproduce

See next-intl attempting to use --affected: example job

Additional context

No response

[ryanarmstrong]

Had a similar issue over on GitLab. The issue was that GitLab Runner will checkout in a detached HEAD mode, which is not a branch, and thus main isn't a branch there.

The fix was to set TURBO_SCM_BASE: "origin/main"

Looking at the logs in your CI, you are also running in a detached HEAD mode, so the above may solve your issue. Alternatively, you could checkout the main branch so you're not in detached HEAD.

Since it seems like this can happen pretty easily in both GitLab and GitHub, it might be a good idea for Turborepo to update its docs to talk about this. It took me quite some time to figure this out.

[amannn]

Thanks for chiming in here @ryanarmstrong!

Preferably, I'd like to avoid setting TURBO_SCM_BASE, so that --affected also works when targeting other branches than origin/main. Maybe github.base_ref could work to set this dynamically?

I was curious if Turbo tries to do this for you since apparently --affected should work with zero config in GitHub Actions.

[ryanarmstrong]

So I could be wrong, but I think the reason that it works in GitHub actions without any config is that Turborepo is looking for GItHub variables and knows when it's in CI. So it has built-in support for GitHub actions but not for GitLab CI.

I am basing this off of the documentation here. But I can't say this definitively.

[miikebar]

For anyone looking for a solution until the issue gets resolved (based on #800 (reply in thread)):

env:
  TURBO_SCM_BASE: ${{ github.event_name == 'pull_request' && github.event.pull_request.base.sha || github.event.before }}

This will set TURBO_SCM_BASE to:

• the HEAD commit of the branch you’re merging into if it's a PR
• the HEAD commit SHA on your target branch before the merge for other contexts (i.e. on push)

[amannn]

@miikebar Seems to work for me, thanks for sharing!