Astro GitHub Actions は何をしますか？

このスキルは、GitHub Actionsを使用してAstroサイト向けの包括的なCI/CDパイプラインをセットアップするのに役立ちます。目標は、作成者が手間を減らしてより高品質なサイトをリリースできるようにすることです。マージ前に型エラーを検出し、リンク切れをフラグし、ビルドを検証し、デプロイを自動化します。

このスキルがカバーするもの

健全なAstroプロジェクトに必要となる可能性のあるワークフローは、いくつかのカテゴリに分かれます。すべてのサイトにすべてが必要なわけではなく、適切な組み合わせはプロジェクトにTypeScriptがあるか、カスタムコンポーネント、コンテンツコレクション、テスト、そしてどこにデプロイするかによって異なります。あなたの仕事は、どのワークフローが関連するかを見極め、それらをセットアップすることです。

ワークフローは以下のカテゴリに分類されます:

型・コンテンツチェック — astro check (TypeScript + コンテンツコレクションスキーマのバリデーション)
コード品質 — ESLint と Prettier
ビルド検証 — astro build が正常に動作することの確認
テスト — ユニットテストとコンポーネントテスト用の Vitest
品質ゲート — Lighthouse CI (パフォーマンス、アクセシビリティ、SEO、ベストプラクティス)
リンクチェック — ビルド済みサイトのリンク切れ検出
セキュリティ — 依存関係の脆弱性チェックのための npm audit
デプロイ — GitHub Pages、Cloudflare Pages、Netlify、Vercel

各ワークフローの詳細な設定（すぐに使えるYAMLテンプレートや設定ファイルを含む）については、references/workflows.md を参照してください。

リクエストへのアプローチ方法

ステップ1: プロジェクトを理解する

ワークフローファイルを作成する前に、何を扱っているかを把握します:

TypeScriptを使用しているか？ tsconfig.json および .ts/.astro ファイルを確認します。ほとんどのAstroプロジェクトで astro check を実行すべきですが、.astro のフロントマター、コンテンツコレクションスキーマ、または src/ でTypeScriptが使われている場合に特に価値が高まります。
コンテンツコレクションを使用しているか？ src/content/config.ts または src/content.config.ts を確認します。使用している場合、astro check でスキーマが検証されるため、特に価値があります。
テストはあるか？ tests/、__tests__/、*.test.ts、または vitest.config.ts を確認します。ある場合はVitestワークフローをセットアップします。ない場合は、テストを追加することが有益であることに言及しますが、強制はしません。
パッケージマネージャーは？ pnpm-lock.yaml、yarn.lock、package-lock.json を探します。ワークフローのインストールコマンドを合わせます（pnpm i --frozen-lockfile、yarn install --frozen-lockfile、npm ci）。
どこにデプロイするか？ wrangler.toml（Cloudflare）、netlify.toml（Netlify）、vercel.json（Vercel）を探すか、単に尋ねます。ほとんどのホストはActionsを使わずに自動デプロイする独自のGitHubアプリを持っています—ユーザーが実際にActionsで処理したい場合にのみデプロイワークフローをセットアップします（通常はGitHub Pagesまたはセルフホスティング）。
ビルドステップはあるか？ Astroは常にあります（astro build）—ただし、package.json のスクリプトが標準の astro build であり、カスタムのものでないことを確認します。
SSRか静的か？ astro.config.* で output: 'server' またはアダプターのインポートを確認します。SSRプロジェクトはデプロイ方法が異なり（Cloudflare/Netlify/Vercelアダプター）、GitHub Pagesにデプロイできない場合があります。

ステップ2: ワークフローのセットを推奨する

見つけた内容に基づいて、セットアップするワークフローを推奨します。ほとんどのAstroサイトに適したデフォルトは以下の通りです:

astro check（ほぼ常に—これはAstroにとって最も価値のあるチェックです）
ビルド検証（ほぼ常に—astro check が見逃す可能性のある統合リグレッションをキャッチします）
ESLint + Prettier（設定ファイルが存在するか、ユーザーが希望する場合）
Lighthouse CI（公開URLがあるコンテンツサイトに最適）
リンクチェッカー（コンテンツが多いサイトに最適）
npm audit（コストが低く、ほぼ常に価値があります）

そして条件付きで:

Vitestテスト（テストが存在する場合）
デプロイワークフロー（ユーザーがActions駆動のデプロイを希望する場合のみ—ほとんどのAstroホストは独自のGitHubアプリを使用します）

ステップ3: ワークフローファイルを作成する

各ワークフローを .github/workflows/ 内の個別のYAMLファイルとして作成します。単一のモノリシックワークフローではなく個別のファイルを使用することで、PRでのフィードバックが明確になり（各チェックが独立して表示される）、個々のチェックの有効化/無効化が容易になります。

テンプレートとして references/workflows.md のものを出発点として使用しますが、特定のプロジェクトに合わせて適応させます。一般的な適応には、パッケージマネージャー、Nodeバージョン、ビルドアーティファクトのパス、デプロイターゲットの調整が含まれます。

ステップ4: サポート設定ファイルを作成する

セットアップするワークフローに応じて、以下の設定ファイルも必要になる場合があります:

eslint.config.js — eslint-plugin-astro を使用したESLintフラット設定
.prettierrc および .prettierignore — prettier-plugin-astro を使用したPrettier設定
lighthouserc.json — Lighthouse CIアサーション
lychee.toml — リンクチェッカー設定（lychee使用時）
vitest.config.ts — Vitest設定

ステップ5: シークレットのリマインダーを設定する

デプロイワークフローを追加する場合は、必要なリポジトリシークレットをユーザーにリマインドします:

GitHub Pages — なし（GITHUB_TOKEN を使用）
Cloudflare Pages — CLOUDFLARE_API_TOKEN、CLOUDFLARE_ACCOUNT_ID
Netlify — NETLIFY_AUTH_TOKEN、NETLIFY_SITE_ID
Vercel — VERCEL_TOKEN、VERCEL_ORG_ID、VERCEL_PROJECT_ID

手順を案内します: リポジトリ設定 > Secrets and variables > Actions > New repository secret。

Cloudflare、Netlify、Vercelについては、それらのプラットフォームがビルド、デプロイ、PRプレビューを自動的に処理する独自のGitHubアプリを提供していることもリマインドします。Actionベースのデプロイは通常、テスト結果に基づいてデプロイを制御する必要がある場合、プラットフォームが持っていないシークレットを使ってビルドを実行する場合、またはリポジトリルート以外のパスからデプロイする場合にのみ価値があります。

命名規則

各ワークフローの機能が一目でわかる、説明的なワークフローファイル名を使用します:

astro-check.yml — astro check（型 + コンテンツスキーマ）
lint.yml — ESLint
format.yml — Prettierチェック
build.yml — ビルド検証
test.yml — Vitest
lighthouse.yml — Lighthouse CI
links.yml — リンク切れチェッカー
security.yml — npm audit
deploy.yml — ホストへのデプロイ

重要な詳細

Node.jsバージョン: AstroはNode 18.20.8+、20.3.0+、または22.0.0+が必要です。デフォルトではNode 22を使用します—これはAstroの安定ターゲットと一致し、多くのアダプターがこれに対してテストされています。actions/checkout@v5 と actions/setup-node@v5 を使用します。

パッケージマネージャーの検出: 常にロックファイルに合わせます。pnpm-lock.yaml → pnpm/action-setup@v4 と pnpm install --frozen-lockfile を使用。yarn.lock → yarn install --frozen-lockfile。package-lock.json → npm ci。CIで npm install は使用しないでください（非決定論的で遅い）。

ブランチ名: ほとんどのAstroリポジトリはデフォルトブランチとして main を使用しますが、トリガーを記述する前に実際のリポジトリを確認してください。

AstroアダプターとSSR: プロジェクトが @astrojs/cloudflare、@astrojs/netlify、または @astrojs/vercel を使用している場合、ビルド出力は静的な dist/ ディレクトリではない可能性があります。Cloudflareアダプターは dist/ と _worker.js を出力します。Vercelは .vercel/output/ を出力します。Netlifyは .netlify/ を出力します。デプロイアーティファクトのパスを適宜調整します。

astro check には @astrojs/check と typescript が必要: 両方がインストールされている必要があります。devDependencies にない場合、ワークフローは失敗します。package.json に既に存在する場合のみ、npm ci の一部として追加します—そうでなければ、ワークフローで明示的にインストールする必要があります。

PRへのLighthouse CI: すべてのPRでLighthouseを実行すると、パフォーマンスのリグレッションを早期に検出できます。treosh/lighthouse-ci-action が標準です。公開プレビューURL（Cloudflare Pages、Netlify、Vercel）の場合は、LighthouseをデプロイプレビューURLに向けます—これにより現実的な数値が得られます。内部のみのセットアップの場合は、ランナー内でビルドしてローカルで提供します。

ソースではなくビルド出力に対してリンクチェックを実行: リンクチェッカーはビルドされた dist/ ディレクトリ（またはデプロイ済みプレビューURL）に対して実行します—Markdownソースに対して実行すると、生成されたルートやサイトマップリンクを見逃します。

ActionデプロイよりもプラットフォームのGitHubアプリを推奨: Cloudflare Pages、Netlify、Vercelはすべて、手動で作成したActionよりもPRプレビュー、ブランチデプロイ、ロールバックをより適切に処理するファーストパーティのGitHubアプリを持っています。最初にGitHubアプリを推奨し、ユーザーがその方法で行う特定の理由がある場合にのみActionデプロイを提案します。

Astro GitHub Actions