Skip to content

ci: cover every released distro, add a blocking Resolute gate - #131

Open
nbbrooks wants to merge 1 commit into
mainfrom
nbbrooks/ci-distro-coverage
Open

ci: cover every released distro, add a blocking Resolute gate#131
nbbrooks wants to merge 1 commit into
mainfrom
nbbrooks/ci-distro-coverage

Conversation

@nbbrooks

@nbbrooks nbbrooks commented Aug 3, 2026

Copy link
Copy Markdown
Member

Why

This repo is released to all five distros — humble, jazzy, kilted, lyrical, rolling — but CI has only ever built rolling:

distro released had CI
humble 0.0.1-1 ❌ (own branch)
jazzy 0.0.1-3
kilted 0.0.1-3
lyrical 0.0.1-4
rolling 0.0.1-3

Three released distros with zero coverage — and the gap falls exactly where it hurts. lyrical is Ubuntu Resolute and released, and robotiq_controllers is currently failing on its buildfarm (#109, lyrical job). We had no job that could have caught it.

How

The four rolling binary/semi-binary workflows + the reusable-industrial-ci-with-cache.yml they called → one matrix, widened to jazzy/kilted/lyrical.

The tier structure is preserved exactly as-is. No tier added, none removed. rolling-source-build.yml keeps its own workflow (it uses action-ros-ci, not industrial_ci).

Job apt Base OS Blocking
jazzy-main main noble
kilted-main main noble
lyrical-main main resolute
rolling-main main resolute
jazzy-testing testing noble
kilted-testing testing noble
lyrical-testing testing resolute
rolling-testing testing resolute
rolling-main + upstream-source main resolute
rolling-testing + upstream-source testing resolute
  • lyrical-main is the new blocking Resolute gate — released distro, populated main apt (ros2_control 6.8.0).
  • rolling-main stays non-blocking, the state #129 established; Rolling's main apt still has no Resolute packages.
  • rolling-testing stays blocking — green today, and this repo's established Resolute signal. Not weakening it.

The nightly cron is kept

Worth being explicit, because I removed it in the picknik_controllers equivalent (#38) and the situations are opposite. There, every cron-triggered workflow had been silently auto-disabled by GitHub after 60 days of repo inactivity — taking PR coverage with it, since the disable applies to the whole workflow. Here the nightly runs are live and are currently the only working Resolute signal in either repo, so stripping them would be a regression.

The auto-disable risk is real but no longer silent: with these job names in the branch's required status checks, a disabled workflow makes PRs unmergeable rather than quietly unchecked. That's precisely what picknik_controllers lacked.

The semi-binary tier now means something

⚠️ ros2_robotiq_gripper.rolling.repos was byte-identical to ros2_robotiq_gripper-not-released.rolling.repos, so the semi-binary jobs were exact duplicates of the binary jobs and could not fail independently.

That happened for a structural reason: serial is unreleased and has no rosdep key, so it must be a source checkout in both tiers — and no released dependency was ever added to distinguish them.

Adds ros2_control from master. It is released, so the binary tier takes the deb while semi-binary builds the development branch. That difference is the entire point of the tier, and it's what would have caught LoanedCommandInterface::get_value() being removed — which instead surfaced as a buildfarm release failure.

Both semi-binary jobs therefore become non-blocking: they now track upstream's master and can go red on upstream's schedule rather than ours. They were only blocking before because the tier was inert.

ROS Lint pinned to lyrical

The newest distro whose build job is blocking. Moved into a ros:lyrical-ros-base container, because GitHub has no 26.04 runner and setup-ros cannot install lyrical on noble — the same mismatch that has kept ci-coverage-build.yml red since the Resolute transition.

Keeps this repo's existing --linelength=121 and its three-package scope (robotiq_driver, robotiq_controllers, robotiq_description).

Deliberately not in this PR

Both are real but independent of the distro-coverage gap:

  • ci-coverage-build.yml runs action-ros-ci on a noble runner outside a container and has failed since Rolling moved to Resolute. Its own comment proposes the fix (wrap in industrial_ci with OS_CODE_NAME: resolute).
  • The source tier has never actually run. reusable-ros-tooling-source-build.yml fetches its .repos with the deprecated ?token=${{ secrets.GITHUB_TOKEN }} URL syntax and gets an HTTP 404 every time. One-line fix — drop the token, this is a public repo. (Same bug in picknik_controllers.)

Both are documented in .github/workflows/README.md so they don't get lost.

Verification

  • pre-commit run --all-files --hook-stage manual — clean
  • All three ament linters inside ros:lyrical-ros-base against the three packages — pass, 33 files checked

Note that jazzy, kilted and lyrical have never built here, so this PR's own run is the first real signal for them. I'll report back on what it finds.

Follow-up

Once this lands, required status checks should go from today's ["Format"] to: Format, ament_copyright, ament_cpplint, ament_lint_cmake, jazzy-main, kilted-main, lyrical-main, rolling-testing — excluding the non-blocking jobs, since requiring a continue-on-error job defeats it.

Separately: rosdistro's source: entry for humble points at main in this repo, which cannot build on humble (no get_optional() in humble's hardware_interface). Stale metadata worth correcting.

This repo is released to humble, jazzy, kilted, lyrical and rolling, but CI has
only ever built rolling. jazzy, kilted and lyrical ship untested -- and lyrical
is the one that matters right now: it is Ubuntu Resolute *and* released, and
robotiq_controllers is currently failing on its buildfarm (#109).

Consolidates the four rolling binary/semi-binary workflows and the
reusable-industrial-ci-with-cache.yml they called into one matrix, then widens it
to jazzy, kilted and lyrical. The tier structure is preserved as-is: binary and
semi-binary, with `main` and `testing` apt variants. No tier is added or removed,
and the source tier keeps its own workflow.

lyrical-main is the new blocking Resolute gate -- released distro, populated
`main` apt (ros2_control 6.8.0). rolling-main stays non-blocking, the state #129
established, since Rolling's `main` apt has no Resolute packages yet.
rolling-testing stays blocking: it is green today and is this repo's established
Resolute signal.

The nightly cron is kept. Unlike picknik_controllers, where cron-triggered
workflows were silently auto-disabled after 60 days of inactivity and took PR
coverage with them, these nightly runs are live and are currently the only
working Resolute signal we have. That risk is no longer silent either: with these
job names in the required status checks, a disabled workflow makes PRs
unmergeable rather than quietly unchecked.

Makes the semi-binary tier mean something. ros2_robotiq_gripper.rolling.repos was
byte-identical to ros2_robotiq_gripper-not-released.rolling.repos, so the
semi-binary jobs were exact duplicates of the binary jobs and could not fail
independently. That happened because `serial` is unreleased and so must appear in
both, and no *released* dependency was ever added. Adds ros2_control from master:
released, so binary takes the deb while semi-binary builds the development
branch. That is the tier that would have caught
LoanedCommandInterface::get_value() being removed, rather than it surfacing as a
buildfarm release failure.

Both semi-binary jobs therefore become non-blocking -- they can now go red on
upstream's schedule rather than ours.

ROS Lint moves to lyrical, the newest distro whose build job is blocking, and
into a ros:lyrical-ros-base container since GitHub has no 26.04 runner and
setup-ros cannot install lyrical on noble. Keeps this repo's existing
--linelength=121 and its three-package scope.

Verified before pushing: pre-commit clean, and all three ament linters pass
inside ros:lyrical-ros-base against those three packages (33 files).

ci-coverage-build.yml and the source tier's `?token=` 404 are both left alone
here; they are tracked in .github/workflows/README.md as separate fixes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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