Arun Patel authored 3 years ago and Wajdi Hajji committed 3 years ago

This works with Terraform v0.14.10; the data source is read before
the plan walk, so the existing deployed image can be determined.
However, it is suggested that future Terraform may combine the
refresh and plan walks which *may* result in a cyclic dependancy.

Arun Patel authored 3 years ago and Wajdi Hajji committed 3 years ago

This works with Terraform v0.14.10; the data source is read before
the plan walk, so the existing deployed image can be determined.
However, it is suggested that future Terraform may combine the
refresh and plan walks which *may* result in a cyclic dependancy.

This works with Terraform v0.14.10; the data source is read before
the plan walk, so the existing deployed image can be determined.
However, it is suggested that future Terraform may combine the
refresh and plan walks which *may* result in a cyclic dependancy.

Rather than ship our own monitoring module, make use of the
gcp-site-monitoring module. This effectively makes this module require
0.13 so a major version bump is required.

Closes #13

As noted in #11, we do not support the common case where a single
Stackdriver workspace hosts multiple projects. Do this by requiring a
Google provider for the Stackdriver workspace be passed to the module is
alerting is enabled.

We use a separate provider because the provider used must be able to
create monitoring resources *in the host project*. In the case of our
standard deployment, this implies it needs *product admin* credentials.

We no longer need to enable the monitoring service since this service a)
needs to be enabled in the *host* project and b) the service will have
been enabled as a necessary side-effect of creating the Stackdriver
workspace.

Closes #11

This module manages a Cloud Run-hosted container. It takes care of making
sure the container is connected to a Cloud SQL instance and sets
environment variables on the application.