You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On the just-trivia branch, there is a bit of a problem with the rollback process.
The rollback script works by git checkout ${lastKnownGoodCommitHash}. This is all well and good and works, but it results in a detached HEAD state in our local repo on the server.
I thought that this isn't the end of the world, because the repo is never committed to from the application server. So a detached HEAD doesn't really matter, as bad as it sounds.
However, there is a problem. On subsequent pushes to the repo, it won't be able to git pull in the latest version from a detached head state. So the rollback works fine, but the next deploy after that will not succeed.
I've done some some reading and I think I have come up with a simple solution. If I add git checkout master to the front and back end deploy scripts, that should do the trick. It we be redundant but not harmful for a regular deploy, but it will allow the next deploy after a rollback to succeed.
I just need to do some manual testing to make sure git works like I think it does.
The text was updated successfully, but these errors were encountered:
On the just-trivia branch, there is a bit of a problem with the rollback process.
The rollback script works by
git checkout ${lastKnownGoodCommitHash}
. This is all well and good and works, but it results in a detached HEAD state in our local repo on the server.I thought that this isn't the end of the world, because the repo is never committed to from the application server. So a detached HEAD doesn't really matter, as bad as it sounds.
However, there is a problem. On subsequent pushes to the repo, it won't be able to
git pull
in the latest version from a detached head state. So the rollback works fine, but the next deploy after that will not succeed.I've done some some reading and I think I have come up with a simple solution. If I add
git checkout master
to the front and back end deploy scripts, that should do the trick. It we be redundant but not harmful for a regular deploy, but it will allow the next deploy after a rollback to succeed.I just need to do some manual testing to make sure git works like I think it does.
The text was updated successfully, but these errors were encountered: