BCDA-9263: Fargate workflows #1222
Conversation
|
Nit: can we rename the PR to the standard format BCDA-XXXX: |
carlpartridge
changed the title
| repository: CMSgov/bcda-app | ||
| ref: ${{ inputs.release_version }} | ||
| - name: Set ECR_URL | ||
| run: echo "ECR_URL=${{ secrets[matrix.vars.account_id] }}.dkr.ecr.us-east-1.amazonaws.com/bcda-api" >> $GITHUB_ENV |
There was a problem hiding this comment.
Which ECR do we push to? Should we push to both prod and non-prod ECRs every time we create a new tag?
There was a problem hiding this comment.
Right now we are pushing to both prod and non-prod for each deploy. We will eventually need these in both places. We only publish once per release tag so I dont think thats a big deal. I need to adjust this a bit for dev as we do deploy that daily and its probably not ideal to have a 'main' nor a 'latest' tag that doesnt align with the latest release tag in prod.
Edit: Updated to account for dev autodeploy.
| $(eval CURRENT_COMMIT=$(shell git log -n 1 --pretty=format:'%h')) | ||
| $(eval DOCKER_REGISTRY_URL=${ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com/bcda-worker) | ||
| docker build -t ${DOCKER_REGISTRY_URL}:latest -t '${DOCKER_REGISTRY_URL}:${CURRENT_COMMIT}' -f Dockerfiles/Dockerfile.bcdaworker_prod . | ||
| docker build -t ${DOCKER_REGISTRY_URL}:latest -t '${DOCKER_REGISTRY_URL}:${RELEASE_VERSION}' -f Dockerfiles/Dockerfile.bcdaworker . |
There was a problem hiding this comment.
Do we need the publish make commands if we don't use them in our github workflow?
There was a problem hiding this comment.
These came first so I updated them. I think they could be useful as a manual process outside of gh workflows. Could also argue that either we should use these make commands in the gh workflow itself or that we should get rid of these make commands.
| SSAS_RELEASE_VERSION: ${{ inputs.ssas_release_version || 'main' }} | ||
| RELEASE_ENV: ${{ inputs.env || 'dev' }} | ||
| CONFIRM_RELEASE_ENV: ${{ inputs.confirm_env || 'dev' }} | ||
| VERIFICATION_RETRIES: 90 # 90 retries with 10s sleep = max 900s or 15m. Verification jobs run in parallel. |
There was a problem hiding this comment.
are we essentially giving ourselves 15 minutes to determine for the service to come up? Can this timeframe be reduced?
3 participants
🎫 Ticket
https://jira.cms.gov/browse/BCDA-9263
🛠 Changes
Add workflows to build, publish, and deploy all services via ECS/fargate.
ℹ️ Context
Part of our move to fargate.
🧪 Validation
Workflow testing