We'll work around the caching issue for now, but I don't think this should break the build. Instead, this PR will update the remote and return 0 status code allowing the build to continue.
I haven't got a bulletproof way of testing the changes. But here's the thinking with the logic, to prove that it should work:
# starts empty
$ git remote -v
# first run adds the "repo1", as normal, with successful status code
$ git remote add gk-origin https://github.com/user/repo1.git || git remote set-url gk-origin https://github.com/user/repo2.git
$ echo $?
0
$ git remote -v
gk-origin https://github.com/user/repo1.git (fetch)
gk-origin https://github.com/user/repo1.git (push)
# second run updates to "repo2" with successful status code (though there's a write to STDERR, about a fatal error on the first command)
$ git remote add gk-origin https://github.com/user/repo1.git || git remote set-url gk-origin https://github.com/user/repo2.git
fatal: remote gk-origin already exists.
$ echo $?
0
$ git remote -v
gk-origin https://github.com/user/repo2.git (fetch)
gk-origin https://github.com/user/repo2.git (push)
Hi!
We're getting some failures with https://github.com/greenkeeperio/greenkeeper-lockfile recently, due to some caching on CircleCI:
We'll work around the caching issue for now, but I don't think this should break the build. Instead, this PR will update the remote and return
0
status code allowing the build to continue.I haven't got a bulletproof way of testing the changes. But here's the thinking with the logic, to prove that it should work: