Two install-time failures on PVE 8.4.x nodes:
1. 'patch' utility not in Depends — causes silent patch failure on fresh
nodes; all three PVE file patches silently skip, plugin appears to
install but storage operations fail. Added 'patch' to control.j2.
2. ZFSPlugin.pm routing not applied on PVE 8.4.x — tabs→spaces reformat
and get_base($scfg) signature change in 8.4 broke hunks #3 and #4
(the freenas elsif routing branches). Nodes with a prior partial
install are doubly affected: grep idempotency check passes on partial
freenas strings, so the routing is never applied, causing:
"freenas: unknown iscsi provider" on clone/migrate operations.
New ZFSPlugin-8.4.14_1.pm.patch generated against stock PVE 8.4.19,
bundled as patches/ZFSPlugin/8.4.patch alongside existing 8.patch.
Verified clean on pve01-hq (8.4.19) and pve02-hq (8.4.14).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Users on unsupported PVE versions now get clear guidance at every
layer — README, install time, and GitHub release notes — rather than
silently failing or getting confusing patch errors.
- README: replace bare compatibility table with a full matrix and
prominent callout blocks for PVE 7 (last v2.x), PVE 8 (EOL
2026-08-31), PVE 9+ (use v3.0), and PVE ≤6 (unsupported)
- postinst: add check_pve_version() that exits on PVE < 7, warns
loudly on PVE 7 (stay on v2.x, do not upgrade to v3.0), notes
the PVE 8 EOL date, and warns on PVE 9+ (v2.x not supported)
- build.yml release template: add a version compatibility table so
every GitHub release prominently states who should and should not
install it
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
PVE 8.4 reformatted pvemanagerlib.js (tabs→spaces, structural changes),
making the existing 8.0.5-era patch fail on all 8.4.x nodes.
- Add pvemanagerlib-8.4.14_1.js.patch covering PVE 8.4.x (all hunks
verified on 8.4.14 and 8.4.19)
- Update postinst to detect pve-manager major.minor (e.g. "8.4") and
try a minor-version-specific patch before falling back to the major
patch — 8.3.x nodes keep using 8.patch, 8.4.x nodes use 8.4.patch
- Update build.yml to bundle 8.4.patch alongside the existing 8.patch
Tested live on pve01-hq (8.4.19) and pve03-hq (8.3.2) — correct patch
selected in each case, pvemanagerlib patched successfully on 8.4.19.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
GitHub is removing Node.js 20 from Actions runners on Sep 16, 2026
and forcing Node 24 as default from Jun 2, 2026. Upgrade all
first-party actions to latest major versions that ship with node24:
actions/checkout@v4 → v6
actions/upload-artifact@v4 → v7
actions/download-artifact@v4 → v8
Note: setup-python@v5 warning is inside cloudsmith-io/action@master
and is not directly addressable here.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
our \$VERSION = '2.3.0' is now the single source of truth for the release
series. The build.yml extracts it with a perl one-liner (no module load,
no stubs needed) and uses it as BASE_VERSION for alpha/beta channel builds.
Git tags remain the release trigger: pushing an exact vX.Y.Z tag publishes
to the stable Cloudsmith channel. A mismatch warning fires if the tag
version and \$VERSION disagree, catching forgotten version bumps.
The v2.3.0-pre anchor tag approach is superseded by this; the anchor tag
can stay in history as a breadcrumb but \$VERSION is now what drives builds.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Two changes:
1. BASE_VERSION now strips pre-release suffixes from the nearest ancestor tag
(e.g. v2.3.0-pre → 2.3.0), so anchor tags like v2.3.0-pre make feature
branch builds say 2.3.0-alpha+<sha> without "pre" leaking into the version.
2. Stable release detection changed from glob (refs/tags/v*) to an exact
semver regex (^refs/tags/v[0-9]+\.[0-9]+\.[0-9]+$). Tags with a suffix
(v2.3.0-pre, v2.3.0-rc1) build and validate but do not publish to Cloudsmith
stable — they fall through to the 'none' channel.
This lets us place a v2.3.0-pre anchor tag to version the development series
correctly, then later push v2.3.0 as the actual stable release.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
perl -c requires all modules to be loadable at compile time. PVE::SafeSyslog
only exists on Proxmox VE hosts, so the syntax check always failed on
GitHub Actions runners. Fix:
- Install real Perl deps via apt (libwww-perl, libio-socket-ssl-perl,
librest-client-perl, libjson-perl)
- Create a minimal stub for PVE::SafeSyslog so perl -c can load FreeNAS.pm
- Pass -I/tmp/pve-stub to perl -c so the stub is found
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Unquoted YAML plain scalars cannot contain ': ' (colon-space) because
the parser interprets it as a nested key-value mapping. The two step
names 'Dry-run patch: ZFSPlugin (PVE 8)' and 'Dry-run patch: apidoc.js
(PVE 8)' triggered this, causing GitHub Actions to reject the workflow
file before any jobs ran.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Two bugs that prevented any jobs from running:
1. action.yml contained only YAML comments (no 'on:' or 'jobs:' keys),
making it an invalid workflow file. GitHub rejected it at parse time.
Fixed by giving it a minimal valid structure with workflow_dispatch
trigger only, so it never fires automatically.
2. build.yml perlcritic step referenced perl5/PVE/Storage/Custom/FreeNAS.pm
which is not committed to the repository, causing a step failure.
Removed — only FreeNAS.pm (LunCmd) is linted for now.
3. build.yml publish job used 'if: |' block scalar for a multi-line
expression, which GitHub Actions rejects in expression position.
Changed to a single inline expression string.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Kevin Adams
Kevin Scott Adams