The workflow changes should be handled separately by Hugh Hackman
per PRI-215. This PR should only contain deployment manifests and
scripts, not CI workflow modifications.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The Headlamp project moved to the kubernetes-sigs org. The old Helm chart
repository URL (headlamp-k8s.github.io) returns 404, causing E2E workflow
failure at the `helm repo add` step.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The self-hosted runner doesn't have kubectl or helm pre-installed.
Add setup steps using azure/setup-kubectl and azure/setup-helm
actions, and add the Headlamp helm repo before the upgrade step.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The deploy script assumed the PVC was mounted on the CI runner at
/mnt/headlamp-plugins, but the runner pod doesn't have that mount.
Fix by using a temporary pod (kubectl run) that mounts the PVC,
receives the plugin tarball via stdin, and extracts it.
Also adds missing workflow steps to create the PVC and upgrade
Headlamp with the shared volume helm values before deploying.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Simplify deploy step to call scripts/deploy-plugin-via-volume.sh
directly instead of duplicating copy logic. Align env var names
(PLUGIN_VOLUME_PATH, HEADLAMP_DEPLOY) with the deploy script's
expected interface from PR #59.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Replace the old preflight-only approach with a build-and-deploy flow
that uses a shared volume (hostPath) between the CI runner and the
Headlamp pod. The workflow now builds the plugin from source, copies
the artifact to a shared volume path, and optionally calls Gandalf's
deploy script for Headlamp rollout coordination.
Removes kubectl exec/cp references and version-match preflight in
favor of deploying the PR's actual build artifact.
Refs: PRI-216, PRI-195
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Polaris is already installed on the CI cluster. The E2E workflow
was failing because the runner SA lacks RBAC to deploy to the
polaris namespace. Remove Setup Helm, Setup kubectl, Deploy Polaris,
Apply RBAC, and Wait for readiness steps.
Resolves: PRI-28, PRI-109
Co-authored-by: Null Pointer Nancy <nancy@privilegedescalation.dev>
Adds Helm-based Polaris dashboard deployment step to E2E workflow, fixing the long-standing E2E failure where Polaris was not accessible in the CI cluster.
Enhances the preflight step to:
- Check the deployed plugin version against the repo version
- Emit a clear warning annotation when there's a mismatch
- Report the plugin name from artifacthub metadata
- Still runs tests (warning, not error) so we catch other issues
This makes plugin version mismatches immediately visible in the
CI summary instead of requiring investigators to dig through
14 timeout failures.
Co-authored-by: hugh-hackman[bot] <hugh-hackman[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Adds a diagnostic step before E2E tests that:
- Logs the expected plugin version from package.json
- Verifies Headlamp is reachable (fails fast if not)
- Attempts to list installed plugins for debugging
This surfaces version mismatches and connectivity issues immediately
instead of requiring analysis of cryptic test timeout failures.
Co-authored-by: gandalf-the-greybeard[bot] <gandalf-the-greybeard[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Configures the reusable release workflow to fetch the latest release
tag from FairwindsOps/polaris and set appVersion in artifacthub-pkg.yml.
This keeps our Artifact Hub listing in sync with the upstream project.
Co-authored-by: Hugh Hackman <hugh@privilegedescalation.dev>
Enable manual triggering of the CI workflow via GitHub Actions UI.
The release workflow already supports workflow_dispatch.
Co-authored-by: hugh-hackman[bot] <hugh-hackman[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
The CI and release workflows use Node 22, but E2E was still on Node 20.
This aligns all workflows to the same Node version for consistency.
Co-authored-by: gandalf-the-greybeard[bot] <gandalf-the-greybeard[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
gh CLI is not installed on the self-hosted runner. Switch to
softprops/action-gh-release@v2 which was used before the
standardization broke it.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Remove broken mv logic and use gh CLI for release creation,
matching the proven workflow from other headlamp plugins.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The headlamp-plugin package command already produces a tarball named
{pkg}-{version}.tar.gz, so the mv command fails when source and
destination are the same file.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Merged prepare-release and release workflows into a single workflow
that handles everything in one job. This eliminates the need for
separate tokens or manual intervention.
Single workflow now:
- Validates version format
- Updates package.json and artifacthub-pkg.yml
- Builds and packages plugin
- Computes checksum
- Updates metadata with real checksum
- Commits all changes to main
- Creates and pushes tag
- Creates GitHub release with tarball
No more tag push triggers, no separate tokens needed.
Everything runs in one workflow_dispatch job.
Generated with [Claude Code](https://claude.ai/code)
via [Happy](https://happy.engineering)
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Happy <yesreply@happy.engineering>
The prepare-release workflow now uses GH_APP_TOKEN instead of
GITHUB_TOKEN to push commits and tags. This allows the tag push
to automatically trigger the release workflow without manual
intervention.
GITHUB_TOKEN cannot trigger other workflows due to GitHub's
security policy to prevent infinite workflow loops.
Added documentation in .github/GH_APP_TOKEN.md explaining the
token setup and requirements.
Generated with [Claude Code](https://claude.ai/code)
via [Happy](https://happy.engineering)
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Happy <yesreply@happy.engineering>
Replace complex draft/publish release workflow with clean two-workflow approach:
1. prepare-release.yaml (manual workflow_dispatch)
- Validates version format
- Updates package.json and artifacthub-pkg.yml
- Commits to main
- Creates and pushes tag
- Triggers release workflow automatically
2. release.yaml (automatic on tag push)
- Single build-and-release job
- Creates GitHub release with tarball in one step (no draft/publish)
- Separate update-metadata job runs after release
- Updates checksum on main branch
Benefits:
- No manual tarball upload required
- No tag force-push anti-pattern
- No draft/publish asset attachment failures
- Clear separation of concerns
- Self-documenting workflow
Eliminates:
- Guard logic for infinite loop prevention
- Post-release tag manipulation
- Manual intervention after workflow "succeeds"
- Checksum chicken-and-egg problem
Generated with [Claude Code](https://claude.ai/code)
via [Happy](https://happy.engineering)
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Happy <yesreply@happy.engineering>
- Changed ci.yaml from ubuntu-latest to local-ubuntu-latest
- Changed release.yaml from ubuntu-latest to local-ubuntu-latest
- e2e.yaml already using k3s-animaniacs (correct)
This ensures all CI jobs run on on-prem runners instead of GitHub-hosted runners.
Generated with [Claude Code](https://claude.ai/code)
via [Happy](https://happy.engineering)
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Happy <yesreply@happy.engineering>
GitHub's immutable releases feature locks releases upon publication,
preventing asset uploads. This fix uses a two-step process:
1. Create draft release (mutable) and upload tarball
2. Publish release after assets are attached
Also adds validation to ensure tarball name matches package.json,
preventing future naming mismatch issues.
Changes:
- Upgrade from softprops/action-gh-release@v1 to @v2
- Create release as draft initially (draft: true)
- Add separate publish step after asset upload
- Add tarball name validation step
Fixes release workflow failures that occurred with v0.3.6 and v0.3.7.
Generated with [Claude Code](https://claude.ai/code)
via [Happy](https://happy.engineering)
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Happy <yesreply@happy.engineering>
Switch E2E tests from GitHub-hosted runners to self-hosted k3s-animaniacs
runners which have network access to headlamp.animaniacs.farh.net.
Changes:
- runs-on: k3s-animaniacs (from ubuntu-latest)
- Re-enable E2E on push/PR events
- Uses ARC (Actions Runner Controller) self-hosted runners
Resolves DNS resolution failures (ERR_NAME_NOT_RESOLVED) by using
runners in the same network as the Headlamp test instance.
Runner config: kubernetes/base/arc-runners/helmrelease-arc-runner-set.yaml
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Happy <yesreply@happy.engineering>
Remove Gitea workflows and consolidate to GitHub Actions as the single
CI/CD platform. GitHub is now the sole source of truth for the project.
Changes:
- Remove .gitea/workflows/ directory entirely
- ai-review.yaml (Gitea-specific, not migrating)
- e2e.yaml (replaced by .github/workflows/e2e.yaml)
- release.yaml (already exists at .github/workflows/release.yaml)
- Migrate .gitea/workflows/ci.yaml → .github/workflows/ci.yaml
- Add unit tests to CI workflow
- Use Node.js 20 with npm caching
- Add 10-minute timeout
GitHub Actions Workflows:
- ci.yaml: Lint, type-check, format-check, build, test
- e2e.yaml: End-to-end Playwright tests
- release.yaml: Build tarball, create GitHub release, update ArtifactHub metadata
Repository Setup:
- Single remote: https://github.com/cpfarhood/headlamp-polaris-plugin
- All development, CI/CD, and releases happen on GitHub
- ArtifactHub pulls releases from GitHub every 30 minutes
Generated with [Claude Code](https://claude.ai/code)
via [Happy](https://happy.engineering)
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Happy <yesreply@happy.engineering>
Add comprehensive Playwright E2E testing documentation and additional
test coverage for app bar badge and plugin settings functionality.
Changes:
- Add GitHub Actions workflow for E2E tests (.github/workflows/e2e.yaml)
- Create .env.example for local test configuration
- Update .gitignore to exclude .env files
- Enhance e2e/README.md with:
- Detailed test coverage documentation
- Cluster requirements and prerequisites
- Debugging guides and troubleshooting tips
- CI/CD integration instructions for GitHub Actions
- Best practices and examples for writing new tests
- Add e2e/settings.spec.ts:
- Test plugin settings page visibility
- Test refresh interval configuration
- Test dashboard URL configuration
- Test connection test button
- Add e2e/appbar.spec.ts:
- Test badge displays cluster score
- Test badge navigation to overview
- Test badge color reflects score level
- Test badge updates across clusters
Test Results (v0.3.4):
- 5/16 tests passing (sidebar, namespaces, drawer functionality)
- 11/16 failing due to missing v0.3.4 features (settings, app bar badge)
- Tests will pass once plugin is updated to v0.3.4 in cluster
The E2E test suite now provides comprehensive coverage of:
- Plugin registration and loading
- Navigation and routing
- Settings configuration
- App bar integration
- Dark mode support
- Data fetching and rendering
Generated with [Claude Code](https://claude.ai/code)
via [Happy](https://happy.engineering)
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Happy <yesreply@happy.engineering>
* ci: fix checksum for manually created GitHub release v0.2.0
The GitHub release was created manually with gh CLI, so the checksum
in metadata didn't match. This updates the checksum to match the actual
tarball on GitHub.
Generated with [Claude Code](https://claude.ai/code)
via [Happy](https://happy.engineering)
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Happy <yesreply@happy.engineering>
* refactor: migrate to GitHub as primary repository
- Move release workflow from Gitea Actions to GitHub Actions
- Update checksum to match manually created GitHub v0.2.0 release
- Simplify workflow by removing Gitea-specific steps
- Use softprops/action-gh-release for easier release management
This eliminates the complexity of Gitea mirroring and the issues
with GH_TOKEN authentication in Gitea Actions.
Generated with [Claude Code](https://claude.ai/code)
via [Happy](https://happy.engineering)
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Happy <yesreply@happy.engineering>
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Happy <yesreply@happy.engineering>
The GitHub Actions fallback workflow raced with the Gitea CI — it ran
first and created the GitHub release with its own tarball (different
checksum), causing the Gitea CI's upload to fail and leaving a
checksum mismatch on Artifact Hub.
- Remove .github/workflows/release.yml entirely (Gitea CI handles both
Gitea and GitHub releases)
- Fix the Gitea CI's GitHub release step to delete existing assets
before uploading, so re-runs and race conditions are handled gracefully
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
## Summary
- Fix the v0.0.1 archive checksum in `artifacthub-pkg.yml` to match the actual GitHub release tarball (was causing "Checksum mismatch" on Headlamp plugin install)
- Gitea CI now computes the checksum after packaging and updates `artifacthub-pkg.yml` on `main` via the Gitea API, then uploads the **same tarball** to GitHub releases (requires `GH_PAT` secret) so both releases serve identical artifacts
- GitHub CI becomes a fallback — skips entirely if the Gitea CI already created the release, preventing a second build from producing a mismatched tarball
## Setup required
Add a `GH_PAT` secret to the Gitea repo containing a GitHub personal access token with `repo` scope. Without it, the GitHub release step gracefully skips and the GitHub Actions fallback handles it.
## Test plan
- [ ] Verify `GH_PAT` secret is set in Gitea repo settings
- [ ] Tag and push a new release (`v0.0.2`)
- [ ] Confirm Gitea CI updates `artifacthub-pkg.yml` checksum on `main`
- [ ] Confirm GitHub release is created by Gitea CI with matching tarball
- [ ] Confirm GitHub Actions fallback skips (release already exists)
- [ ] Verify Headlamp plugin installs without checksum mismatch
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Chris Farhood <chris@farhood.org>
Reviewed-on: farhoodliquor/polaris-headlamp-plugin#1
Co-authored-by: claude <no-reply.claude@farh.net>
Co-committed-by: claude <no-reply.claude@farh.net>
Artifact Hub requires a GitHub-hosted repo for Headlamp plugins.
Since Gitea push-mirrors git objects but not releases, a GitHub
Actions workflow builds and publishes GitHub Releases with the
tarball that Artifact Hub needs.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Gandalf the Greybeard
Hugh Hackman
Chris Farhood