Fix Heroku Deployment #15
Conversation
|
I will squash these into one commit if you think these are fine since essentially all the commits besides the one creating staging environment are just juggling the procfile and updating readme. |
config/cable.yml
Outdated
| staging: | ||
| adapter: redis | ||
| url: <%= ENV.fetch("REDIS_URL") { "redis://localhost:6379/1" } %> | ||
| channel_prefix: bjc_teacher_tracker_production |
There was a problem hiding this comment.
This name should probably be updated.
| database: bjc_teachers_prod | ||
|
|
||
| production: |
There was a problem hiding this comment.
Shouldn’t this key be staging?
There was a problem hiding this comment.
Oh I think I got prod and stage database name mixed up.
|
Will resolve by today. |
README.md
Outdated
| ; | ||
| ``` | ||
| - Using psql | ||
| - First run `heroku pg:psql` or `psql bjc_teachers_dev` |
There was a problem hiding this comment.
You can also just do rails db, locally or on heroku.
config/secrets.yml
Outdated
| secret_key_base: <%= ENV["SECRET_KEY_BASE"] %> | ||
| bjc_password: <%= ENV["BJC_PASSWORD"] %> | ||
| piazza_password: <%= ENV["PIAZZA_PASSWORD"] %> |
There was a problem hiding this comment.
| secret_key_base: <%= ENV["SECRET_KEY_BASE"] %> | |
| bjc_password: <%= ENV["BJC_PASSWORD"] %> | |
| piazza_password: <%= ENV["PIAZZA_PASSWORD"] %> | |
| <<: *production |
This would reduce some duplication
| @@ -23,7 +23,10 @@ test: | |||
|
|
|||
| # Do not keep production secrets in the repository, | |||
| # instead read values from the environment. | |||
| production: | |||
| production: &production | |||
There was a problem hiding this comment.
<<: *production below will work only if we add this &production alias.
|
Everything mentioned above fixed. I will make sure to make fewer such careless mistakes in the future. Tried to deploy this to Heroku and this seem to work good. |
|
If you’ve merged in the upstream changes, and are on Rails 7, then it should be ruby 3 now. (Which also does work on Heroku 20 there’s no need for it explicitly)-- Michael BallFrom my iPhonemichaelball.coOn Mar 13, 2023, at 3:01 AM, Yu Long ***@***.***> wrote:
@Reimirno commented on this pull request.
In README.md:
@@ -97,25 +106,25 @@ We have worked on the adding following core features and functionality:
## Steps to Deploying on Heroku
- ... create a heroku app
+- `heroku stack:set heroku-20` (Ruby 2.7.7 is not supported on latest stack heroku-22. Double check your Ruby version though)
But we are using 2.7.7 though?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because your review was requested.Message ID: ***@***.***>
|
Co-authored-by: Michael Ball <[email protected]>
|
All typo fixed. Merging. |
Created a new staging environment in rails (basically the same to the production environment as close as possible, but with email sender error suppressed and database name changed etc.) This is meant for staging in Heroku so it staging environment does not do things that only production app should do (sending email to clients etc).
I ended up didn't changing anything in Procfile because:
The right thing to do (for heroku) is just to:
db:prepareand then deploy. Then, rundb:schema:load && bin/rails db:seedmanually on console.db:prepareto allow it to run on subsequent deployments. Not doing so will leads to problems like when we have schema changes (when we add features, for example) that is not applied automatically... then you have to manually rundb:migrateordb:prepare(if you have a db setup and schema loaded prepare basically just do migration).Can we simply replace the release command in Procfile to be
db:schema:load && bin/rails db:seed? No. This will fail all subsequent runs becausedb:schema:loadis considered destructive to database and running it a second time will be blocked by rails.So that is why I ended up uncommenting the original
db:prepare. Really, making suredb:prepareworks in all cases (eliminating the edge case of first deployment) is the right thing to do, instead of swapping out command. I am not sure whydb:preparefailed on the first deployment. Based on logsdb:prepareon first deployment seems to fail at the migration stage, complaining either missing version number on migration file or missing table.