ci: set up deployment #10
Conversation
boringcactus
had a problem deploying
to
staging
GitHub Actions
Failure
apparently workflow_dispatch is only valid from main
boringcactus
had a problem deploying
to
staging
GitHub Actions
Failure
boringcactus
had a problem deploying
to
staging
GitHub Actions
Failure
just this once, though, since `gh workflow run --ref mth-deploy` works
boringcactus
had a problem deploying
to
dev-orange
GitHub Actions
Failure
boringcactus
temporarily deployed
to
dev-orange
GitHub Actions
Inactive
| @@ -0,0 +1,71 @@ | |||
| on: | |||
There was a problem hiding this comment.
question: Could we use the department workflow deploy template for consistency?
One thing I really like from this is is the timeout-minutes configuration, which isn't specified in the template. Maybe that is something we could push upstream?
There was a problem hiding this comment.
That template uses the department deploy-ecs workflow, which uses the department build-push-ecr action, which just runs docker build from the command line, meaning we'd get no benefit from the GitHub Actions caching. There's a PR to change that, but it's incredibly stale.
Also, if we set up Sentry the same way Glides does, that'll be a further change to the deployment workflow.
There was a problem hiding this comment.
Ah got it, thanks for explaining that difference! In that case this seems good to me as-is, maybe just worth adding a comment to that stale PR to express why we see it as necessary in order to adopt that standard action.
There was a problem hiding this comment.
Left a comment there. Did not mention this project specifically, since that repo is public.
There was a problem hiding this comment.
Thanks! Appreciate your awareness and consideration around public & private repos! 🙇♀️
KaylaBrady
left a comment
KaylaBrady
left a comment
There was a problem hiding this comment.
Looks good to me! I'm a fan of the PR label to automatically deploy that you describe because it makes it easy to deploy & check what dev environments are in use - could you add that here or as a separate PR?
|
I can add it as a separate PR. |
Asana task: Deploy mobile backend to dev environment
Derived from the Glides deployment process, which is designed around a GitHub-releases-driven prod deployment workflow where manually assigned versions are used as Docker tags (and Sentry releases, but Sentry is not configured here yet). Adds an extra Docker container tag of
latest-$ENV.Glides also has a PR label set up to deploy automatically to dev-green, which has been useful there, but I'm not sure how useful it'd be here in the backend repo, so I haven't set it up here yet. If we think we'll want it, we may as well set it up now.
The environment names of
staginganddev-orangeare chosen in accordance with RFC 15. Orange was selected arbitrarily.Staging environment was created in https://github.com/mbta/devops/pull/1378.
Dev-orange environment was created in https://github.com/mbta/devops/pull/1380.