Communitygithub.com

Nuvraxis/nuvraxis-plugins

Convenciones de GitHub Actions para aplicaciones Next.js de Nuvraxis: exactamente tres flujos de trabajo (pr.yaml, main.yaml, release.yaml) con permisos mínimos, GITHUB_TOKEN como único token y versiones principales fijadas de las acciones.

¿Qué es nuvraxis-plugins?

Este conjunto de habilidades establece las convenciones oficiales de GitHub Actions para aplicaciones Next.js desarrolladas por Nuvraxis. Define exactamente tres flujos de trabajo que deben seguirse al pie de la letra: pr.yaml se ejecuta en cada pull request a cualquier rama y realiza verificaciones de calidad, compilación, construcción de Docker y validación de Helm, sin publicar nada; main.yaml se activa al fusionar en main y construye una imagen multi-arquitectura que se sube a GHCR con las etiquetas sha-SHORTSHA y main, incluyendo proveniencia y SBOM; release.yaml, al etiquetar con vX.Y.Z, verifica que el commit esté en main, retaguea la imagen existente sin reconstruirla, empaqueta y sube el chart de Helm a OCI, y crea un Release de GitHub con el chart, el resumen digital y el SBOM. Cada trabajo tiene permisos mínimos, usa exclusivamente GITHUB_TOKEN, y las acciones están fijadas a su versión mayor. Es útil para desarrolladores que trabajan en repositorios de Nuvraxis, ya que estandariza la integración continua, la construcción de imágenes y el proceso de publicación. Las reglas incluyen el uso de concurrency, timeouts, nombres en minúsculas y la prohibición de exponer secretos. El skill también cubre cómo acelerar builds (por ejemplo, con matrices de runners ARM) y proporciona comandos de verificación con actionlint y GitHub CLI.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Nuvraxis/nuvraxis-plugins/tree/HEAD/plugins/nuvraxis-frontend/skills/github-actions
Ver original→Ver todas las habilidades

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentación

GitHub Actions

Tres flujos de trabajo por aplicación, cada uno con un solo trabajo de su tipo. La plantilla .github/workflows/{pr,main,release}.yaml es la fuente de verdad; se reproducen con notas en references/workflows.md.

pull request ──► pr.yaml       solo verificaciones, nada publicado
merge a main ─► main.yaml     imagen construida una vez → ghcr.io/nuvraxis/<app>:sha-<short>, :main
tag vX.Y.Z ────► release.yaml  misma imagen retagueada :vX.Y.Z, :latest · chart X.Y.Z → OCI · GitHub Release

Reglas para cada flujo de trabajo

  1. permissions: contents: read en la parte superior; ampliar por trabajo solo cuando sea necesario. packages: write para trabajos que suben a GHCR, contents: write solo para el trabajo que crea el Release. No id-token: write ni attestations: write: la proveniencia y el SBOM provienen de BuildKit, no de actions/attest* (que necesita GitHub Enterprise para repositorios privados).

  2. Solo GITHUB_TOKEN. El inicio de sesión en GHCR usa ${{ github.actor }} / ${{ secrets.GITHUB_TOKEN }}; gh usa GH_TOKEN: ${{ github.token }}. Sin tokens de acceso personal en CI. (Extraer paquetes privados desde el clúster es una credencial diferente; consulte helm-nextjs).

  3. Fijar versiones mayores de acciones (@v7) y mantener la tabla de SHA actualizada. La plantilla usa etiquetas principales para legibilidad. Si la organización requiere fijación por SHA, reemplace cada @vN con el SHA de references/action-pins.md y mantenga el comentario # vN.M.P. Versiones mayores actuales: 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. Cadena de herramientas: pnpm/action-setup antes que actions/setup-node. action-setup lee la versión de pnpm desde packageManager; setup-node lee .node-version y almacena en caché el almacén de pnpm (cache: pnpm necesita pnpm en PATH primero). Luego pnpm install --frozen-lockfile. Nunca npm ci.

  5. concurrency por flujo de trabajo y ref; cancelar en curso solo en PRs. Una nueva subida a un PR cancela la ejecución anterior. En main y tags, las ejecuciones siempre terminan: release.yaml necesita la imagen de ese commit exacto.

  6. Nunca hacer eco de secretos ni interpolar entradas no confiables en run:. Pasar valores a través de env: y citarlos ("${APP}"). ${{ github.event.pull_request.title }} y similares nunca van dentro de un script. persist-credentials: false en checkout cuando el trabajo no sube a git.

  7. Cada trabajo tiene timeout-minutes. De lo contrario, una construcción de Docker colgada consume seis horas.

  8. Los nombres están en minúsculas. GHCR rechaza repositorios en mayúsculas. IMAGE: ghcr.io/nuvraxis/<app> se escribe en minúsculas en env; el andamio convierte el nombre de la aplicación a minúsculas.

pr.yaml

  1. on: pull_request con types: [opened, synchronize, reopened, ready_for_review] y sin filtro branches, para que también se verifiquen los PRs apilados contra ramas de características. Cada trabajo tiene if: ${{ !github.event.pull_request.draft }}; marcar como listo activa la ejecución.

  2. Cuatro trabajos en paralelo: quality (biome ci --reporter=github, stylelint, turbo run typecheck test --affected, pnpm audit --audit-level high), build (turbo run build --affected), docker (construir una plataforma con load: true, ejecutarla como solo lectura con capacidades eliminadas, curl /api/health), helm (helm lint --strict y kubeconform en ambos archivos de valores). --affected necesita fetch-depth: 0.

  3. No se sube nada desde un PR. push: false, caché de solo lectura (cache-from solo), sin inicio de sesión en el registro.

main.yaml

  1. on: push: branches: [main] construye la imagen una vez, para ambas arquitecturas, y la sube. Etiquetas de docker/metadata-action: type=sha,format=short,prefix=sha- y type=raw,value=main, flavor: latest=false. latest pertenece a los lanzamientos.

  2. provenance: mode=max, sbom: true, cache-from/to: type=gha,scope=<app>,mode=max. La proveniencia y el SBOM se adjuntan al índice de la imagen; release.yaml los transporta cuando retaguea. NEXT_DEPLOYMENT_ID=${{ github.sha }} es el argumento de compilación para la protección contra sesgos.

  3. main.yaml no publica el chart ni vuelve a ejecutar las comprobaciones del PR. La protección de ramas requiere pr.yaml; main solo produce el artefacto.

release.yaml

  1. on: push: tags: ['v*.*.*'], luego en orden:

    1. Fallar a menos que la etiqueta sea exactamente vMAJOR.MINOR.PATCH y su commit sea un ancestro de origin/main.
    2. No reconstruir. Si ghcr.io/nuvraxis/<app>:sha-<short> no existe, fallar con "deje que main.yaml termine, luego vuelva a ejecutar". Sin construcción de respaldo.
    3. docker buildx imagetools create --tag :vX.Y.Z --tag :latest <sha-image>: una copia a nivel de manifiesto que mantiene ambas arquitecturas, proveniencia y SBOM, en el mismo resumen.
    4. helm package --version X.Y.Z --app-version vX.Y.Z, helm push a oci://ghcr.io/nuvraxis/charts.
    5. gh release create vX.Y.Z --verify-tag --generate-notes con el chart .tgz, image-digest.txt y sbom.spdx.json adjuntos.

  2. El ritual de lanzamiento: fusionar a main → esperar a que main.yaml se ponga verde → git tag vX.Y.Z && git push origin vX.Y.Z. Etiquetar antes de que main.yaml termine provoca que el paso 2 falle a propósito; vuelva a ejecutar el trabajo de lanzamiento una vez que la imagen exista. Un lanzamiento defectuoso se corrige con una nueva etiqueta de parche, nunca moviendo una etiqueta.

Acelerar las cosas (solo cuando sea necesario)

  • arm64 bajo QEMU es la parte lenta de main.yaml. Reemplazar con una matriz en ubuntu-24.04-arm + ubuntu-latest subiendo por resumen, luego un trabajo de fusión con imagetools create. Mantener las etiquetas y el índice único.
  • Caché remota de Turborepo para pr.yaml: consulte pnpm-turborepo.

Verificar

docker run --rm -v "$PWD:/repo" -w /repo rhysd/actionlint:latest     # lint de todos los flujos de trabajo
gh workflow list && gh run list --limit 5
gh run view <run-id> --log-failed

Después de un lanzamiento: docker buildx imagetools inspect ghcr.io/nuvraxis/<app>:vX.Y.Z muestra ambas plataformas, y helm show chart oci://ghcr.io/nuvraxis/charts/<app> --version X.Y.Z muestra appVersion: vX.Y.Z.

Fuentes

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 relacionados

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