- Mar 09, 2021
-
-
Dr Rich Wareham authored
-
Dr Rich Wareham authored
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
-
- Jan 27, 2021
-
-
Dr Rich Wareham authored
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
-
Dr Rich Wareham authored
Use Google Beta provider to allow for min-scale option See merge request !16
-
Monty Dawson authored
-
Monty Dawson authored
-
Monty Dawson authored
- Jan 11, 2021
-
-
Dr Abraham Martin authored
allow ingress type to be specified See merge request !13
-
- Jan 08, 2021
-
-
Dr Rich Wareham authored
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.
-
Dr Rich Wareham authored
The "run.googleapis.com/ingress-status" annotation is maintained by the infrastructure Google-side so ignore changes to it.
-
Dr Rich Wareham authored
Add support for minimum Cloud Run container instances (`min_scale`) Closes #12 See merge request !14
-
Dr Abraham Martin authored
-
Dr Rich Wareham authored
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.
-
- Dec 10, 2020
-
-
Dr Abraham Martin authored
allow stackdriver host project to differ from monitored project Closes #11 See merge request !12
-
Dr Rich Wareham authored
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
-
- Dec 09, 2020
-
-
Dr Rich Wareham authored
Expose the monitoring path in the Cloud Run module, otherwise we can't set it up. Closes #10 See merge request !11
-
Dr Abraham Martin authored
-
Dr Abraham Martin authored
-
Dr Abraham Martin authored
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.
-
- Aug 20, 2020
-
-
Dr Rich Wareham authored
Modify minimum Google provider version to >= 3.35, < 4.0 Closes #9 See merge request !10
-
- Aug 19, 2020
-
-
Dave Hart authored
-
- Aug 06, 2020
-
-
Dr Rich Wareham authored
Fix basic alerting so that it... alerts. See merge request !9
-
- Aug 05, 2020
-
-
Paul Rudin authored
-
- Aug 04, 2020
-
-
Robin Goodall authored
Basic alerting See merge request !7
-
-
- Jul 30, 2020
-
- Jul 29, 2020
-
-
- Jun 16, 2020
-
-
Dr Abraham Martin authored
allow webapp service account id to be customised and SQL instance to be blank Closes #5 and #6 See merge request !6
-
Dr Rich Wareham authored
-
- Jun 11, 2020
-
-
Dr Rich Wareham authored
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
-
Dr Rich Wareham authored
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
-
- May 04, 2020
-
-
Robin Goodall authored
remove random generated name hack Closes #4 See merge request !5
-
- Apr 17, 2020
-
-
Dr Rich Wareham authored
-
Dr Rich Wareham authored
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
-
- Mar 27, 2020
-
-
Dr Abraham Martin authored
main.tf: don't ignore changes in name See merge request !4
-
Dr Rich Wareham authored
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.
-
- Mar 26, 2020
-
-
Dr Rich Wareham authored
Resolve CI changes not being ignored by terraform Closes #3 See merge request !3
-
Robin Goodall authored
-
- Mar 25, 2020
-
-
Dr Abraham Martin authored
Add optional domain mapping Closes #2 See merge request !2
-