feat: ci to build new registry on push to main #363
Conversation
…by the github action
…L for some reason
| branches: | ||
| - main | ||
|
|
||
| pull_request: |
There was a problem hiding this comment.
Do we want to deploy on each PR too?
There was a problem hiding this comment.
No I should pull that out, was moving too quickly, good catch 🙏
.github/scripts/deploy-registry.sh
Outdated
| # Trigger a build for dev | ||
| # DONT EVER SET ANY FLAGS THAT MIGHT PRINT THE URL, AS IT HAS SECRETS IN IT | ||
| curl -X POST "https://cloudbuild.googleapis.com/v1/projects/coder-registry-1/triggers/http-build-registry-v2-dev:webhook?key=${GCLOUD_API_KEY}&secret=${GCLOUD_DEV_DEPLOY_SECRET}" \ | ||
| -H "Content-Type: application/json" \ | ||
| -d '{}' \ | ||
| --fail |
There was a problem hiding this comment.
I'm not entirely convinced about this approach. We could maybe instead trigger a build using the gcloud CLI (ref: https://cloud.google.com/sdk/gcloud/reference/builds/triggers/run) in combination with the setup-gcloud action (https://github.com/google-github-actions/setup-gcloud)
There was a problem hiding this comment.
cc @deansheather for some additional eyes.
There was a problem hiding this comment.
Absolutely would prefer to use gcloud CLI rather than calling googleapis from curl. We also should not be using service account credentials as actions secrets, and should use workload identity instead. I can help you set that up with a new SA for this repo @bcpeinhardt
There was a problem hiding this comment.
Secrets deleted, will update to use the gcloud cli, and yes some help with a service account would be great haha 😎
.github/scripts/deploy-registry.sh
Outdated
| # Trigger a build for prod | ||
| # DONT EVER SET ANY FLAGS THAT MIGHT PRINT THE URL, AS IT HAS SECRETS IN IT | ||
| curl -X POST "https://cloudbuild.googleapis.com/v1/projects/coder-registry-1/triggers/http-build-registry-v2-trigger:webhook?key=${GCLOUD_API_KEY}&secret=${GCLOUD_PROD_DEPLOY_SECRET}" \ | ||
| -H "Content-Type: application/json" \ | ||
| -d '{}' \ | ||
| --fail |
There was a problem hiding this comment.
Should this perhaps be a separate step in the workflow?
There was a problem hiding this comment.
Honestly I would even consider removing it from the workflow. Since we have a dev environment now a little delay to review there might not be the worst thing.
| push: | ||
| branches: | ||
| - main | ||
| - bcpeinhardt/ci-to-build-new-registry-on-push-to-main |
There was a problem hiding this comment.
don't forget to take this out.
| - bcpeinhardt/ci-to-build-new-registry-on-push-to-main |
There was a problem hiding this comment.
Yeah I'm still testing haha but thank you 🙏 putting this in draft until it's ready.
|
Uh merging in main cause the git-clone test to fail. I don't think that was me but would appreciate a second look. |
This PR adds a github actions workflow for deploying new revisions of the registry on pushes to main.
This means updating the new registry will continue to be as simple as landing a PR in this repo, but it should only take as long as the docker container takes to build to see the updates live :)
I don't love that cloud build wants me to pass the build secret and API key as query params but I went through the raw logs for the workflow and it doesn't get logged there.