This is initially planned to execute Django database migrations. However,
other use cases will exist I'm sure.

BREAKING CHANGE: Upgrading to v3 of the gcp-site-monitoring module
will cause uptime check functions to be destroyed/re-created during the
next Terraform apply.

Currently uses sql_instance_connection_name which causes
issues when the provided value is not known until apply.

A map cannot have a key which depends on a resource which is unknown.
To resolve this issue I've refactored the map to have known key names.

Closes #38

As referencing Secret Manager secrets has moved to GA. See:
https://cloud.google.com/run/docs/release-notes#November_09_2021

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.

There are a few more attributes which Google has started using
internally to record state. Add them to the ignore changes list so that
terraform won't keep wanting to change resources.

Part of uis/devops/raven/infrastructure#32

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

It would appear that the "run.googleapis.com/ingress" annotation can be
set to "all" without having to enable the beta launch stage. Indeed it
*has* to be set to "all" since attempting to unset it causes Cloud Run
to immediately reset it.

The "run.googleapis.com/ingress-status" annotation is maintained by the
infrastructure Google-side so ignore changes to it.

Provide a variable which allows ingress type to be specified. This
allows placing the service behind Cloud Load Balancer.

Provide variables which allow extra annotations to be added to the Cloud
Run service and the service template.

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