Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Rewrite server deploy script #1793
Rewrite server deploy script #1793
Changes from 7 commits
7ab6b5d
3f865d2
dd98aa4
2fd5b85
617ba94
6eba3e2
91919c5
f51f37f
07dc2b5
5556ccf
046d69e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The use of git worktree feels a bit like tempting the devil. The use of
-B
in particular risks losing information without realizing.In general, I prefer having deployment procedures so dumb that it takes a lot for them to go wrong, and when they do, they are dumb enough that it is simple to fix them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree that deployment procedures should be as easy to reason about as possible. If they fail, they should fail in very safe ways.
To that end, I'd like to avoid modifying the existing working tree during deployment. I'd also like to avoid branch switching to make sure the current ref gets deployed. In the current process, if two servers are deployed at once, I believe the second one will get
master
. I'd also like to deploy the exact same front-end build to each server. There's no need to build it again and it's one less thing to reason about.When I was working on #1774 I was initially reluctant to use
git worktree
, mostly because I don't like adding new tooling that isn't necessary. The other alternative I experimented with was copying or re-cloning to an entirely separate working copy. This was messier and more brittle than usinggit worktree
.I'm not thrilled with using
-B
. I took it from the github pages deploy, which starts with agit checkout -B gh-pages
.Before my change, the deploy commits happen on a detached head. Nothing is deleted in the process, however it's deleted right afterward. Without a branch, it's difficult to inspect what was pushed to the server. I don't like deleting data. However, it is not surprising that a deploy process would clobber a branch named production. I'd rather reserve a branch for the production deploy work than do it all on a detached head that gets tossed right after it runs.
Would you be more comfortable using a name that was really explicit like
server-deploy-working-branch
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#1941 is another issue with the current scripts.
git worktree
has been working more reliably fordeploy-gh-pages
than the current deploy is for the servers.