Skip to content
This repository has been archived by the owner on Jul 25, 2024. It is now read-only.

Switch Cloud Run deployed revision prefix to build ID #705

Open
grayside opened this issue Nov 14, 2022 · 0 comments
Open

Switch Cloud Run deployed revision prefix to build ID #705

grayside opened this issue Nov 14, 2022 · 0 comments
Labels
component: delivery Related to automation, testing, deployment of the application. priority: p2 Moderately-important priority. Fix may not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@grayside
Copy link
Collaborator

grayside commented Nov 14, 2022

Proposal

Currently, the deploy.cloudbuild.yaml uses the Pub/Sub messageId as the revision prefix. However, this messageId is not generally useful to look up details about the process separate from acking the message in the event of a retry loop. We should definitely log it as part of the build if Cloud Build doesn't do that for us.

However, what we don't have right now is provenance from the Cloud Run revision to the build that ran the deployment. The build context for the container image is available to Cloud Run, but since we have a split build & deploy process, we don't have a direct connection to the deploy build and it's logs.

It would be great if the revision where either:

  • Based on the Build ID
  • Based on the Git Commit hash and that this hash is usable to look up all related builds in the Cloud Build history.

Part of why we aren't using Build ID is the potential for revision name character limits not being large enough to encompass a UUID. The allowed revision length has changed multiple times in the past, we should verify current state.

Problems this will solve

  • Improve completeness of build & deploy provenance from a Cloud Run perspective.
  • Facilitate easier collection of complete set of logs associated with shipping a single change
@grayside grayside added type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. priority: p2 Moderately-important priority. Fix may not be included in next release. component: delivery Related to automation, testing, deployment of the application. labels Nov 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
component: delivery Related to automation, testing, deployment of the application. priority: p2 Moderately-important priority. Fix may not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

1 participant