Expired Git App credentials fail Remote Updating during divergence check

[nishkrishnan]

In the code, we set the remote url to the clone URL when cloning a repository. This is fine for username/password implementations since those credentials never expire. However for gh apps, the credentials expire after an hour, so if the repo is already cloned at the right commit, we just attempt to update the remote

git remote update

to check whether there has been divergence for the checkout merge strategy. The problem with this is that the remote url in the gitconfig is set to use a URL with an expired token even though we refreshed our credentials and wrote it to the git-credentials file right before.

Realistically the clone URL when using write-git-creds should be an ssh URL that git can basically substitute with the https url that contains the token but this is kind of a big change. We can also just fix this by setting the new clone url right before updating the remote to quickly unblock anyone.

https://github.com/runatlantis/atlantis/blob/master/server/events/working_dir.go#L135

[nishkrishnan]

Also related to this, but when authentication fails, git seems to prompt for a new password which obviously won't be entered and is then written to git-credentials as a blank line. Since the logic for gh apps in git_creds_writer only replaces and doesn't append if the credential is not there, you're basically stuck unless you nuke the credentials file or nuke the repo which forces a re-clone where git stores the credentials again.

(Super confusing I know and I've spent like 2 days debugging this to figure out the problem)

[nishkrishnan]

The way git creds are being used is getting out of hand for gh apps. Realistically we should be using ssh keys for any git cli commands and only use the gh app tokens for github api calls but alas this is a large undertaking.