Providers in w-m should be able to set workergroup to whatever they want. Currently we make an assumption that it maps to an AZ which can't necessarily always be true.

My proposal here is to introduce $TASKCLUSTER_WORKER_LOCATION of the format <cloud>/<details>, available within tasks. The <details> portion is specific to the cloud. For example, it would be AZ for Amazon and zone for Google. Hardware workers (standalone and static) will be able to define this string arbitrarily.

Taskcluster-worker-runner would be responsible for supplying this to workers. Workers will fall back to unknown/unknown in a case where it is not supplied, so the env var is always set.

This will be documented in taskcluster-service docs along with other per-task variables, and with reference to tc-worker-runner for per-cloud definition of <details>.

This is simple, but presents a user-visible change, so should probably be handled with an RFC.

https://github.com/taskcluster/taskcluster-rfcs/pull/148/files

Having decided, wander's going to finish this up.

https://github.com/taskcluster/taskcluster-worker-runner/pull/34

This version contains the TASKCLUSTER_WORKER_LOCATION environment
variable.

Create a worker pool to test builds in gcp

With the migration from AWS to GCP, we also need to migrate sccache
buckets from S3 to Google Storage.

The problem is how we deal with regions, since there isn't an exact
correspondence on the region names between the two cloud providers.

To make the transition smoother, docker-worker (and soon generic-worker)
provides a new environment variable called TASKCLUSTER_WORKER_LOCATION,
with information about the cloud provider the task is running on. Using
this new variable, we configure sccache to use the corresponding storage
service of the cloud provider where the task runs.

The bucket names in Google Storage are shorter because GCS imposes a
limit of 30 characteres for the names.

Ref: https://github.com/taskcluster/taskcluster-rfcs/pull/148/files

https://hg.mozilla.org/mozilla-central/rev/63eed8246c06

:grenade sccache support via gcpCredentials is ready, if you intend to implement in OCC, the only thing it is needed is the TASKCLUSTER_WORKER_LOCATION environment variable. It is a json string in the format:

{
  "cloud": "google|aws"
  "region": "<region name>"
  "availabilityZone": "<zone>"
}

when bug 1580430 is resolved, we should be able to spin up windows gcp workers again and i will add this env var

this variable is now being set on gcp windows workers.
https://papertrailapp.com/events?q=system%3Agamma%20program%3AOpenCloudConfig%20TASKCLUSTER_WORKER_LOCATION

we have windows builds running in gcp again. these instances have their TASKCLUSTER_WORKER_LOCATION environment variable set as can be seen in papertrail or build logs. USE_SCCACHE is also set to 1 however these builds are not making successful use of sccache and build logs do not contain an ===SCCACHE STATS=== section.