ARC runner scale set label changed from local-ubuntu-latest to
runners-privilegedescalation. The shared workflows were updated in
.github PR #28 but this per-repo e2e workflow was missed.
Co-authored-by: Hugh Hackman <hugh@privilegedescalation.com>
* e2e: shared volume plugin deployment replacing init container approach
Replace the init container plugin installation with a shared PVC volume
between the CI runner and Headlamp pod. The runner builds the plugin and
copies it to the shared mount; Headlamp reads from the same volume.
- Add deployment/headlamp-e2e-values.yaml (PVC-backed shared volume)
- Add deployment/headlamp-plugins-pvc.yaml (PVC manifest)
- Add scripts/deploy-plugin-via-volume.sh (build + copy + restart)
- Remove deployment/headlamp-static-plugin-values.yaml (init container)
This is CI-only test infrastructure — ArtifactHub remains the sole
user-facing distribution channel.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* ci: update e2e workflow for shared volume plugin deployment
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>
* ci: align e2e workflow with Gandalf's deploy script interface
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>
* fix: deploy plugin via temporary pod instead of assuming local PVC mount
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>
* fix: add kubectl, helm, and helm repo setup steps to e2e workflow
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>
* fix: update Headlamp Helm repo URL from headlamp-k8s to kubernetes-sigs
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>
* chore: add RBAC manifest for E2E CI runner
Documents the Role and RoleBinding applied to the cluster for the ARC
runner service account. Grants permissions in kube-system needed for
shared volume plugin deployment (PVCs, pods, Helm resources).
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix: remove .github/workflows/e2e.yaml changes from PR
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>
* ci: add shared volume plugin deployment to E2E workflow
Adds the build, Helm, PVC, and plugin deploy steps needed for the
shared volume E2E approach. Uses the correct kubernetes-sigs Helm repo
URL and overrides config.sessionTTL=0 to avoid schema validation error.
This is the workflow counterpart to the deployment manifests and scripts
already in this PR (PVC, values overlay, deploy script).
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix(e2e): set sessionTTL=1 to satisfy Helm schema minimum
The Headlamp Helm chart schema enforces a minimum of 1 for
config.sessionTTL. Setting it to 0 caused helm upgrade to fail
with a schema validation error.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix(e2e): add cluster-scoped RBAC for CI runner
The Headlamp Helm chart manages ClusterRole and ClusterRoleBinding
resources. The CI runner SA needs cluster-level permissions to
get/update these during helm upgrade. Added ClusterRole and
ClusterRoleBinding alongside the existing namespace-scoped Role.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix(e2e): replace helm upgrade with kubectl patch to avoid cluster RBAC
The CI runner SA cannot access cluster-scoped resources (ClusterRole,
ClusterRoleBinding) needed by helm upgrade's 3-way merge. Replace the
helm upgrade step with kubectl patch commands that add the shared volume
mount directly to the Headlamp deployment.
This eliminates the need for cluster-admin intervention:
- kubectl patch adds PVC volume + volumeMount to the deployment
- kubectl set env configures the plugins directory
- kubectl rollout status waits for the update
Also removes the now-unnecessary ClusterRole/ClusterRoleBinding from the
RBAC manifest — only namespace-scoped Role/RoleBinding is needed.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix(e2e): improve volume mount idempotency check
Check for existing volume mount by mountPath and PVC claimName, not
just by volume name. A prior helm upgrade may have created mounts
with different names but the same path, causing kubectl patch to fail
with "mountPath must be unique".
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix(e2e): schedule deploy pod on same node as Headlamp
The headlamp-plugins PVC is ReadWriteOnce, so the temporary deploy
pod must run on the same node as the Headlamp pod to mount it.
Look up the Headlamp pod's node and set nodeName in the pod spec.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix(e2e): use Job with base64 tarball instead of kubectl run stdin
The kubectl run --rm -i stdin pipe times out in the ARC runner
environment. Replace with a Kubernetes Job that receives the plugin
tarball as base64-encoded data in the container command. This avoids
the unreliable attach/stdin mechanism entirely.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix(e2e): use ConfigMap for tarball instead of inline base64
Embedding base64 data in the YAML spec broke parsing. Store the plugin
tarball in a ConfigMap via --from-file and mount it in the deploy Job.
This avoids both the stdin pipe issue and the YAML escaping issue.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix(e2e): use temp file for Job YAML to avoid heredoc escaping
Variable expansion inside heredocs breaks YAML parsing when values
contain colons and quotes (like nodeName). Write the Job manifest to
a temp file with literal YAML, then sed-substitute the dynamic values.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix(e2e): use Pod instead of Job for plugin deploy
The CI runner SA has permission to create Pods but not Jobs in
kube-system. Switch from a Job to a plain Pod with restartPolicy:Never.
Use ConfigMap mount for tarball data (no stdin piping needed).
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix: align registerPluginSettings name with deployed plugin directory
The plugin is deployed to the 'polaris' directory but was registered with
'headlamp-polaris', causing Headlamp to not match the settings component
with the loaded plugin. This fixes all 5 failing E2E settings tests.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix: use package name for registerPluginSettings, not directory name
Headlamp identifies plugins by their package.json name (headlamp-polaris),
not the deploy directory name (polaris). The previous commit incorrectly
changed this to 'polaris', causing the settings component to never render
in the plugin settings page — breaking all 5 E2E settings tests.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix: align registerPluginSettings name with deploy directory 'polaris'
The shared volume deploy script places the plugin at /headlamp/plugins/polaris/,
so Headlamp matches settings by directory name 'polaris', not the package.json
name 'headlamp-polaris'. This reverts commit b9d718b which incorrectly changed
the registration name back to 'headlamp-polaris'.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix: align plugin deploy dir with package.json name, clean stale dirs
The PVC had a stale headlamp-polaris directory from a previous install.
Headlamp loads plugins by scanning the plugins dir and reading package.json
from each subdirectory — it was loading the old build from headlamp-polaris/
while the deploy script was writing to polaris/. The settings registration
name needs to match the plugin name Headlamp identifies.
Changes:
- Deploy script now uses headlamp-polaris as the directory name (matching
package.json name field)
- Deploy pod cleans up both polaris/ and headlamp-polaris/ before deploying
to ensure no stale copies remain
- registerPluginSettings uses headlamp-polaris to match Headlamp's plugin
identifier
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix: align registerPluginSettings and E2E test with package.json name
Headlamp identifies plugins by reading package.json from the plugin
directory. Since package.json name is 'headlamp-polaris', both the
registerPluginSettings call and the E2E settings test must use
'headlamp-polaris', not 'polaris'.
- registerPluginSettings('polaris') → registerPluginSettings('headlamp-polaris')
- E2E test locator: text=polaris → text=headlamp-polaris
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix(e2e): load main page before settings to ensure plugin list is populated
Headlamp's PluginSettings component initializes its state from
localStorage on mount and never syncs when props.plugins updates later.
If the settings page loads before fetchAndExecutePlugins completes,
the plugin list stays empty and the test can't find "headlamp-polaris".
Fix: navigate to the main page first, wait for the Polaris sidebar
entry to confirm the plugin is loaded (which populates localStorage),
then navigate to the settings page.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix(e2e): use client-side routing for settings navigation
The PluginSettings component reads the plugin registry once on mount
and never re-renders when new plugins register. Using page.goto() for
the settings URL re-initializes the SPA, causing PluginSettings to
mount before async plugin scripts finish calling registerPluginSettings().
Replace page.goto() with pushState + popstate to do client-side routing.
This preserves the already-loaded plugin registrations from the main
page, so PluginSettings sees the plugin immediately on mount.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* fix(e2e): use correct HOME-context URL for plugin settings page
The settings page is at /settings/plugins (HOME sidebar context), not
/c/main/settings/plugins (in-cluster context). The in-cluster URL
doesn't match any route, so PluginSettings never mounted and the
plugin entry was never visible.
With the correct URL, no preloading or client-side routing hacks are
needed — PluginSettings uses useTypedSelector on the Redux plugin store,
so it re-renders automatically when registerPluginSettings() fires.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
---------
Co-authored-by: Gandalf the Greybeard <gandalf@privilegedescalation.dev>
Co-authored-by: Paperclip <noreply@paperclip.ing>
Co-authored-by: Hugh Hackman <hugh@privilegedescalation.com>
Co-authored-by: Hugh Hackman <hugh-hackman[bot]@users.noreply.github.com>
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>
privilegedescalation-paperclip[bot]
Chris Farhood