Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: avoid resetting fetch head when doing branch fetch unshallow #4577

Merged
merged 2 commits into from
Nov 7, 2024

Conversation

0x0013
Copy link
Contributor

@0x0013 0x0013 commented May 20, 2024

When doing merge strategy with shallow clones, git will set FETCH_HEAD to base branch when doing unshallow. This fetches another time to reset it back, as we depend on the value later.

what

When using merge strategy with a checkout-depth and the shallow branch can't find a common base with the base branch, a full branch must be fetched with --unshallow. This PR does another fetch from the feature branch after doing this, to keep the FETCH_HEAD as expected for future operations.

why

When doing merge strategy with shallow clones, git will set FETCH_HEAD to base branch when doing unshallow. FETCH_HEAD is later used as the ref when doing a merge to base branch, effectively merging it with itself. This in turn causes Atlantis to plan/apply against the base branch and presenting "no changes", even when there should be changes.

tests

We have been running a fork with this fix for a few month, using a merge strategy with a checkout-depth value that triggers a full clone relatively often. We have not experienced plans against the base branch since this fix, while we experienced them quite often before.

references

While the original issue seems to be referring to a different situation, there is as issue comment describing this situation. The bug being fixed would also present errors like the ones in the issue, though I don't think this PR fixes that specific issue.

@0x0013 0x0013 requested review from a team as code owners May 20, 2024 06:51
@0x0013 0x0013 requested review from chenrui333, lukemassa and X-Guardian and removed request for a team May 20, 2024 06:51
@github-actions github-actions bot added the go Pull requests that update Go code label May 20, 2024
@jamengual jamengual added the waiting-on-review Waiting for a review from a maintainer label May 24, 2024
@0x0013
Copy link
Contributor Author

0x0013 commented Jun 19, 2024

Could someone suggest why the CI check (tester/e2e-github) might be failing? The output is unclear:

Error: Process completed with exit code 1.

and the tests passed for me locally, so I can't understand what the issue might be.

@X-Guardian X-Guardian closed this Nov 5, 2024
@X-Guardian X-Guardian reopened this Nov 5, 2024
@X-Guardian
Copy link
Contributor

Can you update this PR from the main branch? You haven't given permission for maintainers to update it.

When doing merge strategy with shallow clones, git will set FETCH_HEAD
to base branch when doing unshallow. Fetch another to reset it back.
@0x0013
Copy link
Contributor Author

0x0013 commented Nov 7, 2024

@X-Guardian Thanks for taking a look at this. I've rebased the branch.

@dosubot dosubot bot added the lgtm This PR has been approved by a maintainer label Nov 7, 2024
@X-Guardian X-Guardian merged commit d4247bc into runatlantis:main Nov 7, 2024
33 of 34 checks passed
@X-Guardian
Copy link
Contributor

Thanks for this @0x0013. Can you test on one of these container images: dev-debian-d4247bc or dev-alpine-d4247bc

@0x0013
Copy link
Contributor Author

0x0013 commented Nov 8, 2024

Tested with dev-debian-d4247bc and Atlantis still shows changes after PR branch tail exceeds ATLANTIS_CHECKOUT_DEPTH - as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
go Pull requests that update Go code lgtm This PR has been approved by a maintainer waiting-on-review Waiting for a review from a maintainer
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants