Dustin J. Mitchell f8a58269bd Bug 1359976: base worker payload generation on worker-type; r=wcosta r=aki ... To date we have variously specified both worker-type and worker-implementation, often manually coordinated. We also embedded a few awkward assumptions such as that the native engine only runs on OS X. But a worker type has one and only one implementation, and that implementation is stable over time (as changing it would require simultaneous landings on all trees). Instead, this change makes worker-type the primary configuration, and derives both a worker implementation (defining the payload format) and worker OS (determining what to include in the payload) from that value. The derivation occurs when deciding how to implement a particular job, where the run_using functions are distinguished by worker implementation. The two-part logic to determine how and where to run a test task based on its platform is combined into a single transform, `set_worker_type`. This contains some other related changes: - MOZ_AUTOMATION is set in specific jobs, rather than everywhere docker-worker is used - the URL to test packages is factored out into a shared function - docker-worker test defaults are applied in `mozharness_test.py` - the WORKER_TYPE array in `task.py`, formerly mixing two types of keys, is split - the 'invalid' workerType is assigned an 'invalid' implementation - all tasks that do not use job descriptions but use docker-worker, etc. have `worker.os` added Tested to not produce a substantially different taskgraph for a regular push, a try push, or a nightly cron. MozReview-Commit-ID: LDHrmrpBo7I --HG-- extra : rebase_source : 4cdfe6b8d9874b0c156671515b213d820b48482f		2017-05-08 22:53:50 +00:00
..
kind.yml	Bug 1359976: base worker payload generation on worker-type; r=wcosta r=aki	2017-05-08 22:53:50 +00:00