Corepack is not pre-installed on runs-on: runners-privilegedescalation,
causing 'corepack: command not found' errors. Install it via
'npm install -g corepack' before using corepack commands.
Fixes PRI-51.
- Move rebuild step BEFORE checksum computation
- Add validation step after rebuild
- Remove redundant VERSION/PKG_NAME variable reassignments
- Checksum now computed from rebuilt tarball, not original
The tarball was being created BEFORE the checksum was computed and
updated in artifacthub-pkg.yml. This meant the released tarball
contained a placeholder checksum instead of the actual SHA256 hash.
This change adds a step to rebuild the tarball after the checksum
is computed, ensuring the released artifact has the correct checksum.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The fail_on_unmatched_files: true causes the release step to exit 1
when the glob pattern doesn't match (e.g., TARBALL env var resolution
timing). Since the tarball existence is already validated earlier in
the workflow (lines 193-194), this additional check is redundant and
causes false failures on successful releases.
Fixes: https://github.com/privilegedescalation/headlamp-kube-vip-plugin/issues/32
Co-authored-by: Hugh Hackman <hugh@privilegedescalation>
Co-authored-by: Paperclip <noreply@paperclip.ing>
If a release workflow fails after creating the branch (e.g. pnpm setup
failure, network error) but before creating the tag, re-triggering the
workflow previously failed at 'git push origin $BRANCH' because the
branch already existed.
Changes:
- Commit and tag: check for existing remote branch and delete it before
re-creating, so re-triggers are clean. Safe because check-tag skips
when the tag already exists — we only reach this point when the tag
does NOT exist yet.
- Create PR: guard with 'gh pr view' so a pre-existing PR from a failed
run is reused instead of causing 'pr already exists' failure.
Split the single 'git push origin $BRANCH --tags' into two pushes
(branch and tag separately) to avoid any flag ambiguity.
The release job used pnpm/action-setup@v5 without a version input,
which requires a packageManager field in package.json. Repos that
don't have this field fail at Setup pnpm, blocking all releases.
Mirror the resilient two-step pattern already used in plugin-ci.yaml:
- If packageManager is present: use Corepack (respects pinned version)
- If absent: fall back to pnpm/action-setup@v5 with version: latest
Fixes the systemic v1.0.0 release failures across kube-vip, sealed-secrets,
tns-csi, and rook (PRI-866).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
pnpm/action-setup@v4 errors with ERR_PNPM_BAD_PM_VERSION when both
`version` (in the workflow) and `packageManager` (in package.json) are
specified. Remove the hardcoded `version: latest` from plugin-release
so that repos can pin their pnpm version via the packageManager field
in package.json.
When packageManager is absent the action falls back to latest (same
prior behavior). When packageManager is set it is used exclusively,
which prevents silent version drift.
The plugin-ci.yaml change is handled separately in PR #54.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Mirrors the pnpm-detection logic from plugin-ci.yaml. When a repo has
pnpm-lock.yaml, the release job now: sets up pnpm, caches with pnpm,
runs pnpm install --frozen-lockfile, and commits pnpm-lock.yaml (not
package-lock.json) in the release branch.
Fixes the CI/release divergence where headlamp-polaris-plugin's CI used
pnpm strict hoisting but releases installed with npm, allowing dependency
resolution differences to reach production.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The multi-line --body string had cc @cpfarhood at column 0, which
terminated the YAML literal block scalar prematurely and caused
actionlint to reject the workflow file. Use printf to construct
the body string without embedding a literal newline in the YAML.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
All PRs must include cc @cpfarhood. The automated release PR
body generated by plugin-release.yaml was missing this.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Adds a check-secrets job that runs before any expensive work. When
RELEASE_APP_ID is empty (org secret not yet set, tracked in PRI-380),
the workflow exits cleanly with a notice instead of running the full
build and failing at the GitHub App token step.
Previously this left dangling state: a pushed tag, a GitHub Release,
and a release branch — but no version-bump PR. Now the workflow skips
all of that and exits clean.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix: skip duplicate release gracefully when tag already exists
Replace inline exit-1 tag check with a dedicated check-tag job that uses
the GitHub API. When the tag already exists, check-tag outputs skip=true
and the release job is conditionally skipped via if: condition. Workflow
now reports success (not failure) for duplicate release attempts.
Fixes#30 (partial) — resolves the tag-already-exists failure mode.
Co-Authored-By: Hugh Hackman <hugh@privilegedescalation.io>
* fix: use curl instead of gh CLI in check-tag job for portability
gh CLI may not be pre-installed on ARC runners. curl is always available
in container images. Avoids potential startup failure if gh binary is absent.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix: drop -f flag from curl in check-tag to avoid exit on 404
With -f, curl exits non-zero when the tag does not exist (404). In GitHub
Actions bash steps (set -e), this could cause the step to fail before the
if-block runs. Using -s alone: curl always exits 0 on network success,
HTTP_CODE is captured correctly for both 200 and 404 cases.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
---------
Co-authored-by: Hugh Hackman <hugh@privilegedescalation.io>
Co-authored-by: Paperclip <noreply@paperclip.ing>
The org blocks GITHUB_TOKEN from creating pull requests
("Write permissions for workflows are disabled by the organization").
Switch to a GitHub App installation token generated via
actions/create-github-app-token for the PR creation step.
Requires org-level secrets RELEASE_APP_ID and RELEASE_APP_PRIVATE_KEY
to be configured. Calling workflows must pass these secrets.
Closes#30
Co-authored-by: Hugh Hackman <hugh@privilegedescalation.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
ARC runner containers run as non-root, so `mv` to /usr/local/bin fails
with permission denied. Install to $HOME/.local/bin instead and add to
GITHUB_PATH.
Co-authored-by: Hugh Hackman [bot] <hugh-hackman[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
ARC runner scale set was recreated on 2026-03-19 with label
`runners-privilegedescalation` but all shared workflows still referenced
`local-ubuntu-latest`. This label mismatch caused startup_failure on
every Release workflow and queued CI jobs with no runner to pick them up.
Updates all 4 workflows and the actionlint config to match the current
ARC runner scale set label.
Closes#27
actions/checkout v6 was already adopted in headlamp-agent-skills.
This brings the org-level reusable workflows (plugin-ci, plugin-release,
ci-health-check) up to the same version. Affects all plugin repos that
call these shared workflows.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The apt-based gh CLI install requires sudo which is not available on our
self-hosted container runners. Replace with a direct binary download from
GitHub releases that works without elevated permissions.
Fixes the "gh: command not found" error in the release workflow's
"Create PR for version bump" step.
Co-authored-by: Hugh Hackman <hugh@privilegedescalation.com>
Co-authored-by: Paperclip <noreply@paperclip.ing>
The self-hosted runner (local-ubuntu-latest) does not have gh CLI
pre-installed, causing the PR creation step to fail with
"gh: command not found" after the release is published.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The release PR is just a version bump + checksum update. Enable
auto-merge with squash and delete the release branch after merge
to prevent branch accumulation.
The release workflow pushed directly to main which fails on repos
with branch protection enabled. This broke the polaris plugin v0.7.0
release.
Changes:
- Create release/vX.Y.Z branch instead of committing to main
- Push to the release branch + tags
- Create a PR to merge the version bump back to main
- Add pull-requests: write permission
Fail fast when a release tag already exists instead of running the
full build+package cycle only to fail at git push. Saves CI time on
duplicate workflow_dispatch triggers.
Paperclip
Hugh Hackman
Chris Farhood