Skip to content

Add build worker integration tests with worker type filtering#669

Draft
jwmossmoz wants to merge 6 commits intomainfrom
add-build-worker-integration-tests
Draft

Add build worker integration tests with worker type filtering#669
jwmossmoz wants to merge 6 commits intomainfrom
add-build-worker-integration-tests

Conversation

@jwmossmoz
Copy link
Contributor

@jwmossmoz jwmossmoz commented Jan 21, 2026

Summary

  • Add support for running Gecko build tasks on alpha worker pools through the integration test pipeline
  • Add filter_by_worker_type.py transform to filter replicated tasks by workerType
  • Add cross-provisioner pool mapping support to handle gecko-3/b-win2022gecko-1/b-win2022-alpha

Problem

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

  1. New filter_by_worker_type.py transform: Filters replicated tasks by their workerType field in the task definition. This allows selecting specific tasks (like builds) that use a particular worker type.

  2. Enhanced integration_test.py transform:

    • Added worker-pool-mappings schema support for explicit pool mappings
    • Supports cross-provisioner mappings (e.g., gecko-3gecko-1)
    • Fixed label prefix matching to use longest-match-first ordering
  3. New gecko-builds task in kind.yml:

    • Replicates build tasks from mozilla-central decision task
    • Filters to only b-win2022 worker type
    • Maps gecko-3/b-win2022 to gecko-1/b-win2022-alpha

Note 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:

gecko-builds:
  description: "Run Gecko build tasks on alpha worker pools"
  filter-worker-types:
    - b-win2022
  worker-pool-mappings:
    gecko-3/b-win2022: gecko-1/b-win2022-alpha
  replicate:
    target:
      - gecko.v2.mozilla-central.latest.taskgraph.decision
    include-attrs:
      kind:
        - build
    exclude-attrs:
      build_platform:
        - android
        - macosx
        - linux

Test plan

  • Run TASK_ID=test-task-id uv run taskgraph full --fast -k integration-test locally
  • Verify build tasks appear in output with correct pool mapping
  • Verify provisionerId: gecko-1 and workerType: b-win2022-alpha in task JSON
  • Run integration tests on Taskcluster to verify end-to-end

Files changed

  • taskcluster/kinds/integration-test/kind.yml - Added gecko-builds task definition
  • taskcluster/worker_images_taskgraph/transforms/filter_by_worker_type.py - New transform
  • taskcluster/worker_images_taskgraph/transforms/integration_test.py - Added pool mapping support

🤖 Generated with Claude Code

jwmossmoz and others added 6 commits January 21, 2026 12:12
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>
@jwmossmoz jwmossmoz marked this pull request as draft February 13, 2026 16:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant