release-please-standards

Release-Please の標準

このスキルを使用する場合

次の場合にこのスキルを使用します…	次の場合は代わりにこちらを使用します…
canonical な release-please のワークフロー、マニフェスト、設定ファイルの形式が必要な場合	対話形式のワークフローとして release-please をエンドツーエンドで監査またはセットアップしたい場合 — configure-release-please を使用してください
既存の release-please セットアップを、文書化された規約に照らして確認する場合	変更前にリポジトリの種類と既存の設定を実行時に検出したい場合 — configure-release-please を使用してください
別のスキルで標準の release-please 設定を参照する必要がある場合	monorepo のコンポーネントタグ、パッケージごとの extra-files、または shared から component へのタグ移行を設定する場合 — git-plugin:release-please-configuration を使用してください

バージョン：2025.1

自動セマンティックバージョニングと変更履歴の生成に使用する、標準の release-please 設定です。

標準設定

GitHub Actions ワークフロー

ファイル：.github/workflows/release-please.yml

リリース PR には、ほかのワークフローをトリガーできるトークンが必要です。方法は 2 つあります。 GitHub App トークンを推奨（laurigates 組織の標準）し、 MY_RELEASE_PLEASE_TOKEN PAT は従来の代替手段として維持します。

GitHub App トークン（推奨） — create-github-app-token は、 RELEASE_PLEASE_APP_ID（変数）と RELEASE_PLEASE_PRIVATE_KEY（シークレット）から トークンを生成します。これらは gitops により release_please = true が設定されたリポジトリにプロビジョニングされます。

name: Release Please

on:
  push:
    branches:
      - main

permissions:
  contents: write
  pull-requests: write

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/create-github-app-token@v3
        id: app-token
        with:
          app-id: ${{ vars.RELEASE_PLEASE_APP_ID }}
          private-key: ${{ secrets.RELEASE_PLEASE_PRIVATE_KEY }}
      - uses: googleapis/release-please-action@v4
        with:
          token: ${{ steps.app-token.outputs.token }}

PAT（従来の方式） — リポジトリの設定にある MY_RELEASE_PLEASE_TOKEN シークレットを使用します。

      - uses: googleapis/release-please-action@v5
        with:
          token: ${{ secrets.MY_RELEASE_PLEASE_TOKEN }}

設定ファイル

ファイル：release-please-config.json

{
  "packages": {
    ".": {
      "release-type": "node",
      "changelog-sections": [
        {"type": "feat", "section": "Features"},
        {"type": "fix", "section": "Bug Fixes"},
        {"type": "perf", "section": "Performance"},
        {"type": "deps", "section": "Dependencies"},
        {"type": "docs", "section": "Documentation", "hidden": true},
        {"type": "chore", "section": "Miscellaneous", "hidden": true}
      ]
    }
  },
  "plugins": ["node-workspace"]
}

ファイル：.release-please-manifest.json

{
  ".": "0.0.0"
}

注：バージョン 0.0.0 はプレースホルダーです。release-please によって自動的に更新されます。

プロジェクトの種類ごとのバリエーション

Node.js フロントエンド／バックエンド

• release-type：node
• プラグイン：node-workspace
• 更新対象：package.json のバージョンフィールド

Python サービス

• release-type：python
• 更新対象：pyproject.toml のバージョンフィールド、およびコード内の __version__

インフラストラクチャ（Helm）

• release-type：helm
• 更新対象：Chart.yaml のバージョンフィールド

マルチパッケージリポジトリ

モノレポでは、すべてのパッケージに component を設定し、ルートで include-component-in-tag: true を設定する必要があります。また、パッケージごとの extra-files と、必要に応じて linked-versions プラグインも設定します。

{
  "packages": {
    "packages/frontend": {"release-type": "node", "component": "frontend"},
    "packages/backend": {"release-type": "node", "component": "backend"}
  },
  "plugins": ["node-workspace"]
}

モノレポの全体的な戦略（コンポーネントタグ、重複タグ／複数パスの修正、パッケージごとの extra-files のパスルール、リンクされたバージョン、パッケージの追加、shared から component へのタグ移行）については、git-plugin:release-please-configuration を参照してください。

必須コンポーネント

最低要件

1. ワークフローファイル：.github/workflows/release-please.yml

   • googleapis/release-please-action@v5 を使用
   • トークン：GitHub App トークン（推奨）または MY_RELEASE_PLEASE_TOKEN シークレット
   • main への push でトリガー

2. 設定ファイル：release-please-config.json

   • プロジェクトに適した有効な release-type
   • changelog-sections を定義

3. マニフェストファイル：.release-please-manifest.json

   • すべてのパッケージと現在のバージョンを一覧表示

トークンの設定

ワークフローでは、GITHUB_TOKEN ではなく、専用のリリーストークンを使用します。理由は次のとおりです。

• リリース PR からほかのワークフローをトリガーできる
• リリース PR で CI チェックを実行できる
• 適切な監査証跡を維持できる

次の 2 つのトークン方式が使用できます。

方式	方法	使用する場合
GitHub App トークン（推奨）	actions/create-github-app-token → app-id: ${{ vars.RELEASE_PLEASE_APP_ID }}、private-key: ${{ secrets.RELEASE_PLEASE_PRIVATE_KEY }} を指定し、token: ${{ steps.app-token.outputs.token }} として渡します	laurigates 組織の標準 — 認証情報は release_please = true が設定されたリポジトリに gitops によってプロビジョニングされます
PAT（従来の方式）	token: ${{ secrets.MY_RELEASE_PLEASE_TOKEN }}	GitHub App が設定されていない場合

すでに App トークン方式を使用しているワークフローは準拠しています。 MY_RELEASE_PLEASE_TOKEN に切り替えるよう指摘しないでください。

準拠状況の確認

ステータスレベル

ステータス	条件
PASS	3 つすべてのファイルが存在し、有効な設定になっている
WARN	ファイルは存在するが、非推奨のアクションバージョン（v5 より前）を使用している
FAIL	必須ファイルが不足しているか、設定が無効である

検証ルール

1. ワークフローの検証：

   • アクションバージョン：v5（古い場合は警告）
   • トークン：ハードコードせず、シークレットを使用すること
   • トリガー：main への push を含めること

2. 設定の検証：

   • release-type：有効な値（node、python、helm、simple）であること
   • changelog-sections：feat と fix を含めること

3. マニフェストの検証：

   • 有効な JSON であること
   • パッケージが設定と一致すること

保護対象ファイル

重要：Release-please は次のファイルを自動的に管理します。

• CHANGELOG.md - 手動で編集しないでください
• package.json、pyproject.toml、Chart.yaml のバージョンフィールド
• .release-please-manifest.json - 初期設定時のみ編集してください

適用については release-please-protection スキルを参照してください。

Conventional Commits

Release-please では、Conventional Commits に準拠したコミットメッセージが必要です。

プレフィックス	リリースタイプ	例
feat:	マイナー	feat: add user authentication
fix:	パッチ	fix: correct login timeout
feat!:	メジャー	feat!: redesign API
BREAKING CHANGE:	メジャー	コミット本文に記載

インストール

1. ワークフローファイルを作成する
2. 設定ファイルを作成する
3. マニフェストファイルを作成する
4. リリーストークンを設定する — 推奨：RELEASE_PLEASE_APP_ID 変数と RELEASE_PLEASE_PRIVATE_KEY シークレットを設定する（gitops は release_please = true のリポジトリにこれらをプロビジョニングします）。従来の方法：リポジトリのシークレットに MY_RELEASE_PLEASE_TOKEN を追加する
5. pre-commit に conventional-pre-commit フックが設定されていることを確認する

トラブルシューティング

リリース PR が作成されない

• Conventional Commits の形式を確認する
• ワークフローに適切な権限が設定されていることを確認する
• トークンに書き込みアクセス権があることを確認する

バージョンが更新されない

• マニフェストファイルが有効な JSON であることを確認する
• release-type がプロジェクトと一致していることを確認する
• Actions の release-please ログを確認する

リリース PR で CI が実行されない

• GITHUB_TOKEN ではなく、専用のリリーストークン（GitHub App トークンまたは PAT）を使用する必要があります
• ワークフローのトリガーに pull_request が含まれていることを確認する