[QUESTION] Possible to stand up MySQL in the same container for testing?

[LarryBarker]

@jhoughtelin Hey there 👋 Just came here from your video on deploying to Cloud Run, really helpful content. We have a pretty heavy CI/CD pipeline with using Cloud Build + Cloud Run (everything is managed with Terraform).

Anyhow, we just finished setting up preview URLs, and are wondering how we can stand up MySQL in the container so we have a fully isolated environment for testing PRs. We use a cloudbuild.yaml file for the Cloud Build trigger.

Do you have any thoughts on how this can be done?

Thanks for the content, appreciate any feedback you may have 🙏

[jhoughtelin]

Where is your database? Is it in CloudSQL or a standalone instance accessible from the public web?

[LarryBarker]

@jhoughtelin Hey thanks for the follow up! So the production environment uses a CloudSQL instance. What we're trying to do is stand up a new instance inside of the same container when we deploy a revision so we can test in isolation. Here's a link to the article that outlines how to configure deployment previews: https://cloud.google.com/run/docs/tutorials/configure-deployment-previews

We're essentially doing the same thing, just for a Laravel app. Challenge is, if the PR contains database changes, these are going to run against the same database used in production before the code has been tested and may actually be ready for production.

We thought about standing up a separate CloudSQL instance for previews, but then all previews will share the same database so there is potential for the same problem. For example, say PR-1 has changed the database, but PR-2 is expecting a different schema, both of these PRs will be deployed as their own service, but be referencing the same database.

Thanks for your patience with my long winded explanation :D

[jhoughtelin]

I believe understand your problem know. I have not used cloud run in this manner. Most of the testing I work with is done using local-ish docker configurations to support branch specific testing. It sounds like your case is going to require creating a new schema from a clone in an existing VM with some kind of dynamic naming mechanism potentially associated to the git commit hash and then cary that through as an environment variable for the database name in the cloud run instance. I have not personally replicated the approach I use for local development and automated testing in cloud run for this particular scenario to be able to instantiate, migrate and seed a database when it's brought online.