ci: re-enable riscv64 releases, don't let one arch block the manifest

[mauro-agent]

What

Reverts #545's disable of the riscv64 release build, and separately fixes the bug #545's own title named: one failed arch job skipped the final manifest job entirely, leaving the release tag completely unpublished on quay (v0.22.0 never got a manifest, not even for amd64/arm64).

Why revert now

Checked test-riscv64.yml's actual recent run history before reverting: zero riscv64-job failures across the last 20 PR CI runs on the same ubuntu-24.04-riscv runner (the 2 failures in that window were an unrelated build-ui/npm issue that skipped the riscv64 job before it even ran). Whatever made the runner unreliable back in June looks resolved, so this restores build-ui/build-linux-riscv64 unchanged rather than guessing at a different fix for a problem that isn't currently reproducing.

The actual fix

The build (manifest) job now runs regardless of riscv64's outcome, still requiring amd64/arm64 to succeed, and includes riscv64 in the published manifest only if it actually succeeded that run. A riscv64 flake degrades to a two-arch release instead of no release at all.

Also bumped the UI artifact's retention from 1 to 3 days: #545 noted a same-day retry couldn't recover because the artifact had already expired by the time anyone re-ran the failed job.

Test plan

• A real tag push exercises this end to end (can't fully simulate locally); recommend testing against a pre-release tag before the next real cut
• Confirm the manifest still publishes correctly if riscv64 is intentionally made to fail

[Copilot]

Pull request overview

Re-enables the riscv64 release image build and adjusts the release image workflow so a single-architecture failure (riscv64) no longer prevents publishing the multi-arch manifest for successful architectures (amd64/arm64).

Changes:

• Reintroduce build-ui and build-linux-riscv64 jobs for release builds.
• Make the manifest build job run even if riscv64 fails, while still requiring amd64/arm64 success.
• Conditionally include the riscv64 image in the manifest only when its build succeeded; increase UI artifact retention to 3 days.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 49.72%. Comparing base (c42c764) to head (2cc002b).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #758      +/-   ##
==========================================
+ Coverage   49.71%   49.72%   +0.01%     
==========================================
  Files          77       77              
  Lines        9733     9735       +2     
==========================================
+ Hits         4839     4841       +2     
  Misses       4337     4337              
  Partials      557      557              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mauro-agent]

Timing investigation, recorded before a session restart so it isn't lost.

The native ubuntu-24.04-riscv runner (test-riscv64.yml, same Dockerfile.riscv64) took 42 minutes total, 30 of those in the Docker image build step alone.

Ran the same build locally (16 CPUs / 58GB, docker buildx build --platform linux/riscv64, no cache, plain QEMU emulation, no platform pinning): 24m15s total. Even a modest emulated machine already beats the native runner. Step breakdown showed 77% of that time (18.8 of 24.25 min) in one step: go build, running under full QEMU system emulation because the builder stage isn't pinned to $BUILDPLATFORM.

Tried fixing that properly, pinning with-swagger/without-swagger/builder to --platform=$BUILDPLATFORM and using tonistiigi/xx (xx-go build, xx-apt-get) to cross-compile natively and only cross-link the one CGO dependency (libpcsclite, for go-piv/piv-go/v2 via sbctl). The swag codegen step alone dropped from 196s to 12.6s pinned, confirming the general approach is directionally right. But the actual go build step failed: xx-go didn't correctly enable CGO for the riscv64 target, so go-piv/piv-go and github.com/ThalesGroup/crypto11 fell back to their CGO-disabled stub code paths and hit undefined: pkcs11.Ctx, undefined: scTx, etc. Real toolchain work to fix properly (correct CC, actual cross-linking config), not attempted further this session.

Net result: the plain unpinned emulated build (24m15s) is the only approach actually proven to work end to end. The $BUILDPLATFORM + xx optimization is a real, promising lead (the swag-stage speedup is genuine evidence) but needs someone to actually debug the CGO cross-link failure before it's usable. Not blocking this PR either way, since #758's own fix is unrelated (the manifest-blocking bug, already merged in this branch) -- just recording the finding.

[mauro-agent]

Decision: ship the plain, fully-emulated build now. It already works end to end (this PR's own runs prove that). The $BUILDPLATFORM + tonistiigi/xx cross-compile speedup is a separate, real lead but not required to land this fix, and its CGO cross-link problem (see the timing-investigation comment above) needs real toolchain debugging. Picking that back up later, tracked separately.

Retriggered CI above: the failing e2e-tests run was an unrelated flake (unexpected EOF pulling quay.io/kairos/ubuntu:22.04-core-arm64-rpi4-v3.6.1-beta2 from quay.io), not caused by this change.