ci(health-check): run on push to main + split into pr / main / reusable

[xmfcx]

• Parent Issue: Simplify the docker images and workflows #6852
• Add a push: main trigger to health-check.yaml so merges populate the :health-check-*-main registry cache — previously it only ran on PR/schedule/dispatch, starving subsequent PRs of warm layers.
• Split the three trigger modes out of the monolithic workflow:
  • health-check-pr.yaml (new): pull_request with paths: at the trigger level + require-label.yaml@v1 gate, calls the reusable on success. paths: replaces the per-step changed-files conditional; the hard label gate turns a watched-path PR without run:health-check red instead of silently skipping.
  • health-check-reusable.yaml (new): workflow_call with the matrix docker-build job; step-level if:s reduced to orthogonal matrix filters (build-type != 'main', platform == 'arm64', build-type == 'nightly').
  • health-check.yaml (trimmed): push: main, schedule, workflow_dispatch, calls the reusable.
• Drop the scenario-test downstream job from the PR path along with the docker save + upload-artifact steps that fed it and load: true on the bake step (only needed for the save). scenario-test-reusable.yaml is deleted in the same PR since nothing else referenced it. Merge-time scenario coverage is unaffected: the standalone scenario-test.yaml (cron + push: main + workflow_dispatch) still runs and does not use the reusable.
• ~10 repeated if: conditionals gone; the changed-files step gone; each trigger mode expressed in its own file.

Why

The previous single-file workflow mixed pull_request / schedule / workflow_dispatch behind identical per-step guards. Untangling them into trigger-specific files removes the conditional thicket, makes the label gate hard-fail (red) instead of silent-skip, and lets push: main runs keep warming the shared BuildKit registry cache that PR builds read as their fallback. Scenario-test is dropped from the PR path (and its now-orphaned reusable deleted) so that restructuring doesn't have to carry the artifact save/upload round-trip; the standalone merge-time scenario workflow still exercises the same coverage, and a PR-gated form will be brought back in a follow-up once its shape is reworked.

---

• 3 of 6 PRs splitting ci(docker-new): split base-cuda layer and restructure CI pipelines #7025. Builds on ci: gate setup-universe behind run:health-check, unify label reusable #7029 (merged).
• Cache-rewire (scope change + buildkit-cache-dance injection) is intentionally held back to the next PR so this one stays focused on trigger restructuring + PR-path scenario-test removal.

Test plan

• Open a PR touching docker-new/** without the run:health-check label: expect health-check-pr / require-label red and the reusable job skipped.
• Add the label to that PR: expect require-label green, the reusable workflow (docker-build matrix) running; confirm no scenario-test job appears in the run.
• Push this branch to main: expect health-check / health-check to run with no label gate, populating ghcr.io/${{ github.repository }}-buildcache-new:*-main tags, and scenario-test to run independently as before.
• Dispatch health-check via the Actions UI (workflow_dispatch): expect the reusable job to run without a label.
• grep -r scenario-test-reusable .github/ returns nothing.

[github-actions]

Thank you for contributing to the Autoware project!

🚧 If your pull request is in progress, switch it to draft mode.

Please ensure:

• You've checked our contribution guidelines.
• Your PR follows our pull request guidelines.
• All required CI checks pass before marking the PR ready for review.

[xmfcx]

@mitsudome-r I also updated the required workflow accordingly 👍

[mitsudome-r]

I can create a follow up PR to put back the scenario test workflow after merging.

[xmfcx]

What scenario-test.yaml does

Scheduled build-and-run of a scenario test against Autoware, independent of the docker-new pipeline. Triggers:

• schedule: cron 0 12 * * * (daily 12:00 UTC)
• push: branches: [main]
• workflow_dispatch

Runs on GHA-hosted ubuntu-24.04, inside the ghcr.io/autowarefoundation/autoware:universe-devel container. Steps:

1. apt-get install build deps; pip install --upgrade gdown vcs2l.
2. Fresh clone: git clone https://github.com/autowarefoundation/autoware.git ~/autoware_ws — ignores the checked-out ref, always tracks main tip.
3. vcs import src < repositories/simulator.repos to pull simulator packages.
4. rosdep install --from-paths src --ignore-src -r -y.
5. pip3 install --user xmlschema==3.4.5 (hard-pinned compat workaround).
6. colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release --executor sequential with CMAKE_DISABLE_PRECOMPILE_HEADERS=ON (memory).
7. gdown --id <FILE_ID> for a sample scenario yaml and sample map zip.
8. sed-rewrite /home/user/ → $HOME/ in the scenario yaml.
9. ros2 launch scenario_test_runner scenario_test_runner.launch.py ... with RMW_IMPLEMENTATION=rmw_cyclonedds_cpp, 300s initialize_duration, no rviz, 1 fps.
10. Parse ./results/scenario_test_runner/result.junit.xml — fail if <failure or <error tags present.
11. Upload ./results/, scenario_output.log, ~/.ros/log/.
12. pkill -9 ros2 / scenario_test_runner / openscenario_interpreter_node / python.

Actual health

Last 15 runs: every single one red. Latest failures (incl. the 2026-04-17 cron run at 12:00 UTC) all die at the same step:

gdown: error: unrecognized arguments: --id

Newer gdown versions (≥5.x) dropped --id; the file ID is now a positional arg. Since the workflow unconditionally pip install --upgrade gdown, the build has been broken since whenever the gdown release removed --id, and nobody has fixed it. The scenario never even launches — everything from step 9 onward is dead code in current CI.

Other latent issues

• Step 2 ignores the checked-out repo. Every run is against main tip via a fresh git clone, which means the workflow cannot meaningfully be tested from a feature branch — workflow_dispatch on a branch still builds main.
• xmlschema pin at 3.4.5 is a fragile compat hack with no comment explaining why.
• No job-level timeout-minutes — a hanging scenario_test_runner would eat the default 360 min.
• --executor sequential build is very slow; every run recompiles the whole universe tree from scratch (no cache).
• actions/checkout@v4 and actions/upload-artifact@v4 flagged for Node 20 deprecation (removal Sep 2026).
• pip install --user inside a container works here but is non-hermetic.
• No concurrency cancel for cron-triggered runs beyond the default group (group includes event_name + ref, so overlapping schedule + push-to-main can both run).

Bottom line

The workflow is architecturally a separate merge-time scenario gate from the monolithic health-check.yaml. It has been silently failing on gdown --id since the library drop, so the merge-time "scenario coverage" that still nominally exists is in fact not producing signal — red runs just get ignored. If this is to be reinstated as a real gate, at minimum: fix the gdown call, pin gdown to a working major version (or migrate to a non-Drive host), add timeout-minutes, and decide whether the workflow should test the ref under test or always main tip.

[xmfcx]

@mitsudome-r also it will work faster with the new images because cyclonedds and other dds optimizations are done properly in the new images 🐇 as long as you run through the /entrypoint.sh