[Spanner] liquibase.properties shouldn't depend on TF local file

[dtest]

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.

[markmandel]

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.

[dtest]

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:

• terraform apply submits the secret
• cloudbuild pulls the secrets and builds the file,
• (optional) cloud build does the work instead of building an image.

If that sounds right, I can work on this after GDC

[markmandel]

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.