Communitygithub.com

Nuvraxis/nuvraxis-plugins

Nuvraxis の Next.js アプリ向け GitHub Actions 規約 — 3 つのワークフロー (pr.yaml, main.yaml, release.yaml) で CI/CD を実現。最小権限、GITHUB_TOKEN のみ、アクションのメジャーピン。

nuvraxis-plugins とは？

このスキルは、Nuvraxis の Next.js アプリケーションにおける GitHub Actions CI/CD パイプラインの厳格な規約を定義します。プルリクエストごとにコード品質、テスト、ビルド、Docker ヘルスチェック、Helm Lint を実行する `pr.yaml`、main ブランチへのマージ時にマルチアーキテクチャイメージをビルドし GHCR にプッシュする `main.yaml`、そしてタグ付きリリース時にイメージを再タグし、Helm チャートを OCI にプッシュ、GitHub Release を作成する `release.yaml` の 3 つのワークフローで構成されます。各ジョブには最小限の権限を付与し、`GITHUB_TOKEN` のみを使用し、アクションはメジャーバージョンでピン留めするという厳格なルールに従います。また、ビルドの再現性とセキュリティのために、プロビナンスと SBOM は BuildKit で生成し、`actions/attest*` は使用しません。このスキルは、ワークフローファイルの編集、CI ステップの追加、実行失敗やリリースの問題のデバッグ時に参照されます。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Nuvraxis/nuvraxis-plugins/tree/HEAD/plugins/nuvraxis-frontend/skills/github-actions
オリジナルを見る→すべてのスキルを見る

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

ドキュメント

GitHub Actions

アプリごとに 3 つのワークフローがあり、それぞれが 1 つのジョブを持ちます。テンプレートの .github/workflows/{pr,main,release}.yaml が信頼できる情報源であり、references/workflows.md に注釈付きで再掲しています。

pull request ──► pr.yaml       チェックのみ、公開なし
merge to main ─► main.yaml     イメージを 1 回ビルド → ghcr.io/nuvraxis/<app>:sha-<short>, :main
tag vX.Y.Z ────► release.yaml  同じイメージを再タグ :vX.Y.Z, :latest · チャート X.Y.Z → OCI · GitHub Release

全ワークフローのルール

  1. 最上部に permissions: contents: read を設定し、必要なジョブでのみ権限を広げる。 GHCR にプッシュするジョブには packages: write、Release を作成するジョブには contents: write。id-token: write や attestations: write は不要: プロビナンスと SBOM は BuildKit から生成し、actions/attest* (プライベートリポジトリでは GitHub Enterprise が必要) は使用しません。

  2. GITHUB_TOKEN のみを使用。 GHCR へのログインは ${{ github.actor }} / ${{ secrets.GITHUB_TOKEN }} を使用し、gh は GH_TOKEN: ${{ github.token }} を使用します。CI で個人アクセストークンは使用しません。(クラスターからプライベートパッケージを取得するための認証情報は別途必要です。helm-nextjs を参照。)

  3. アクションのメジャーバージョンをピン留め (@v7) し、SHA テーブルを最新に保つ。 テンプレートでは可読性のためにメジャータグを使用しています。組織で SHA ピン留めが必要な場合は、各 @vN を references/action-pins.md の SHA に置き換え、# vN.M.P コメントを残してください。現在のメジャーバージョン: 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. ツールチェーン: pnpm/action-setup は actions/setup-node の前に配置。 action-setup は packageManager から pnpm バージョンを読み取り、setup-node は .node-version を読み取り pnpm ストアをキャッシュします (cache: pnpm は PATH に pnpm が必要)。その後 pnpm install --frozen-lockfile を実行。npm ci は使用しません。

  5. ワークフローと参照 (ref) ごとに concurrency を設定し、PR の進行中の実行はキャンセルする。 PR への新しいプッシュは古い実行をキャンセルします。main とタグの実行は常に完了させます: release.yaml はそのコミットの正確なイメージを必要とします。

  6. シークレットをエコーしたり、信頼できない入力を run: に展開したりしない。 値は env: を介して渡し、引用符で囲みます ("${APP}")。${{ github.event.pull_request.title }} などはスクリプト内に記述しません。ジョブが git にプッシュしない場合は、checkout で persist-credentials: false を設定します。

  7. 全てのジョブに timeout-minutes を設定する。 設定しないと、Docker ビルドがハングした場合に 6 時間も消費する可能性があります。

  8. 名前は小文字にする。 GHCR は大文字のリポジトリを拒否します。IMAGE: ghcr.io/nuvraxis/<app> は env 内で小文字で記述します。スキャフォールドはアプリ名を小文字に変換します。

pr.yaml

  1. on: pull_request に types: [opened, synchronize, reopened, ready_for_review] を指定し、branches フィルターは設定しない。 これにより、フィーチャーブランチに対する積み上げ PR もチェックされます。全てのジョブに if: ${{ !github.event.pull_request.draft }} を設定し、準備完了にマークすると実行がトリガーされます。

  2. 4 つの並列ジョブ: quality (biome ci --reporter=github、stylelint、turbo run typecheck test --affected、pnpm audit --audit-level high)、build (turbo run build --affected)、docker (1 つのプラットフォームを load: true でビルド、ケーパビリティを落として読み取り専用で実行、/api/health を curl)、helm (helm lint --strict と両方の values ファイルに対する kubeconform)。--affected を使用するには fetch-depth: 0 が必要です。

  3. PR からは何もプッシュしない。 push: false、キャッシュは読み取り専用 (cache-from のみ)、レジストリへのログインは行いません。

main.yaml

  1. on: push: branches: [main] でイメージを 1 回ビルドし、両方のアーキテクチャに対応してプッシュする。 docker/metadata-action からのタグ: type=sha,format=short,prefix=sha- と type=raw,value=main、flavor: latest=false。latest はリリース用です。

  2. provenance: mode=max、sbom: true、cache-from/to: type=gha,scope=<app>,mode=max。 プロビナンスと SBOM はイメージインデックスに添付され、release.yaml で再タグする際に引き継がれます。NEXT_DEPLOYMENT_ID=${{ github.sha }} はスキュー防止用のビルド引数です。

  3. main.yaml はチャートを公開せず、PR チェックを再実行しない。 ブランチ保護は pr.yaml を要求します。main はアーティファクトのみを生成します。

release.yaml

  1. on: push: tags: ['v*.*.*']、その後順に:

    1. タグが正確に vMAJOR.MINOR.PATCH であり、そのコミットが origin/main の祖先であることを確認し、そうでない場合は失敗させる。
    2. 再ビルドはしない。 ghcr.io/nuvraxis/<app>:sha-<short> が存在しない場合は、「main.yaml を完了させてから再実行してください」というメッセージで失敗させる。フォールバックビルドは行いません。
    3. docker buildx imagetools create --tag :vX.Y.Z --tag :latest <sha-image>: マニフェストレベルのコピーで、両方のアーキテクチャ、プロビナンス、SBOM を同じダイジェストで保持します。
    4. helm package --version X.Y.Z --app-version vX.Y.Z、helm push を oci://ghcr.io/nuvraxis/charts に実行。
    5. チャート .tgz、image-digest.txt、sbom.spdx.json を添付して gh release create vX.Y.Z --verify-tag --generate-notes を実行。

  2. リリースの儀式: main にマージ → main.yaml がグリーンになるのを待つ → git tag vX.Y.Z && git push origin vX.Y.Z。main.yaml が完了する前にタグ付けすると、ステップ 2 が意図的に失敗します。イメージが存在するようになったらリリースジョブを再実行してください。不良リリースは新しいパッチタグで修正し、タグを移動することは決して行いません。

高速化 (必要な場合のみ)

  • arm64 の QEMU は main.yaml の低速部分です。代わりに ubuntu-24.04-arm + ubuntu-latest のマトリックスを使用してダイジェストでプッシュし、その後にマージジョブで imagetools create を実行します。タグと単一インデックスは維持します。
  • pr.yaml の Turborepo リモートキャッシュ: pnpm-turborepo を参照。

検証

docker run --rm -v "$PWD:/repo" -w /repo rhysd/actionlint:latest     # 全ワークフローを lint
gh workflow list && gh run list --limit 5
gh run view <run-id> --log-failed

リリース後: docker buildx imagetools inspect ghcr.io/nuvraxis/<app>:vX.Y.Z で両方のプラットフォームが表示され、helm show chart oci://ghcr.io/nuvraxis/charts/<app> --version X.Y.Z で appVersion: vX.Y.Z が表示されます。

参考資料

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.

関連スキル

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