A forced rebuild on the same day, of the same upstream version, produces a tag
that is already published, and the release API answers 409 Conflict. The build
itself had succeeded and passed all its checks; only publishing failed, so the
run reported failure after doing all the work.
The tag now gets the run number appended when one with that name is already
there. Overwriting was the alternative and is worse: someone may already have
downloaded the artifact behind that tag.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
publish-release.sh gained make print-var calls, which need the repository root,
but its dist argument is relative to wherever the caller stood. The path is now
made absolute first and the cd happens after, so the script works both from the
workflow (which already cds) and by hand.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Proxmox VE 9.2 made arm64 official — same code base, repositories and release
lifecycle as x86-64 — and the pve-no-subscription repository carries proxmox-ve,
pve-manager, proxmox-default-kernel and pve-qemu-kvm for it. The build was still
hard-wired to amd64 in four places, which is now fixed:
* firmware is chosen from the target architecture (AAVMF for arm64, OVMF for
amd64) and padded to 64 MiB as QEMU's arm64 virt machine requires. Upstream
packer-maas keys this on the host architecture, which only works when host
and target match.
* host_is_arm is derived from uname rather than hard-coded false, so KVM is
used exactly when host and target architectures agree
* the release body builds its MAAS upload command from MAAS_ARCH, PVE_VERSION
and IMAGE_NAME instead of repeating amd64
* install-deps.sh installs qemu-system-arm and AAVMF under WITH_ARM64=1,
off by default since they are useless on an amd64-only builder
verify-image.sh asserted no kernel matching *-amd64, which would have passed
silently on an arm64 image carrying a Debian arm64 kernel. It now rejects any
/boot/vmlinuz-* not ending in -pve, which holds for both architectures. Checking
that with synthetic file lists caught a first attempt that returned "pass" for an
image containing both a PVE and a Debian kernel, so the expression is now a single
pipeline verified against GNU grep on the build host — the macOS grep this was
first tried on disagrees, and only the Linux behaviour matters here.
No arm64 image has been built and none deployed. The README gains an arm64
section saying so plainly, listing the two real obstacles — TCG emulation on an
x86_64 builder, and having no arm64 hardware to deploy to — and the entry stays
under "Not verified".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The build condition only compared pve-manager, which left two gaps. Kernel
security fixes ship in proxmox-default-kernel and do not bump pve-manager, so the
updates that matter most would not have triggered a rebuild. Debian base security
updates bump neither, so an image could have sat unchanged indefinitely while its
openssl and glibc went stale.
scripts/ci/decide-build.sh now rebuilds when pve-manager changes, when
proxmox-default-kernel changes, or when the newest release passes MAX_AGE_DAYS
(30). It compares against image-info.txt from the last release rather than
inferring from tag names, so the comparison reflects what is actually inside the
published image, and it can be run by hand to see the decision without triggering
anything.
The daily schedule stays. Measured from the trixie repository, Proxmox publishes
about weekly — 56 pve-manager and 28 proxmox-kernel versions since 9.0 — so daily
checking costs about 30 seconds on the days nothing changed and cuts worst-case
staleness from a week to a day. Tags carry the date now (pve-<version>-<date>)
because an age-triggered rebuild can repeat a version.
The README gains a "Prebuilt images" section linking the releases page, with the
checksum and MAAS upload commands, and a "Release automation" section explaining
the trigger table and stating plainly that the host-mode runner gives root on the
build machine to anything that can dispatch a workflow.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Builds the image on a self-hosted runner and publishes it, with the checksum and
a corresponding-source offer, as a Gitea release.
The schedule is daily but the build is conditional. Proxmox does not ship daily,
so an unconditional daily build would produce roughly 45 GB a month of
near-identical artifacts; instead the job compares the newest pve-manager in the
configured repository against the last published release and stops early when
they match. A manual trigger with `force` rebuilds anyway. Releases are tagged
after the version they contain (`pve-9.2.11`) rather than the date, so the tag
says something useful, and older ones are pruned to keep three.
The logic lives in scripts/ci/ rather than inline in the workflow. Shell inside a
YAML block scalar cannot carry an indented heredoc terminator, and the release
body needs several; scripts also mean the pieces can be run and tested by hand.
A `print-var` target exposes single Makefile variables to them.
Two constraints shaped this:
* The runner is registered in host mode, so steps run directly on the build
machine as root. The build needs /dev/kvm, qemu-nbd, FUSE and root, which a
container would have to be given anyway. The consequence — anything able to
dispatch a workflow gets root on that machine — is stated in the workflow
header rather than left implicit.
* Checkout is a plain git clone. actions/checkout is a JavaScript action and
the host-mode runner has no Node.js runtime.
The artifact is named maas-image-pve-<version>-amd64.tar.gz, not
proxmox-ve-*.tar.gz, and the release body says the build is unofficial and
unaffiliated. Proxmox permits redistribution under the AGPLv3 but asks that the
trademark not be used in product names.
SOURCES.md is generated per release: the image is an unmodified installation of
Debian and Proxmox packages, so it points at those archives for the
corresponding source, and records that the firmware licence texts ship inside the
image at /usr/share/doc/pve-firmware/licenses/ and must not be stripped.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
