feat: replace legacy rechunker with rpm-ostree compose build-chunked-oci

[dylanmtaylor]

Replaces hhd-dev/legacy-rechunk with rpm-ostree's built-in compose build-chunked-oci.

Includes the rechunker-group-fix one-shot systemd unit so users rebasing from legacy rechunker images do not lose /etc/gshadow consistency. Mirrors PR #4633.

The SBOM/changelogs portion of the original split landed via #4635 and is no longer in scope here.

Port of ublue-os/aurora#1476.

Closes #4510
Closes #3917

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[Copilot]

Pull request overview

This PR migrates Bluefin’s image “rechunking” flow away from legacy-rechunk and onto rpm-ostree’s native compose build-chunked-oci, and introduces a systemd-based migration safeguard intended to prevent /etc/group//etc/gshadow breakage when rebasing from legacy rechunked images.

Changes:

• Replace the legacy rechunker-based Justfile pipeline with an rpm-ostree compose build-chunked-oci-based pipeline.
• Add rechunker-group-fix script + systemd unit and enable it in the base image to mitigate legacy nss-altfiles migration issues.
• Update CI workflow to run the new rechunk step and (for PRs) export an OCI archive artifact for testing.

Reviewed changes

Copilot reviewed 4 out of 6 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
system_files/shared/usr/lib/systemd/system/rechunker-group-fix.service	Adds a boot-time oneshot service to reset/regenerate group shadow data during migration.
system_files/shared/usr/bin/rechunker-group-fix	Adds helper script to repopulate /etc/gshadow entries based on /etc/group.
Justfile	Replaces legacy rechunker steps with rpm-ostree chunked-OCI compose and adds helper targets for rootful loading / OCI export.
build_files/base/17-cleanup.sh	Enables the new rechunker-group-fix.service in the built image.
.gitignore	Stops ignoring legacy _build outputs and ignores generated .oci archives.
.github/workflows/reusable-build.yml	Updates CI to use the new rechunk step and upload OCI archives for PR testing; adds podman workaround for annotation pushing.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[renner0e]

This is mostly fine, you are just missing every improvement we've made after the first initial PR that introduced the rpm-ostree rechunker

You still need to rewrite your changelogs script to use the contents of the SBOM instead of the label set by the hdd rechunker

[castrojo]

I can handle the SBOMs/Changelogs, I've been working on it on other variants. I can work on that on a follow on PR.

[dylanmtaylor]

I can handle the SBOMs/Changelogs, I've been working on it on other variants. I can work on that on a follow on PR.

I pulled a lot of that work into this PR.

[bsherman]

I've been look at this closer. I'm really wondering if this is the right time to make the change. Is compose build-chunked-oci the way to go when coreos/chunkah is starting to get into good shape and is almost certainly going to be the next step?

[renner0e]

I've been look at this closer. I'm really wondering if this is the right time to make the change. Is compose build-chunked-oci the way to go when coreos/chunkah is starting to get into good shape and is almost certainly going to be the next step?

I think it does make sense as we currently rely on the HDD rechunker to generate our changelogs and this also introduces the workaround needed to get rid of the HDD rechunker, see the service unit.

(Although I would've preferred to split this up into multiple PRs despite bazzite and Aurora having already figured those things out and the changes being less experimental and more tested now.)

This is a preparation to use other solutions like chunkah in the future if it makes sense.

[bsherman]

Looks like the latest changes will fail SBOM generation. Going to throw copilot at this again.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 9 changed files in this pull request and generated 5 comments.

Comments suppressed due to low confidence (1)

.github/workflows/reusable-build.yml:346

• The SBOM being attached is named sbom.json and generated via just gen-sbom, which currently outputs Syft JSON (syft-json), but this workflow labels and discovers it as SPDX (application/vnd.spdx+json). This mismatch will break downstream consumers (e.g., changelog generation via ORAS discovery) and misrepresents the artifact content. Align the SBOM output format and the ORAS --artifact-type/discover filter (either generate SPDX JSON or change the artifact type + consumer parsing to Syft JSON).

          SBOM="sbom_out/${IMAGE_NAME}/sbom.json"
          
          cd "$(dirname "${SBOM}")"
          oras attach \
            --artifact-type application/vnd.spdx+json \
            --annotation filename=$(basename "$SBOM") \
            "${IMAGE}@${DIGEST}" \
            "$(basename ${SBOM})"

          sbom_digest=$(oras discover --format json "${IMAGE}@${DIGEST}" | jq -r '.referrers[] | select(.artifactType == "application/vnd.spdx+json") | .digest')

[bsherman]

@dylanmtaylor A few general suggestions.

First, it's a LOT easier to get confidence on changes and code reviews for smaller chunks of changes. So I'd strongly suggest figuring out if anything can be done in stages. If not possible, my second comment becomes invaluable.

Second, for any change, if it's not covered by tests or able to be validated in a PR build, it's highly valuable to clone/fork and run a build in a distinct location which can fully exercise the workflow. The bigger the change, the more important that becomes. Also, it's a general problem with any changes to workflow steps which only happen on release or "main" builds, like those here for changelogs, rechunk, etc.

[dylanmtaylor]

@dylanmtaylor A few general suggestions.

First, it's a LOT easier to get confidence on changes and code reviews for smaller chunks of changes. So I'd strongly suggest figuring out if anything can be done in stages. If not possible, my second comment becomes invaluable.

Second, for any change, if it's not covered by tests or able to be validated in a PR build, it's highly valuable to clone/fork and run a build in a distinct location which can fully exercise the workflow. The bigger the change, the more important that becomes. Also, it's a general problem with any changes to workflow steps which only happen on release or "main" builds, like those here for changelogs, rechunk, etc.

Some good recommendations here. I'll try to think about logically splitting this up.

[hanthor]

🤖 AI-Assisted Pull Request Review

Really nice work porting native compose build-chunked-oci rechunking and handling the NSS altfiles/gshadow migration workaround! This is a solid foundation.

Critical SBOM Format Mismatch Bug:
I noticed a mismatch in the reusable-build.yml workflow and the Justfile:
The workflow attaches sbom.json under the artifact type application/vnd.spdx+json using ORAS:

oras attach \
  --artifact-type application/vnd.spdx+json \
  --annotation filename=$(basename "$SBOM") \
  "${IMAGE}@${DIGEST}" \
  "$(basename ${SBOM})"

However, the command just gen-sbom in the codebase actually generates Syft JSON format (syft-json), which is not valid SPDX JSON. Downstream consumers (such as the release changelog generators or other tools searching for SPDX referrers) will fail when attempting to parse this file as an SPDX document.

Recommendation:
To resolve this, please update the gen-sbom recipe in the Justfile to output SPDX JSON format (e.g. syft ... -o spdx-json if using syft), or adjust the ORAS attachment and consumer logic to align on Syft JSON format.

[castrojo]

Closing old feature PRs here since the images on projectbluefin/bluefin are already ahead. We'll keep updating and fixing issues here until then, thanks!