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

make use of our common monitoring module

Closes #13

See merge request !15

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

Use Google Beta provider to allow for min-scale option

See merge request !16

allow ingress type to be specified

See merge request !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.

Add support for minimum Cloud Run container instances (`min_scale`)

Closes #12

See merge request !14

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.

allow stackdriver host project to differ from monitored project

Closes #11

See merge request !12

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

Expose the monitoring path in the Cloud Run module, otherwise we can't set it up.

Closes #10

See merge request !11

Also remove the alerting_enabled default to false for two reasons:
1) To force the developer to make a decision on monitoring
2) If alerting_enabled is true but alerting_email_address is not set up, then there is not much point as we don't have any other channel set up.

Modify minimum Google provider version to >= 3.35, < 4.0

Closes #9

See merge request !10

Fix basic alerting so that it... alerts.

See merge request !9

Basic alerting

See merge request !7

Add support for timeout_seconds to be passed as a variable

Closes #8

See merge request !8

allow webapp service account id to be customised and SQL instance to be blank

Closes #5 and #6

See merge request !6

Sometimes we don't need a SQL instance for the webapp. Allow
sql_instance_connection_name to be empty and, if so, don't add the Cloud
SQL connection roles to the service account or add the SQL instance
annotation to the webapp.

Closes #5

As noted in #6, we were hard-coding the service account id used for the
webapp to "webapp-run". This meant it was impossible to deploy more than
one webapp in a project.

Form a better default from the "name" variable. For existing deployments
the service account id will be unchanged if the "name" variable is at
its default value.

Allow the service account id to be specified explicitly via the
optional "service_account_id" variable.

Closes #6

remove random generated name hack

Closes #4

See merge request !5

We no longer need the random id hack for generating Cloud Run resource
names as the provider now supports a autogenerate_revision_name flag
which allows Google to generate the appropriate resource name for us.

Closes #4

main.tf: don't ignore changes in name

See merge request !4

Ignoring changes in name means that one can never run terraform
deployments beyond the initial creation of the webapp service. Terraform
will always modify a service in-place but try to use the same name which
negates the point of *setting* the name in the
google_cloud_run_service.webapp resource.

The downside of this is that one can't then deploy changes without
deleting and re-creating random_id.webapp_revision_name resource but
that is at least documented in the README.

Resolve CI changes not being ignored by terraform

Closes #3

See merge request !3

Add optional domain mapping

Closes #2

See merge request !2