ci(verify): give each CodeBuild job a unique runner label

[aidandaly24]

Description

Gives the Linux and Windows verify matrix jobs a unique runner label (verify-linux, verify-windows) so GitHub cannot route one job to the runner CodeBuild created for the other.

Every CodeBuild job in a workflow run shares the codebuild-agentcore-e2e-<run_id>-<attempt> label, and CodeBuild registers each ephemeral runner with every label its job requested. The Windows runner therefore carries {base, image:windows-1.0}, a superset of the plain Linux job's {base}. When the Windows runner registers while the Linux job is still queued, GitHub hands it the Linux job. The Linux runner that arrives next has only {base}, so the Windows job never matches and sits queued until someone cancels and reruns.

Attempt 1 of the three runs reported in Slack shows exactly this pattern. In each, the Windows job was queued a few seconds before the Linux job, was cancelled without ever getting a runner, and a plain-label Linux job failed on a CodeBuild runner:

Run	Windows job with no runner	Linux job that ran on the Windows runner
33810416086	unit-test / Test (Windows)	build / Build (Linux)
33816761295	build / Build (Windows)	check / check
33878953551	verify / Build (Windows)	verify / check

AWS documents this failure mode and recommends a unique custom label per job: https://docs.aws.amazon.com/codebuild/latest/userguide/sample-github-action-runners-update-labels.html. CodeBuild ignores labels it does not recognize for build configuration but still registers them on the runner, so verify-linux and verify-windows only affect routing.

Any future CodeBuild job added to a run that also calls verify.yml needs its own label too, otherwise a plain-label job can still be picked up by the verify-linux runner and strand the Linux verify job.

This PR targets the feat/refactor-release-workflow branch so the fix lands together with verify.yml in #2206. ci.yml only triggers on PRs into main and refactor, so CI does not run on this PR itself; the change is exercised by the next CI run on #2206 after merge.

Related Issue

N/A. CI routing fix for the runner mis-assignment reported in Slack. Folds into #2206.

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots
• Parsed the workflow as YAML and parsed each runner value as JSON with the expressions substituted
• Confirmed the fix against attempt-1 job labels and runner assignments of the three failing runs above

Source tests were not run because this change only touches workflow runner labels.

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[agentcore-devx-automation]

AgentCore Harness Review

Verdict: Looks good

Small, well-explained CI fix. Adding per-job labels (verify-linux, verify-windows) alongside the shared codebuild-agentcore-e2e-* label correctly disambiguates which CodeBuild-hosted runner satisfies which matrix job. The inline comment captures the failure mode clearly and links to the relevant AWS docs.

One thing to confirm out-of-band (not visible in the diff): the CodeBuild project's webhook/label configuration needs to actually register runners with these new labels — otherwise jobs will sit queued indefinitely. Assuming that's been set up on the AWS side, this is good to merge.