Tags: m-lab/visualizations
Tags
Moves all production deployment to a single build step (#11) Previously, one build step would deploy app.yaml in production, and then a second build step would deploy dispatch.yaml. This was causing build failures on the 2nd step because even though the first build step completed as far as Cloud Build was concerned, GCP had launched some other operations in the background to promote the new deployment and deleted the old one. The second step was failing because gcloud wouldn't launch a new operation for the service while there were still operations in progress. This change moves all production deployments steps to a single build step, and even more to a single invocation of `gcloud app deploy`. In this way, gcloud can decide when it it safe to deploy app.yaml and dispatch.yaml in relation to one another.
Uses Artifact Registry build images (#7) * Uses Artifact Registry build images And the name of the build image is stored as a user-defined substitution variable in the build trigger in each project. This is because the flow for this repo is mlab-sandbox -> mlab-staging -> measurement-lab, but the build images are not present in the measurement-lab project. That project uses the mlab-oti image, since both are production projects. * Substitutes _only_ the image project Rather than substituting the entire build image path, this commit changes that to only substitute the project of the build image to make it more transparent in the code what is being run.