Open dtest opened 1 year ago
We could always use some gcloud commands and/or some default cloud build substitutions to do the work.
We could even download the spanner jar on each run too.
It's also possible we don't need to build an image - everything is mounted in /workspace so we might be able to use liquibase/liquibase:{version}
as the entire build step.
To me, building the image isn't the concern (other than taking the space in Artifact registry for potential debugging).
The default substitutions would provide PROJECT_ID.
The main question is where to get 'secrets' for cloud build (SPANNER_INSTANCE_ID and SPANNER_DATABASE_ID are what we need).
it seems like secrets manager might be the right approach.
So something like:
If that sounds right, I can work on this after GDC
There is nice integration with secret manager and cloud build -- but the information we need is all query-able with gcloud, which we can do in the cloud build script, which makes me thing Secret manager may be overkill.
If we move to automated cloud deploys, the liquibase build for schema migrations will likely fail due to not having a liquibase.properties file generated from TF.
We have this dependency due to getting something up and running quickly and that includes a few manual steps that follow the
terraform apply
setup.The main information that populates the
liquibase.properties
file is the Spanner project, instance_id, and database_id.Is there a better place we can pull these values from that Cloud Build would have access from? If so, the cloud build could write the
liquibase.properties
file instead of TF before generating the image.