rpm: speed up cross-arch worker builds by installing deps into mounted target rootfs

[kartikjoshi21]

Enable faster and more reliable cross-arch RPM worker builds by installing build dependencies into a mounted target rootfs while running the package manager on the native BuildKit executor platform (avoids slow/full emulation and “exec format error” during install).

Changes

• Detect native executor platform from BuildKit worker opts and normalize platform tuples.
• For build != target:
  1. resolve target base image as target platform
  2. run install on build platform and install into mounted target rootfs via --installroot
  3. return the mutated rootfs as the target-platform worker
• Add optional --forcearch support (applied when supported by dnf/tdnf).
• Enable CacheAddPlatform for Rocky 8/9, Azure Linux 3, and Mariner 2 to avoid cross-arch cache/repo metadata collisions.

[Copilot]

Pull request overview

This PR optimizes cross-architecture RPM worker builds by installing build dependencies into a mounted target rootfs while running the package manager on the native BuildKit executor platform. This approach avoids slow QEMU emulation and "exec format error" issues during cross-architecture package installation.

Changes:

• Adds native executor platform detection from BuildKit worker options with platform normalization
• Implements cross-arch build flow: resolve target base image, run install on build platform with --installroot, and return mutated rootfs as target-platform worker
• Adds optional --forcearch support for dnf-based distros (applied when supported by dnf/tdnf)
• Enables CacheAddPlatform for Rocky 8/9, Azure Linux 3, and Mariner 2 to prevent cross-arch cache/repo metadata collisions
• Improves GitHub workflow reliability by simplifying registry mirror setup and adding error handling

Reviewed changes

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

Show a summary per file

File	Description
targets/linux/rpm/distro/worker.go	Adds platform detection, normalization, and cross-arch worker build logic with InstallIntoRoot support
targets/linux/rpm/distro/dnf_install.go	Implements DnfForceArch option and InstallIntoRoot function for cross-arch package installation
targets/linux/rpm/rockylinux/v8.go	Enables platform-specific cache keys for Rocky Linux 8
targets/linux/rpm/rockylinux/v9.go	Enables platform-specific cache keys for Rocky Linux 9
targets/linux/rpm/azlinux/azlinux3.go	Enables platform-specific cache keys for Azure Linux 3
targets/linux/rpm/azlinux/mariner2.go	Enables platform-specific cache keys for Mariner 2
.github/workflows/worker-images.yml	Simplifies registry mirror setup and adds error handling for gh release view command

[Copilot]

The shell variable interpolation in lines 169-170 could be vulnerable to injection attacks if forceArch or installRoot contain shell metacharacters. Consider sanitizing these values or using proper quoting. However, since these values come from trusted internal sources (rpmArchFromPlatform and rootfsPath constant), this is less critical but still a best practice concern.

Suggested change

	force_arch="` + forceArch + `"
	install_root="` + installRoot + `"
	force_arch=` + fmt.Sprintf("%q", forceArch) + `
	install_root=` + fmt.Sprintf("%q", installRoot) + `

[cpuguy83]

I think we've extended the distro Config too far here to accommodate tdnf's limitations. The shell script fallback chain in the tdnf path (detect --forcearch → try installing dnf via tdnf → fall back to chroot+qemu) is complex and hard to test. The ExtraCacheDirs field also only exists because we might switch package managers at runtime.
Instead, I'd like to see this refactored so that azlinux/mariner configs just include dnf in their BuilderPackages. That way:

• We get a single code path: dnf --forcearch --installroot works the same across all RPM distros
• The ExtraCacheDirs field goes away (no runtime package manager switching)
• The ~70 lines of tdnf-specific shell with runtime --forcearch detection, tdnf install dnf fallback, and chroot fallback all go away
• The supports_forcearch grep-on-help-text detection goes away
  More broadly, I think the cross-build logic would benefit from being a per-distro concern rather than living entirely in the centralized Config. Each distro knows its own setup requirements (e.g. azlinux needs dnf installed, rocky already has it). A Worker interface or per-distro setup hook would make this kind of customization cleaner than adding more fields to Config

[cpuguy83]

Can we make CacheDir a []string?

[kartikjoshi21]

Makes sense, i have tried to make it looks simpler using above suggestions please check, Thanks

[cpuguy83]

Much cleaner here, thanks for the update!

Some basic test results like I did for the deb changes:

amd64->arm64
pr - 5m9s
main - 6m20s

amd64->amd64
pr - 2m14s
main - 2m20s