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

Merge strategy does not work #1193

Closed
krzysztof-magosa opened this issue Sep 18, 2020 · 4 comments · Fixed by lyft/atlantis#7 or #1225
Closed

Merge strategy does not work #1193

krzysztof-magosa opened this issue Sep 18, 2020 · 4 comments · Fixed by lyft/atlantis#7 or #1225

Comments

@krzysztof-magosa
Copy link

Hi.
We've tried checkout-strategy: merge but it does not work, Atlantis is configured as GH App.

running git clone --branch master --single-branch https://:<redacted>@github.com/performgroup/iae-general-tf.git /data/repos/performgroup/iae-general-tf/1216/default: Cloning into '/data/repos/performgroup/iae-general-tf/1216/default'...
remote: Repository not found.
fatal: Authentication failed for 'https://github.com/performgroup/iae-general-tf.git/': exit status 128
@lkysow
Copy link
Member

lkysow commented Sep 18, 2020

Is https://:<redacted> the actual URL? There's no username, it should be https://username:<redacted>

@krzysztof-magosa
Copy link
Author

It's exact copy/paste. Maybe lack of username is caused by fact it's installed as GH APP?

@Roberdvs
Copy link

Same here.

I was setting up a fresh Atlantis as a GitHub App with checkout-strategy: merge.
I switched to default strategy after seeing this issue and everything worked, so thanks for pointing me in the right direction.

In case it helps narrow it down, the contents of both /home/atlantis/.git-credentials and /home/atlantis/.gitconfig are the same in both cases and running directly the git clone command inside the Atlantis container works when removing the :<redacted> bit.

@dan-slinky-ckpd
Copy link

dan-slinky-ckpd commented Oct 22, 2020

Same as above. We have applied the branch strategy workaround which works for now, but now we find the same behaviour above when the PR is openned from a fork. Had no issues with forks in the non GitHub App configuration, using allow-fork-prs in both situations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants