Communitygithub.com

Nuvraxis/nuvraxis-plugins

Règles pour les chart Helm des applications Next.js Nuvraxis — un chart par application dans charts/ (nommé d'après l'application), publié sur oci://ghcr.io/nuvraxis/charts et synchronisé par Argo CD.

Qu'est-ce que nuvraxis-plugins ?

Cette compétence définit les règles pour créer et gérer des chart Helm pour les applications Next.js Nuvraxis. Chaque application possède son propre chart dans le répertoire charts/<app>/, versionné et publié via OCI sur ghcr.io/nuvraxis/charts. Les chart sont conçus pour être synchronisés par Argo CD, avec des sondes de démarrage, de vivacité et de disponibilité pointant sur /api/health, un contexte de sécurité non-root read-only, un emptyDir pour le cache .next, et une configuration via ConfigMap et Secret existant. La compétence interdit l'édition manuelle des versions (version et appVersion), impose des sondes strictes, des ressources mémoire avec limite mais pas de limite CPU, et une haute disponibilité par défaut (2 réplicas, PDB, mise à jour glissante). Elle valide les chart avec helm lint --strict et kubeconform, et exige que tout soit une fonction pure des valeurs, sans hooks Helm ni fonctions aléatoires.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Nuvraxis/nuvraxis-plugins/tree/HEAD/plugins/nuvraxis-frontend/skills/helm-nextjs
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

Chart Helm pour une application Next.js

À utiliser pour charts/<app>/ et comment Argo CD le consomme. L'image exécutée provient de docker-nextjs ; le pipeline qui publie les deux est github-actions.

Le dossier charts/__APP__/ du template est la source de vérité. Toutes les valeurs avec commentaires : references/values.md. Câblage Argo CD : references/argocd.md.

Règles

  1. Un chart par application, dans charts/<app>/ à la racine du dépôt de l'application. Pourquoi là : Argo CD peut le synchroniser directement depuis git (path: charts/<app>) pour un environnement de développement et depuis le registre OCI pour la production, avec les mêmes fichiers ; il est en dehors de apps/, donc ni dans le contexte de construction Docker ni dans un paquet pnpm workspace ; et les modifications du chart accompagnent le code qui en a besoin dans la même PR. Le chart est délibérément mono-application : pas de chart umbrella, pas de sous-charts. Des templates génériques pilotés par les valeurs (comme le chart umbrella backend) uniquement là où une seule application a besoin du commutateur : Ingress, HPA, PDB, topology spread.

  2. Ne jamais modifier manuellement version ou appVersion. Les deux restent 0.0.0 dans git. release.yaml exécute helm package --version X.Y.Z --app-version vX.Y.Z à partir du tag vX.Y.Z, de sorte que le chart publié et le tag d'image correspondent toujours.

  3. image.tag par défaut à appVersion ; ne le définir que pour les environnements synchronisés par git. Depuis OCI, appVersion est le tag de version et l'image est ghcr.io/nuvraxis/<app>:vX.Y.Z. Synchronisé depuis git, appVersion est 0.0.0, donc l'Application Argo CD définit image.tag: sha-<short-sha> (ou main). image.repository est en minuscules, toujours.

  4. Sondes : démarrage, vivacité et disponibilité, toutes sur /api/health. La sonde de démarrage (2s × 30) couvre le boot ; la vivacité et la disponibilité ne démarrent qu'après. La route ne touche jamais une dépendance, donc une panne de base de données ne redémarre pas les pods. Ne pas pointer une sonde sur / : cela rend une page.

  5. Contexte de sécurité correspond à l'image : uid/gid 1001, runAsNonRoot, readOnlyRootFilesystem, pas d'escalade de privilèges, toutes les capacités supprimées, seccomp RuntimeDefault. automountServiceAccountToken: false à la fois sur le ServiceAccount et le pod : l'application n'appelle pas l'API Kubernetes.

  6. .next/cache est un emptyDir avec un sizeLimit. C'est le seul chemin inscriptible (/app/apps/<app>/.next/cache). La limite empêche un cache d'image incontrôlé de remplir le nœud.

  7. Configuration via envFrom : une ConfigMap depuis values.config, et un Secret qui existe déjà.

    config:
  API_BASE_URL: https://api.nuvraxis.com
existingSecret: portal-secrets

    Le chart ne template jamais les valeurs secrètes : pas de kind: Secret avec data depuis les valeurs, pas de --set secret=…. Le Secret est créé par External Secrets, Sealed Secrets ou un opérateur, et seul son nom est dans les valeurs. Un changement de ConfigMap redémarre les pods via l'annotation checksum/config.

  8. Pas de NEXT_PUBLIC_* dans le chart. Ils sont intégrés à la construction de l'image (voir docker-nextjs) ; les définir à l'exécution ne fait rien.

  9. Ressources : requests pour CPU et mémoire, une limite de mémoire, pas de limite CPU. Les limites CPU étranglent un serveur Node lors des pics et augmentent la latence de queue ; la limite de mémoire reste parce que le heap de Node grandit jusqu'à ce qu'on lui donne.

  10. Haute disponibilité par défaut : 2 réplicas, PDB maxUnavailable: 1, mise à jour glissante avec maxUnavailable: 0, contraintes de dispersion topologique entre zones et nœuds (ScheduleAnyway). Avec autoscaling.enabled, le Deployment omet replicas, donc Argo CD et le HPA ne se battent pas pour cela.

  11. Ingress est optionnel, TLS via les annotations cert-manager. ingress.enabled, className, hosts, tls avec un secretName, et cert-manager.io/cluster-issuer dans les annotations. Pour les réponses en streaming sur ingress-nginx ajouter nginx.ingress.kubernetes.io/proxy-buffering: "off" ; pour la limitation de débit, limit-rps (voir nextjs-security).

  12. Pas de hooks Helm, pas de lookup, pas de valeurs aléatoires. Argo CD rend le chart avec helm template et applique le résultat : les hooks deviennent des hooks Argo avec une sémantique différente, lookup ne retourne rien, et randAlphaNum change à chaque synchronisation et montre l'application comme définitivement désynchronisée. Tout ce qui est rendu doit être une fonction pure des valeurs.

  13. Les paquets GHCR privés nécessitent des identifiants de pull. Les paquets GHCR sont privés dès la première publication. Pour les images : un Secret docker-registry avec un token ayant read:packages, référencé dans imagePullSecrets (les valeurs de production référencent ghcr-pull). Pour le chart dans Argo CD : un Secret de dépôt avec enableOCI: "true" (voir references/argocd.md). Ou rendre les paquets publics dans GitHub si le code est public.

  14. values-production.yaml ne contient que ce qui diffère en production. Superposer : -f values.yaml -f values-production.yaml. Ne pas copier les valeurs par défaut dedans.

  15. Valider avec helm lint --strict et helm template | kubeconform -strict. Pourquoi kubeconform plutôt que helm-unittest : les bugs qu'un chart mono-application a réellement sont des noms de champs, types ou versions d'API incorrects dans la sortie rendue, ce que kubeconform attrape contre les schémas Kubernetes réels avec zéro code de test. helm-unittest vérifie la logique des templates, que ce chart a à peine. Valider et linter les deux fichiers de valeurs, comme le fait pr.yaml.

Ajouts

BesoinModification
Une variable d'environnement runtimeconfig: dans les valeurs (non secrète) ou une clé dans le Secret existant
Un secretl'ajouter au Secret externe ; rien ne change dans le chart
Un autre port ou sidecarle justifier d'abord ; une application Next a besoin d'un port
Un cron jobun chart ou une application séparé(e), pas ce Deployment
NetworkPolicyajouter templates/networkpolicy.yaml, activé par networkPolicy.enabled

Vérification

helm lint --strict charts/<app>
helm lint --strict charts/<app> -f charts/<app>/values-production.yaml
helm template <app> charts/<app> -f charts/<app>/values-production.yaml \
  | docker run --rm -i ghcr.io/yannh/kubeconform:v0.8.0 -strict -summary -kubernetes-version 1.34.0 -

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

>- GitHub Actions conventions for Nuvraxis Next.js apps — exactly three workflows: pr.yaml (every PR to any branch: Biome, stylelint, typecheck/test/build with turbo --affected, Docker build + health check, helm lint + kubeconform; publishes nothing), main.yaml (push to main: one multi-arch image to GHCR tagged sha-SHORTSHA and main, provenance + SBOM, gha cache), release.yaml (tag vX.Y.Z: verify on main, retag the existing image without rebuilding, package and push the Helm chart to OCI, GitHub Release with chart, digest and SBOM). Minimal permissions per job, GITHUB_TOKEN only, pinned action majors. Use when editing .github/workflows/*, adding a CI step, or debugging a failed run or release.

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