Communitygithub.com

Nuvraxis/nuvraxis-plugins

GitHub Actions Konventionen für Nuvraxis Next.js-Apps – drei Workflows: pr.yaml, main.yaml, release.yaml. Minimalberechtigungen, GITHUB_TOKEN, gepinnte Action-Majors.

Was ist nuvraxis-plugins?

Dieses Skill definiert eine standardisierte CI/CD-Pipeline für Nuvraxis Next.js-Anwendungen mit genau drei GitHub Actions Workflows: pr.yaml (für Pull-Requests: Biome, stylelint, TypeCheck/Build mit Turbo --affected, Docker-Build + Health Check, Helm Lint + Kubeconform – keine Veröffentlichung), main.yaml (Push auf main: ein Multi-Arch-Image nach GHCR mit sha-<KurzSHA> und main-Tag, Provenance und SBOM, GHA-Cache) und release.yaml (Tag vX.Y.Z: Image nicht neu bauen, sondern existierendes Image mit den Tags vX.Y.Z und latest retaggen, Helm-Chart in OCI pushen, GitHub Release mit Chart-Digest und SBOM). Die Workflows folgen strengen Sicherheitsregeln: Minimale Berechtigungen pro Job, ausschließliche Nutzung des GITHUB_TOKEN, gepinnte Action-Majors (z. B. @v7) und keine persönlichen Access-Token. Die `concurrency`-Einstellungen brechen alte PR-Läufe ab, während main- und Tag-Läufe immer vollständig ausgeführt werden. Das Skill wird aktiviert, wenn `.github/workflows/*` bearbeitet, ein CI-Schritt hinzugefügt oder ein fehlgeschlagener Lauf oder Release debuggt wird. Unterstützt werden GitHub Actions, Docker BuildKit, Helm OCI und Turborepo mit dem `--affected`-Flag für effizientes Bauen.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Nuvraxis/nuvraxis-plugins/tree/HEAD/plugins/nuvraxis-frontend/skills/github-actions
Original anzeigen→Alle Skills durchsuchen

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Dokumentation

GitHub Actions

Drei Workflows pro App, jeder mit einem Job seiner Art. Die Vorlage .github/workflows/{pr,main,release}.yaml ist die Quelle der Wahrheit; sie werden mit Anmerkungen in references/workflows.md reproduziert.

pull request ──► pr.yaml       Prüfungen nur, nichts veröffentlicht
merge to main ─► main.yaml     Image einmal gebaut → ghcr.io/nuvraxis/<app>:sha-<short>, :main
tag vX.Y.Z ────► release.yaml  gleiches Image retagged :vX.Y.Z, :latest · Chart X.Y.Z → OCI · GitHub Release

Regeln für jeden Workflow

  1. permissions: contents: read oben; pro Job nur nach Bedarf erweitern. packages: write für Jobs, die in GHCR pushen, contents: write nur für den Job, der das Release erstellt. Kein id-token: write oder attestations: write: Provenance und SBOM kommen von BuildKit, nicht von actions/attest* (benötigt GitHub Enterprise für private Repos).

  2. Nur GITHUB_TOKEN. GHCR-Login verwendet ${{ github.actor }} / ${{ secrets.GITHUB_TOKEN }}; gh verwendet GH_TOKEN: ${{ github.token }}. Keine persönlichen Access-Tokens in CI. (Das Ziehen privater Pakete aus dem Cluster ist ein anderes Zugangsdaten; siehe helm-nextjs.)

  3. Action-Majors pinnen (@v7) und die SHA-Tabelle aktuell halten. Die Vorlage verwendet Major-Tags zur Lesbarkeit. Falls die Organisation SHA-Pinning verlangt, ersetze jedes @vN durch den SHA aus references/action-pins.md und behalte den # vN.M.P-Kommentar bei. Aktuelle Majors: checkout v7, setup-node v7, pnpm/action-setup v6, setup-qemu v4, setup-buildx v4, login v4, metadata v6, build-push v7, azure/setup-helm v5.

  4. Toolchain: pnpm/action-setup vor actions/setup-node. action-setup liest die pnpm-Version aus packageManager; setup-node liest .node-version und cacht den pnpm-Store (cache: pnpm benötigt pnpm zuerst im PATH). Dann pnpm install --frozen-lockfile. Niemals npm ci.

  5. concurrency pro Workflow und Ref; nur bei PRs laufende abbrechen. Ein neuer Push auf einen PR bricht den alten Lauf ab. Auf main und Tags laufen immer vollständig: release.yaml benötigt das Image des exakten Commits.

  6. Nie Secrets ausgeben oder unvertraute Eingaben in run: interpolieren. Werte über env: übergeben und in Anführungszeichen setzen ("${APP}"). ${{ github.event.pull_request.title }} und ähnliches niemals in ein Skript einfügen. persist-credentials: false bei Checkout, wenn der Job nicht in Git pusht.

  7. Jeder Job hat timeout-minutes. Ein hängender Docker-Build würde sonst sechs Stunden verbrauchen.

  8. Namen in Kleinbuchstaben. GHCR lehnt Großbuchstaben-Repositories ab. IMAGE: ghcr.io/nuvraxis/<app> wird in Kleinbuchstaben in env geschrieben; das Scaffold wandelt den App-Namen in Kleinbuchstaben um.

pr.yaml

  1. on: pull_request mit types: [opened, synchronize, reopened, ready_for_review] und ohne branches-Filter, damit auch gestapelte PRs gegen Feature-Branches geprüft werden. Jeder Job hat if: ${{ !github.event.pull_request.draft }}; als bereit markieren löst den Lauf aus.

  2. Vier parallele Jobs: quality (biome ci --reporter=github, stylelint, turbo run typecheck test --affected, pnpm audit --audit-level high), build (turbo run build --affected), docker (eine Plattform mit load: true bauen, schreibgeschützt mit reduzierten Capabilities ausführen, curl /api/health), helm (helm lint --strict und kubeconform auf beiden values-Dateien). --affected benötigt fetch-depth: 0.

  3. Von einem PR wird nichts gepusht. push: false, Cache schreibgeschützt (nur cache-from), kein Registry-Login.

main.yaml

  1. on: push: branches: [main] baut das Image einmal für beide Architekturen und pusht es. Tags von docker/metadata-action: type=sha,format=short,prefix=sha- und type=raw,value=main, flavor: latest=false. latest gehört zu Releases.

  2. provenance: mode=max, sbom: true, cache-from/to: type=gha,scope=<app>,mode=max. Provenance und SBOM werden an den Image-Index angehängt; release.yaml trägt sie beim Retaggen mit. NEXT_DEPLOYMENT_ID=${{ github.sha }} ist das Build-Argument für Skew-Schutz.

  3. main.yaml veröffentlicht weder das Chart noch wiederholt es PR-Prüfungen. Branch-Schutz erfordert pr.yaml; main produziert nur das Artefakt.

release.yaml

  1. on: push: tags: ['v*.*.*'], dann in dieser Reihenfolge:

    1. Fehlschlagen, es sei denn, der Tag ist exakt vMAJOR.MINOR.PATCH und sein Commit ist ein Vorfahre von origin/main.
    2. Nicht neu bauen. Wenn ghcr.io/nuvraxis/<app>:sha-<short> nicht existiert, fehlschlagen mit „main.yaml beenden lassen, dann erneut ausführen“. Kein Fallback-Build.
    3. docker buildx imagetools create --tag :vX.Y.Z --tag :latest <sha-image>: Eine Manifest-Ebene-Kopie, die beide Architekturen, Provenance und SBOM bei demselben Digest behält.
    4. helm package --version X.Y.Z --app-version vX.Y.Z, helm push an oci://ghcr.io/nuvraxis/charts.
    5. gh release create vX.Y.Z --verify-tag --generate-notes mit dem Chart .tgz, image-digest.txt und sbom.spdx.json als Anhänge.

  2. Das Release-Ritual: Merge auf main → warten, bis main.yaml grün ist → git tag vX.Y.Z && git push origin vX.Y.Z. Das Taggen vor Abschluss von main.yaml führt Schritt 2 absichtlich zum Fehlschlag; führe den Release-Job erneut aus, sobald das Image existiert. Ein fehlerhaftes Release wird mit einem neuen Patch-Tag behoben, niemals durch Verschieben eines Tags.

Beschleunigung (nur bei Bedarf)

  • arm64 unter QEMU ist der langsame Teil von main.yaml. Ersetze durch eine Matrix auf ubuntu-24.04-arm + ubuntu-latest, die per Digest pusht, dann einen Merge-Job mit imagetools create. Behalte die Tags und den einzelnen Index.
  • Turborepo-Remote-Cache für pr.yaml: siehe pnpm-turborepo.

Überprüfen

docker run --rm -v "$PWD:/repo" -w /repo rhysd/actionlint:latest     # alle Workflows linten
gh workflow list && gh run list --limit 5
gh run view <run-id> --log-failed

Nach einem Release: docker buildx imagetools inspect ghcr.io/nuvraxis/<app>:vX.Y.Z zeigt beide Plattformen, und helm show chart oci://ghcr.io/nuvraxis/charts/<app> --version X.Y.Z zeigt appVersion: vX.Y.Z.

Quellen

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

Nuvraxis/nuvraxis-plugins

>- Biome 2.5 setup and rules for Nuvraxis monorepos — root biome.json with pinned $schema, VCS ignore, formatter settings, the recommended preset with a11y and the react/next domains, nursery policy, organize imports, overrides, nested per-package configs ("extends": "//"), biome check --write locally, biome ci in CI, VS Code settings, and migrating from ESLint/Prettier. Use when the repo has biome.json or biome.jsonc, @biomejs/biome in package.json, .eslintrc*/eslint.config.*/.prettierrc* to migrate, or when fixing lint and formatting errors.

Nuvraxis/nuvraxis-plugins

>- Dockerfile rules for Next.js standalone apps in a pnpm + Turborepo monorepo — multi-stage build (turbo prune → pnpm fetch/offline install → turbo build → minimal runner), pinned Node 26 Alpine by digest, checksum-verified pnpm binary, non-root uid 1001, read-only root filesystem with a writable .next/cache, HEALTHCHECK on /api/health, build args only for NEXT_PUBLIC_* values, BuildKit secrets and cache mounts, multi-arch, OCI labels and .dockerignore. Use when the repo has a Dockerfile, .dockerignore, compose file, or next.config with output "standalone", or when asked to containerise, shrink, harden or debug an image.

Nuvraxis/nuvraxis-plugins

>- Helm chart rules for Nuvraxis Next.js apps — one chart per app in charts/ (named after the app), published to oci://ghcr.io/nuvraxis/charts and synced by Argo CD; Chart.yaml version/appVersion set only by release.yaml; Deployment with startup/liveness/readiness probes on /api/health, non-root read-only security context, emptyDir for .next/cache, ConfigMap + existing Secret via envFrom, Service, Ingress with cert-manager, HPA, PDB, ServiceAccount, topology spread; no Helm hooks; helm lint --strict + kubeconform. Use when the repo has charts/, Chart.yaml, values*.yaml, templates/*.yaml with Helm syntax, or an Argo CD Application, or when asked to deploy, scale, expose or configure the app on Kubernetes.

Nuvraxis/nuvraxis-plugins

>- Production rules for Next.js 16 App Router apps at Nuvraxis — Server/Client Component boundaries, Cache Components ("use cache", cacheLife, cacheTag, updateTag), Server Actions, route handlers, env handling, instrumentation, output standalone and the /api/health route. Use when the project has "next" in package.json, an app/ or src/app/ directory, next.config.ts, proxy.ts, instrumentation.ts, or files named page.tsx, layout.tsx, route.ts, loading.tsx, error.tsx.

Verwandte Skills

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community