Cloud Run pipeline to staging #69
Conversation
google-cla
bot
added
the
cla: yes
| @@ -0,0 +1,26 @@ | |||
| # Copyright 2021 Google LLC | |||
There was a problem hiding this comment.
Should Documentation & Decision records be blockers or follow-up issues?
There was a problem hiding this comment.
Unsure - maybe should be discussed at our meeting today?
There was a problem hiding this comment.
Seems we missed this in meeting. My general preference is that each PR includes any relevant decision records, but my position on this is flexible while we figure out how that impacts velocity.
| - 'build' | ||
| - '-t' | ||
| - 'us-central1-docker.pkg.dev/${PROJECT_ID}/${_DIR}/${_DIR}:${SHORT_SHA}' | ||
| - '${_DIR}/.' |
There was a problem hiding this comment.
What is ${_DIR}/. mean to enable?
There was a problem hiding this comment.
The idea was to be able to use the same builder for the website and content-api. The build initiates from the root directory and dives down into _DIR/ to find the appropriate Dockerfile.
There was a problem hiding this comment.
I think it's worth having a comment that this builder is used for all container images. This is also worth a decision record.
I think there's definitely value here in creating a unified build process, especially if this is where we ensure provenance, add binauth attestation later on, etc.
| # TODO: Run tests, revert back to previous revision if failure | ||
|
|
||
| # Cloud Run Canary | ||
| - id: 'Update Traffic' |
There was a problem hiding this comment.
comment: I think this is a good starting place, but I expect we'll iterate significantly in defining how canary rollouts work. How does status that a rollout is partial/complete get reported?
There was a problem hiding this comment.
It's writing to a pub/sub topic, so we can subscribe to that. We can also see it in the Cloud Run UI.
| - --platform=managed | ||
| - --revision-suffix=${_REVISION} | ||
| - --project=${_TARGET_PROJECT} | ||
| - --allow-unauthenticated |
There was a problem hiding this comment.
I was thinking for Prod it would have to be unauthenticated and I want the staging rollout to be as much like the prod one as possible.
Note, this is all after all the checks on the PR and it's merged into main. So at this point there should have already been a private service built and tested against as part of an e2e test. For the CD pipeline, even though this is staging, I wanted it to be as much like prod as possible.
|
RE Should I include a step that prints out the pub/sub message for debugging? My 2¢: maybe, but comment it out if you do? That way it might function as a "teachable moment" on how to debug with Pub/Sub. |
|
Adding debug print statement
| @@ -0,0 +1,26 @@ | |||
| # Copyright 2021 Google LLC | |||
There was a problem hiding this comment.
Seems we missed this in meeting. My general preference is that each PR includes any relevant decision records, but my position on this is flexible while we figure out how that impacts velocity.
| - 'build' | ||
| - '-t' | ||
| - 'us-central1-docker.pkg.dev/${PROJECT_ID}/${_DIR}/${_DIR}:${SHORT_SHA}' | ||
| - '${_DIR}/.' |
There was a problem hiding this comment.
I think it's worth having a comment that this builder is used for all container images. This is also worth a decision record.
I think there's definitely value here in creating a unified build process, especially if this is where we ensure provenance, add binauth attestation later on, etc.
Initial Cloud Run CD pipeline
This pipeline:
This setup requires creating triggers, artifact registry repos, pub/sub topics, and adjusting permissions. Should I include the terraform in this PR or in a followup?
Other question, should I include a step that prints out the pub/sub message for debugging?
Staging website here: https://website-qo2ri6lf3a-uc.a.run.app