feat(ci): promote images from staging when deploying to prod #5
Conversation
…om-staging-to-prod * origin/main: fix: updated all json schemas (#22) feat: added kickoff_workflow (#9) revert: "chore: swap sampleId type to ID to support QualityControlQuery" (#20) feat: enable additional variables for PipelineData (#15) chore: swap sampleId type to ID to support QualityControlQuery (#16) feat: federeated /samples/validate_users_can_delete_objects (#14) feat: added coverage viz summary (#4) chore(main): release 1.6.0 (#11) chore: release 1.6.0 (#12) feat: Pass CSRF token when querying CZID Rails graphql (#10)
There was a problem hiding this comment.
Seems reasonable! Long term, it would be nice to eventually unpin and get back to being on @main rather than staying pinned to a specific version of the deploy-happy-stack action, just in case there's eventually a security patch or something we might forget about.
| with: | ||
| tfe-token: ${{ secrets.TFE_TOKEN }} | ||
| env: ${{ vars.HAPPY_ENV }} | ||
| create-tag: true |
There was a problem hiding this comment.
I see we're dropping create-tag: true entirely with this PR. I don't really know the specifics of deploy-happy-stack, but is this something we'd want to keep with what this PR is adding? It feels like if we wanted a tag created before, we would still want one now, but the new args don't seem to have anything to do with tagging one way or the other. Just wanted to make sure this was purposeful and not an accidentally cut out line!
There was a problem hiding this comment.
create-tag defaults to false
To use the image promotion, create-tag does need to be set to false, since that tells happy to assume that images already exist (for staging -> prod deployment via promotion, they "exist" in the staging env), so I've just dropped it here and relied on the default.
I believe the happy team actually recommended that I pin to a version, because they may make breaking changes to the action, which would break our deploy pipelines if we automatically use the latest version. But to your point, this is now something that we have to factor in maintenance for, to bump and test newer versions every once in a while (or if we're directed to do it for security or other urgent reasons) |
* CZID-8322-add-csrf-prevention:
feat: federated /workflow_runs/{args.workflowRunId}/zip_link.json (#25)
fix: Updated schema for kick off workflow (#27)
fix: Change schema back to next gen format (#28)
chore(main): release 2.0.0 (#26)
feat!: swap sampleId type to ID to support QualityControlQuery (#21)
chore(main): release 1.7.0 (#17)
feat(ci): promote images from staging when deploying to prod (#5)
fix: updated all json schemas (#22)
feat: added kickoff_workflow (#9)
revert: "chore: swap sampleId type to ID to support QualityControlQuery" (#20)
feat: enable additional variables for PipelineData (#15)
chore: swap sampleId type to ID to support QualityControlQuery (#16)
feat: federeated /samples/validate_users_can_delete_objects (#14)
feat: added coverage viz summary (#4)
Remove CSRF token header
Configure CSRF header plugin
Add csrf prevent plugin module
chore(main): release 1.6.0 (#11)
chore: release 1.6.0 (#12)
feat: Pass CSRF token when querying CZID Rails graphql (#10)
Pull Request
CZID-8804
Description
Implement prod deployment by promoting images from staging to prod. Locks our deploy action to use the version containing chanzuckerberg/github-actions/pull/228, which enables a new argument needed for this feature.
Notes
IMAGE_SOURCE_ROLE_ARNas Github secret in production environmentIMAGE_SOURCE_ENVandIMAGE_SOURCE_STACKwere previously set.