Communitygithub.com

Nuvraxis/nuvraxis-plugins

Conventions GitHub Actions pour les applications Next.js Nuvraxis — exactement trois workflows : pr.yaml, main.yaml et release.yaml, avec des permissions minimales et GITHUB_TOKEN uniquement.

Qu'est-ce que nuvraxis-plugins ?

Ce skill définit un ensemble standardisé de workflows GitHub Actions pour les applications Next.js de l'écosystème Nuvraxis. Il impose exactement trois workflows : pr.yaml pour les pull requests (vérifications Biome, stylelint, typecheck/test/build avec turbo --affected, build Docker + health check, lint Helm + kubeconform), main.yaml pour les pushes sur main (construction d'une image multi-architecture avec provenance et SBOM, cache GHA), et release.yaml pour les tags (retag d'une image existante sans reconstruire, publication du chart Helm en OCI, création d'une GitHub Release). Les règles incluent des permissions minimales par job, l'utilisation exclusive du GITHUB_TOKEN, le pinning des actions aux versions majeures, et une gestion stricte de la concurrence. Le skill est particulièrement utile lors de la modification des fichiers .github/workflows/, de l'ajout d'une étape CI, ou du débogage d'un échec de run ou de release. Il est compatible avec Claude Code, Cursor et tout agent capable de générer ou maintenir du code CI/CD.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Nuvraxis/nuvraxis-plugins/tree/HEAD/plugins/nuvraxis-frontend/skills/github-actions
Voir l'original→Voir toutes les compétences

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

GitHub Actions

Trois workflows par application, chacun avec un job de son type. Le modèle .github/workflows/{pr,main,release}.yaml est la source de vérité ; ils sont reproduits avec des notes dans references/workflows.md.

pull request ──► pr.yaml       vérifications uniquement, rien n'est publié
merge to main ─► main.yaml     image construite une fois → ghcr.io/nuvraxis/<app>:sha-<short>, :main
tag vX.Y.Z ────► release.yaml  retag de la même image :vX.Y.Z, :latest · chart X.Y.Z → OCI · GitHub Release

Règles pour chaque workflow

  1. permissions: contents: read en haut ; élargir par job uniquement si nécessaire. packages: write pour les jobs qui poussent vers GHCR, contents: write uniquement pour le job qui crée la Release. Pas de id-token: write ou attestations: write : provenance et SBOM proviennent de BuildKit, pas de actions/attest* (qui nécessite GitHub Enterprise pour les dépôts privés).

  2. GITHUB_TOKEN uniquement. La connexion GHCR utilise ${{ github.actor }} / ${{ secrets.GITHUB_TOKEN }} ; gh utilise GH_TOKEN: ${{ github.token }}. Pas de jetons d'accès personnels dans CI. (Le tirage de paquets privés depuis le cluster est une information d'identification différente ; voir helm-nextjs.)

  3. Pinner les actions aux versions majeures (@v7) et tenir à jour le tableau SHA. Le modèle utilise des tags majeurs pour la lisibilité. Si l'organisation exige le pinning SHA, remplacez chaque @vN par le SHA de references/action-pins.md et conservez le commentaire # vN.M.P. Versions majeures actuelles : 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. Chaîne d'outils : pnpm/action-setup avant actions/setup-node. action-setup lit la version pnpm depuis packageManager ; setup-node lit .node-version et met en cache le store pnpm (cache: pnpm nécessite pnpm sur PATH d'abord). Ensuite pnpm install --frozen-lockfile. Jamais npm ci.

  5. concurrency par workflow et ref ; annuler en cours sur les PRs uniquement. Une nouvelle poussée vers une PR annule l'ancien run. Sur main et les tags, les runs se terminent toujours : release.yaml nécessite l'image de cet commit exact.

  6. Ne jamais afficher de secrets ni interpoler d'entrées non fiables dans run:. Passer les valeurs via env: et les citer ("${APP}"). ${{ github.event.pull_request.title }} et autres ne doivent jamais se trouver dans un script. persist-credentials: false sur le checkout lorsque le job ne pousse pas vers git.

  7. Chaque job a timeout-minutes. Une construction Docker bloquée brûlerait autrement six heures.

  8. Les noms sont en minuscules. GHCR rejette les dépôts en majuscules. IMAGE: ghcr.io/nuvraxis/<app> est écrit en minuscules dans env ; le scaffold met le nom de l'app en minuscules.

pr.yaml

  1. on: pull_request avec types: [opened, synchronize, reopened, ready_for_review] et sans filtre branches, afin que les PRs empilées contre des branches de fonctionnalités soient également vérifiées. Chaque job a if: ${{ !github.event.pull_request.draft }} ; marquer comme prêt déclenche le run.

  2. Quatre jobs parallèles : quality (biome ci --reporter=github, stylelint, turbo run typecheck test --affected, pnpm audit --audit-level high), build (turbo run build --affected), docker (construire une plateforme avec load: true, l'exécuter en lecture seule avec les capacités supprimées, curl /api/health), helm (helm lint --strict et kubeconform sur les deux fichiers values). --affected nécessite fetch-depth: 0.

  3. Rien n'est poussé depuis une PR. push: false, cache en lecture seule (cache-from uniquement), pas de connexion au registre.

main.yaml

  1. on: push: branches: [main] construit l'image une fois, pour les deux architectures, et la pousse. Tags de docker/metadata-action : type=sha,format=short,prefix=sha- et type=raw,value=main, flavor: latest=false. latest appartient aux releases.

  2. provenance: mode=max, sbom: true, cache-from/to: type=gha,scope=<app>,mode=max. La provenance et le SBOM sont attachés à l'index d'image ; release.yaml les transporte lorsqu'il retague. NEXT_DEPLOYMENT_ID=${{ github.sha }} est l'argument de build pour la protection contre le skew.

  3. main.yaml ne publie pas le chart et ne relance pas les vérifications PR. La protection de branche nécessite pr.yaml ; main ne produit que l'artefact.

release.yaml

  1. on: push: tags: ['v*.*.*'], puis dans l'ordre :

    1. Échouer sauf si le tag est exactement vMAJOR.MINOR.PATCH et que son commit est un ancêtre de origin/main.
    2. Ne pas reconstruire. Si ghcr.io/nuvraxis/<app>:sha-<short> n'existe pas, échouer avec « laissez main.yaml se terminer, puis relancez ». Pas de construction de repli.
    3. docker buildx imagetools create --tag :vX.Y.Z --tag :latest <sha-image> : une copie au niveau du manifeste qui conserve les deux architectures, la provenance et le SBOM, au même digest.
    4. helm package --version X.Y.Z --app-version vX.Y.Z, helm push vers oci://ghcr.io/nuvraxis/charts.
    5. gh release create vX.Y.Z --verify-tag --generate-notes avec le chart .tgz, image-digest.txt et sbom.spdx.json joints.

  2. Le rituel de release : merger vers main → attendre que main.yaml devienne vert → git tag vX.Y.Z && git push origin vX.Y.Z. Tagger avant que main.yaml ne se termine fait échouer l'étape 2 intentionnellement ; relancez le job de release une fois que l'image existe. Une mauvaise release est corrigée avec un nouveau tag de patch, jamais en déplaçant un tag.

Accélérer (uniquement si nécessaire)

  • arm64 sous QEMU est la partie lente de main.yaml. Remplacer par une matrice sur ubuntu-24.04-arm + ubuntu-latest en poussant par digest, puis un job de fusion avec imagetools create. Conserver les tags et l'index unique.
  • Cache distant Turborepo pour pr.yaml : voir pnpm-turborepo.

Vérifier

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

Après une release : docker buildx imagetools inspect ghcr.io/nuvraxis/<app>:vX.Y.Z affiche les deux plateformes, et helm show chart oci://ghcr.io/nuvraxis/charts/<app> --version X.Y.Z affiche appVersion: vX.Y.Z.

Sources

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.

Skills associés

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