feat(packaging): Add a busybox init-container installer image as a fourth distribution channel.

[jackluo923]

Description

Adds a fourth distribution channel alongside the .deb/.rpm/.tar.gz packages: a busybox init-container installer image that bundles both plugins and copies each into a mounted volume at pod init, so the stock presto-native images can be used unmodified (how the connector is consumed in CLP-OSS and CLP cloud deployments; y-scope/clp#2439 is the deployment counterpart).

Each plugin is selected by its own env var, since the coordinator JAR and worker .so install into different locations (set either or both):

docker run --rm -e WORKER_PLUGIN_INSTALL_PATH=/plugins -v "$(pwd)/plugins:/plugins" \
  ghcr.io/y-scope/clp-plugin-presto-connector:<version>

CI builds the image per architecture on every run and assembles a multi-arch :<version> tag, but pushes to GHCR only from the default branch and version tags. Local builds (task package) load the building machine's :<version>-<arch> tag. Details in tools/build-packages/README.md.

Validation performed

• Built via build-installer-init-image.sh --load from a locally built package tarball; a run with both COORDINATOR_PLUGIN_INSTALL_PATH and WORKER_PLUGIN_INSTALL_PATH set installed the JAR and the .so + lib/ into the right targets (file list matches the tarball exactly); a run with neither set exited with the usage error.
• Non-root run (--user "$(id -u):$(id -g)"): installs cleanly, files owned by the running user.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 2e99db94-4490-4ed7-a92e-851dcc4c46a3

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/init-container-installer

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[junhaoliao]

as debugged offline, there's one permission issue we need to fix

the rest lgtm

[junhaoliao]

shall we consider this -

the architecture tags are mutable shared names, so overlapping runs can interleave before this manifest resolves them. publish run-scoped staging tags, then promote only those references after both matrix legs succeed:

# image job
staging_version="${VERSION}-${GITHUB_RUN_ID}-${GITHUB_RUN_ATTEMPT}"
# pass --version "${staging_version}" and --push to the builder

# manifest job
source_tag="${tag_version}-${GITHUB_RUN_ID}-${GITHUB_RUN_ATTEMPT}"
docker buildx imagetools create --prefer-index=false \
  --tag "${image_repo}:${tag_version}-amd64" "${image_repo}:${source_tag}-amd64"
docker buildx imagetools create --prefer-index=false \
  --tag "${image_repo}:${tag_version}-arm64" "${image_repo}:${source_tag}-arm64"
docker buildx imagetools create --tag "${image_repo}:${tag_version}" \
  "${image_repo}:${source_tag}-amd64" "${image_repo}:${source_tag}-arm64"

[jackluo923]

Good catch — the race is real: the per-arch tags are mutable shared names, so two overlapping publish runs (e.g. a re-run of an older attempt, or a tag build racing main) could produce a manifest mixing images from different runs.

Rather than run-scoped staging tags, I went with referencing the images by digest: each image leg captures the pushed image's registry digest (buildx --metadata-file) and exposes it as a job output, and the manifest job does imagetools create --tag : @ @. Same guarantee — the manifest combines exactly the images this run built — but:

• digests are immutable, so there's no window at all (staging tags are still mutable names, just less likely to collide);
• no staging tags accumulating in the GHCR package (they'd need a cleanup step to avoid piling up per run);
• no extra pushes — the digest is a side effect of the push we already do.

The per-arch :- tags are still pushed for debugging convenience; they just no longer carry correctness. The final : tag stays mutable by design — that's the SNAPSHOT contract (each publish is supposed to move it); the fix only ensures each move is internally consistent.

[junhaoliao]

this replacement is lossy: valid versions 1.0+rc and 1.0~rc both become 1.0_rc. define one shared encoding and use it here and in the manifest job:

package_version_to_image_tag() {
    local version="$1"
    [[ "${version}" =~ ^[0-9][0-9A-Za-z.+~-]*$ ]] || return 1
    local tag_version="${version//+/_plus_}"
    tag_version="${tag_version//\~/_tilde_}"
    printf '%s\n' "${tag_version}"
}

tag_version="$(package_version_to_image_tag "${version}")" ||
    die "invalid package version: ${version}"

[jackluo923]

Connector version shouldn't contain "+" or "~". Mistake on my part. I will switch to fail loudly if these versions are encountered.

[junhaoliao]

made one modification to the docs directly