deploy-site ワークフロー: 手動実行の分岐と fork PR の安全化

[nuitsjp]

対象

• .github/workflows/deploy-site.yml

目的

• 手動実行（workflow_dispatch）時のデプロイ事故を防止する。
• fork PR で AZURE_SWA_API_TOKEN が使えないケースでも、CI を失敗させずにビルド検証を継続する。

改善案（どう修正するか / 理由）

1) workflow_dispatch の入力で挙動を明確化

• 修正: workflow_dispatch.inputs.target（例: preview / production）を追加する。
  • preview（デフォルト）: ビルドのみ（SWA/Pages へデプロイしない）
  • production: main 前提で Web/PDF ビルド + SWA デプロイ + Pages デプロイ
• 理由: 手動実行で「プレビュー相当の成果物」をSWA本番へデプロイしてしまう事故や、SWA/Pages の不整合を防ぐため。

2) SWA デプロイを同一リポジトリPRに限定（forkはスキップ）

• 修正: Azure Static Web Apps へデプロイ ステップに条件を追加する。
  • 例: github.event_name == 'push' && github.ref == 'refs/heads/main' || (github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository)
• 理由: fork PR では secrets.AZURE_SWA_API_TOKEN が渡らず失敗しやすいので、ビルドは回しつつデプロイのみ安全にスキップするため。

3) 重い依存導入を必要時のみに限定（任意）

• 修正: Mermaid CLI / Playwright のインストールを、変換やPDF生成が有効なケース（本番相当）にだけ実行する。
• 理由: PRプレビューは変換を走らせない設計のため、時間短縮と失敗点削減になる。

4) concurrency で PR の古い実行をキャンセル（任意）

• 修正: 同一PRの synchronize 連発時に古い実行を cancel する。
• 理由: 無駄なビルド/デプロイと競合を抑えるため。

受け入れ条件

• workflow_dispatch（デフォルト）でデプロイが発生しない。
• workflow_dispatch の production 選択で、main から SWA と Pages の両方が更新される。
• fork PR では SWA デプロイがスキップされ、CI は失敗しない（ビルドは実施）。
• 同一リポジトリ内 PR では従来どおり SWA のプレビューが動作する。

補足: アクションのバージョン固定はタグ指定のままで OK とする。