-
Notifications
You must be signed in to change notification settings - Fork 116
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
Refactor deploy/activate script #2069
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
monfresh
force-pushed
the
mb-activate-script
branch
3 times, most recently
from
March 28, 2018 18:16
6592034
to
fb45120
Compare
monfresh
requested review from
mark-from-usds,
jgsmith-usds,
stevegsa and
jgrevich
March 28, 2018 18:24
|
Fudge. It's the vicious cycle of needing the config to be present before loading the app. Back to the drawing board. |
monfresh
force-pushed
the
mb-activate-script
branch
from
March 28, 2018 21:32
fb45120
to
ad1415d
Compare
@mark-from-usds Can you try again? I forced pushed a change. |
monfresh
force-pushed
the
mb-activate-script
branch
from
March 28, 2018 22:59
ad1415d
to
4a5945f
Compare
I just recycled the markryan env with the latest changes. Fingers crossed. |
|
Still not working but I know what the issue is. Hopefully the third time will be the charm. |
**Why**: If the `deploy/activate` script is a shell script, it requires calling `Bundler.setup` so that the files that the script depends on are loaded. The problem is that the `Bundler.setup` call was preventing us from running parallel builds in Circle CI. I removed the `Bundler.setup` call in #2060 to see if that would allow parallel builds, which it did, but I forgot to check if this would break build deployment, and it did. In order to allow the script to run during deployment and also allow parallel builds to work, I defined a shell script that will fetch the config from S3 by calling the ruby file directly using `bundle exec`. That way, the gems will already be loaded. This also separates concerns and makes it easier to test the S3 fetching in isolation. It also keeps things consistent with the other scripts in the `deploy` directory.
monfresh
force-pushed
the
mb-activate-script
branch
from
March 29, 2018 15:28
4a5945f
to
0476a99
Compare
Yay! Success! Can you approve the PR please? |
mark-from-usds
approved these changes
Mar 29, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Why: If the
deploy/activate
script is a shell script, it requirescalling
Bundler.setup
so that the files that the script depends onare loaded. The problem is that the
Bundler.setup
call was preventingus from running parallel builds in Circle CI.
I removed the
Bundler.setup
call in #2060 to see if that would allowparallel builds, which it did, but I forgot to check if this would break
build deployment, and it did.
In order to allow the script to run during deployment and also allow
parallel builds to work, I defined a shell script that will fetch the
config from S3 via a rake task. That way, Rails and gems will already
be loaded. This also separates concerns and makes it easier to test the
S3 fetching in isolation. It also keeps things consistent with the other
scripts in the
deploy
directory.Hi! Before submitting your PR for review, and/or before merging it, please
go through the following checklist:
For DB changes, check for missing indexes, check to see if the changes
affect other apps (such as the dashboard), make sure the DB columns in the
various environments are properly populated, coordinate with devops, plan
migrations in separate steps.
For route changes, make sure GET requests don't change state or result in
destructive behavior. GET requests should only result in information being
read, not written.
For encryption changes, make sure it is compatible with data that was
encrypted with the old code.
For secrets changes, make sure to update the S3 secrets bucket with the
new configs in all environments.
Do not disable Rubocop or Reek offenses unless you are absolutely sure
they are false positives. If you're not sure how to fix the offense, please
ask a teammate.
When reading data, write tests for nil values, empty strings,
and invalid formats.
When calling
redirect_to
in a controller, use_url
, not_path
.When adding user data to the session, use the
user_session
helperinstead of the
session
helper so the data does not persist beyond the user'ssession.
When adding a new controller that requires the user to be fully
authenticated, make sure to add
before_action :confirm_two_factor_authenticated
.