ci: teach create-distribution-package a staging-dir mode#75
Merged
Conversation
Two opt-in extension points to the generic Build & Release workflow,
both fully backward compatible (every existing plugin keeps its current
behaviour because the new fields are absent).
1. supported_platforms (manifest.json)
When a plugin's manifest declares an array like
"supported_platforms": ["linux-x86_64", "linux-arm64", ...]
matrix entries whose canonical platform is not listed are skipped
from build, package, upload and release. Useful for plugins that do
not (yet) support every host (e.g. Python-embedding plugins blocked
on Windows ARM, or ROS-aware plugins that only ship for Linux).
The platform identifier is canonical "<os>-<arch>" using the same
normalization release_tools.py already applies elsewhere
(PLATFORM_ARCH_MAP / PLATFORM_OS_MAP) — aarch64 -> arm64,
x64 -> x86_64.
2. <plugin>/release.sh override
When a plugin ships an executable release.sh, the Build & Test step
runs it instead of the default ./build.sh + ctest flow. The script
takes responsibility for build, tests, and producing the artifacts
the rest of the pipeline expects under build/<plugin>/Release/.
Used by plugins whose build pipeline diverges from the conan + cmake
default (e.g. multi-distribution Docker builds).
The bulk of the resolution logic moves into a new release_tools.py
subcommand, resolve-build-scope, replacing the inline Python and bash
that previously lived in the workflow's "Resolve build scope" step. The
workflow step is now a thin wrapper that pipes the script's key=value
output into $GITHUB_OUTPUT.
The default (heuristic) mode finds one plugin binary by its embedded manifest id and copies it alongside manifest.json. That works for single-artifact plugins but breaks down for plugins whose marketplace zip needs to ship more than one .so — e.g. data_stream_ros2 packages a distro-agnostic proxy plus one per-distro inner per supported ROS 2 distribution. Auto-selected by the presence of ``<build_dir>/dist/``: - Staging-dir mode: the contents of ``<build_dir>/dist/`` (assembled upstream, typically by a plugin-level release.sh) are copied as-is into ``<output_dir>/<extension_id>/``. ``manifest.json`` is added automatically if the staging tree omits it. - Heuristic mode (default, unchanged): existing behaviour — locate the binary by manifest id, copy it + manifest, bundle any sibling python3* directory dropped by the CMake POST_BUILD step. Backward compatible: every existing plugin keeps the heuristic flow because none of them produce a ``dist/`` subdirectory under their build directory today.
Base automatically changed from
feat/release-platform-filter-and-override
to
main
April 28, 2026 10:39
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
1 participant
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
Adds a second mode to
release_tools.py create-distribution-packageso plugins whose marketplace zip ships more than one binary can pre-assemble the tree they want and have the packaging step zip it as-is.Why
The current heuristic finds one
.soby its embedded manifest id and copies it alongsidemanifest.json. That works for single-artifact plugins, but breaks down fordata_stream_ros2, whose zip needs:.so(humble / iron / jazzy / rolling) underdist/<distro>/Mode selection
Auto-selected by the presence of
<build_dir>/dist/:<build_dir>/dist/manifest.json, bundle any siblingpython3*dir from the CMake POST_BUILD step.<build_dir>/dist/*into<output_dir>/<extension_id>/. Addmanifest.jsonif the staging tree omits it.Backward compatible: every existing plugin keeps the heuristic flow because none produces a
dist/subdirectory under its build directory today.Test plan
<build_dir>/dist/viarelease.shproduces a zip whose contents match the staging tree exactly.<build_dir>/dist/falls through to the heuristic path.Stack
This PR depends conceptually on #74 (
release.shoverride hook) — together they let a plugin own its build pipeline from end to end. Thedata_stream_ros2/release.shthat uses both lands in #66 once both are merged.Base branch:
feat/release-platform-filter-and-override. Once #74 merges tomain, retarget this PR tomain.