Modify the CD github action to support independently deploy different apps within an environment
Modify the CD github action to become a reusable workflow
Add a "deploy on push" github action to calls the CD github action conditionally
Modify the participant portal CI and storybook CD github actions to only run if there are changes to themselves or the participant_portal dir
Modify Makefile, bin/deploy-release.sh, and bin/publish-release.sh to support alternate a data model where there is one infra "app" but multiple project "apps"
Add back participant_portal/Makefile to support CD; set the target to the prod image
Fix bug in participant_portal/Dockerfile; npm run css must be done before npm run build because it requires participant_portal/app/styles/styles.css to exist
Context for reviewers
Testing instructions, background context, more in-depth details of the implementation, and anything else you'd like to call out or ask reviewers. Explain how the changes were verified.
This PR modifies our CD to support a slightly different data model than the infra template currently supports. Namely, we want:
multiple environments - this is the same; see infra/app/envs
each environment has a single controlling terraform module - this is the same; see infra/app/envs/prod
each environment has multiple applications (an application here is defined as something that needs a service, a load balancer, etc) that have shared resources (such as a database, IAM config, container registry, etc) - this is not necessarily different
each environment should be able to independently deploy each application (i.e. we should be able to deploy the participant portal to the dev environment without having to also deploy the staff portal) - this is different; note that I think this only works is this reusable way because each of our apps is deployed the same way (e.g. build a docker image, publish the docker image, deploy the docker image)
Although we could organize the infra dir to have multiple "app" dirs (e.g. one for the participant portal, one for the staff portal, etc), this isn't actually what we want. We want to be able to share resources across our apps.
To accomplish this, I've made some changes.
I modified the CI/CD paradigm to support the concept of an "infra_app_name" (i.e. app) and an "app_name" (e.g. participant_portal, staff_portal). Each of these apps can be auto-deployed independently from one another
I also turned the CD github action into a reusable workflow (it can still be used to manually deploy in the github web interface).
I also created a new wrapper github action that will check each of our app dirs to see if any files have been modified (e.g. added, renamed, deleted, changed) and deploy the app if there has been a change.
Feedback
It might be possible to DRY up the cd-on-push.yml, but I didn't want to keep pursuing this further. This can be saved for a future refactoring exercise. However, if you, the reviewer, know how to do this in Github Action syntax, please let me know!
Testing
Screenshots, GIF demos, code examples or output to help show the changes working as expected. ProTip: you can drag and drop or paste images into this textbox.
Select "Run workflow" and choose this branch (PRP-166-cd-connect-the-infrastructure). Leave the default settings.
To verify the deploy on push github action:
This workflow run demonstrates that it works when a change has been made to a file in a watched directory (in this case the participant_portal dir). Note that the other apps (staff_portal and analytics) did not trigger a deploy because no files were changed in those directories. It's ok that the deploy itself failed; that's a IAM permissions problem unrelated to this CD trigger.
This other workflow demonstrates that it works when a file is deleted in a watched directory.
To verify that the bugs in the participant_portal Makefile and Dockerfiles have been fixed (these are also tested in the above workflow runs, but here are the manual testing instructions):
Run cd participant_portal && docker compose build. You should get no errors.
Run make release-build APP_NAME=participant_portal. You should get no errors.
rocketnova
commented
1 year ago
Ticket
https://wicmtdp.atlassian.net/browse/PRP-166
Changes
prodimagenpm run cssmust be done beforenpm run buildbecause it requires participant_portal/app/styles/styles.css to existContext for reviewers
This PR modifies our CD to support a slightly different data model than the infra template currently supports. Namely, we want:
Although we could organize the infra dir to have multiple "app" dirs (e.g. one for the participant portal, one for the staff portal, etc), this isn't actually what we want. We want to be able to share resources across our apps.
To accomplish this, I've made some changes.
app) and an "app_name" (e.g.participant_portal,staff_portal). Each of these apps can be auto-deployed independently from one anotherFeedback
It might be possible to DRY up the cd-on-push.yml, but I didn't want to keep pursuing this further. This can be saved for a future refactoring exercise. However, if you, the reviewer, know how to do this in Github Action syntax, please let me know!
Testing
To verify the CD github action:
To verify the deploy on push github action:
To verify that the bugs in the participant_portal Makefile and Dockerfiles have been fixed (these are also tested in the above workflow runs, but here are the manual testing instructions):
cd participant_portal && docker compose build. You should get no errors.make release-build APP_NAME=participant_portal. You should get no errors.TODO