[Feat] Publish test images for pull requests

[roomote-community]

Opened on behalf of Matt Rubens. Follow up by mentioning @roomote, in the web UI, or in Discord.

What changed

• Added a maintainer-triggered /publish-images workflow for open pull requests, including fork PRs.
• Reuses amd64 app and worker artifacts from the exact successful CI run for the current PR head and base instead of rebuilding them.
• Falls back to an unprivileged, merge-SHA-pinned rebuild only when the short-lived CI artifacts are unavailable.
• Publishes full head/base SHA tags plus a current pr-<number> alias, then posts the exact image references back to the pull request.
• Keeps PR-controlled builds separate from the package-write publisher and verifies worker fallback metadata before reusing the immutable base image.

Why this change was made

Contributors need deployable images to test pull request changes end to end before merge, without paying for the same Docker build twice. The split build/publish design supports fork PRs without exposing a package-write token to PR-controlled code.

Impact

Maintainers can request disposable GHCR preview images directly from a pull request discussion. Fresh CI output is published without another build; older PRs remain usable through the safe fallback. Structural workflow tests and the repository pre-push suite pass.

Linked work items

Follow-up to #964.

[roomote-community]

No new code issues found. See task

• .github/workflows/CI.yml:359-367,429-437 The publisher rejects expired artifacts, but CI retains them for only one day. Any still-open PR that has not pushed for 24 hours can no longer use /publish-images; retain these artifacts for the intended preview window or rebuild them when the command is invoked.

_{Reviewed aeed924}

[mrubens]

@tomny-dev does this seem reasonable to you per #964 (comment) ?

[tomny-dev]

@roomote-roomote should we just append the publish step to an existing workflow (gated with pr branch check)? otherwise we are building the same image again multiple times.

[tomny-dev]

@roomote should we just append the publish step to an existing workflow (gated with pr branch check)? otherwise we are building the same image again multiple times.

[roomote-community]

I'm on it. I routed this request into the existing PR task so follow-up work stays on one Roomote thread for this PR, and I'll keep updates here. See task

[roomote-community]

Updated in aeed924. CI now exports publishable amd64 image artifacts, and /publish-images reuses the exact successful head/base run instead of rebuilding. The package-write step remains separate for fork safety; if CI artifacts have expired, an unprivileged merge-SHA-pinned fallback rebuild keeps older PRs usable. Full-SHA immutable tags and head/base checks prevent stale alias updates. Workflow tests and pre-push checks pass. See task

[tomny-dev]

@roomote shouldnt we remove the new workflow now that you editing the existing workflow?

[roomote-community]

I'm on it. I routed this request into the existing PR task so follow-up work stays on one Roomote thread for this PR, and I'll keep updates here. See task

[roomote-community]

Not quite. CI.yml runs on pull_request, where fork PRs receive a read-only token and cannot push to GHCR. The /publish-images comment also arrives after that CI run has finished. CI now only builds and exports the reusable artifacts; publish-pr-images.yml is the trusted maintainer-triggered run that receives packages: write and publishes them. We could colocate both event paths in one YAML file, but they would still be separate runs with separate permissions, and keeping the publisher separate makes that security boundary clearer. No code change needed for this follow-up.