Add build worker integration tests with worker type filtering#669
Draft
Add build worker integration tests with worker type filtering#669
Conversation
Add support for running Gecko build tasks on alpha worker pools as part of integration testing. This enables testing build workers (like b-win2022) alongside the existing os-integration test tasks. Changes: - Add filter_by_worker_type.py transform to filter replicated tasks by workerType field in the task definition - Add gecko-builds task to integration-test kind that: - Targets the full gecko decision task (not os-integration) - Filters to only build kind tasks - Filters by worker type (b-win2022) to select relevant builds - Excludes android/macosx/linux builds (no alpha pools) The filter transform is designed to work with the replicate transform, allowing fine-grained selection of tasks based on which worker pool they run on. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Sort task definitions by name length (longest first) to ensure more specific prefixes like "gecko-builds" match before shorter ones like "gecko". This fixes an issue where "gecko-builds-build-win64/opt" was incorrectly matching the "gecko" task definition instead of "gecko-builds". The fix ensures that cross-provisioner pool mappings (e.g., gecko-3/b-win2022 to gecko-1/b-win2022-alpha) are correctly applied to build tasks. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Change gecko-builds task to replicate from autoland (level 1, gecko-1 provisioner) instead of mozilla-central (level 3, gecko-3 provisioner). This avoids chain of trust issues since gecko-3 workers have CoT keys that shouldn't be used on alpha/test pools. Level 1 builds from autoland use gecko-1 provisioner, so the default -alpha suffix mapping works. Note: Requires gecko-1/b-win2022-alpha pool to be created in Taskcluster. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Revert to mozilla-central as the source for build tasks since autoland doesn't have Windows builds using b-win2022. The cross-provisioner mapping (gecko-3/b-win2022 -> gecko-1/b-win2022-alpha) remaps level 3 builds to the level 1 alpha pool. CoT won't be valid for these integration tests, but that's acceptable since we're testing the worker image functionality, not producing release artifacts. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
filter_by_worker_type.pytransform to filter replicated tasks by workerTypegecko-3/b-win2022→gecko-1/b-win2022-alphaProblem
When testing build workers like
b-win2022, there was no way to run build tasks through the worker-images integration test pipeline. The Firefox os-integration system only includes test tasks (TEST_KINDS), not builds. Users had to manually push to try with worker overrides to test build tasks on alpha pools.Solution
New
filter_by_worker_type.pytransform: Filters replicated tasks by theirworkerTypefield in the task definition. This allows selecting specific tasks (like builds) that use a particular worker type.Enhanced
integration_test.pytransform:worker-pool-mappingsschema support for explicit pool mappingsgecko-3→gecko-1)New
gecko-buildstask in kind.yml:b-win2022worker typegecko-3/b-win2022togecko-1/b-win2022-alphaNote on Chain of Trust
The cross-provisioner mapping redirects level 3 builds (gecko-3) to level 1 alpha pools (gecko-1). CoT will not be valid for these integration test runs, but this is acceptable since we're testing the worker image functionality, not producing release artifacts.
Usage
The configuration in
kind.yml:Test plan
TASK_ID=test-task-id uv run taskgraph full --fast -k integration-testlocallyprovisionerId: gecko-1andworkerType: b-win2022-alphain task JSONFiles changed
taskcluster/kinds/integration-test/kind.yml- Added gecko-builds task definitiontaskcluster/worker_images_taskgraph/transforms/filter_by_worker_type.py- New transformtaskcluster/worker_images_taskgraph/transforms/integration_test.py- Added pool mapping support🤖 Generated with Claude Code