Skip to content

feat: pre-production/production ブランチ対応と strict 保護レベル追加 - #566

Merged
keito4 merged 2 commits into
mainfrom
feat/add-environment-branches
Mar 13, 2026
Merged

feat: pre-production/production ブランチ対応と strict 保護レベル追加#566
keito4 merged 2 commits into
mainfrom
feat/add-environment-branches

Conversation

@keito4

@keito4 keito4 commented Mar 13, 2026

Copy link
Copy Markdown
Owner

Summary

  • setup-team-protection.sh--protection-level strict オプションを追加(最厳格なブランチ保護設定)
  • CI/Security/Docker ワークフローのトリガー対象に pre-production, production ブランチを追加
  • コマンドドキュメントに保護レベルと環境ブランチの使用例を追記

--protection-level strict で適用される設定

設定
必須レビュアー数 2名以上
管理者にも適用 enforce_admins: true
リニア履歴必須 required_linear_history: true
最終プッシュ承認必須 require_last_push_approval: true
会話解決必須 required_conversation_resolution: true
署名付きコミット必須 required_signatures: true

使い方

bash script/setup-team-protection.sh \
  --branches main,pre-production,production \
  --create-branches \
  --protection-level strict

Test plan

  • --dry-run で strict レベルの設定内容を確認
  • --protection-level standard で既存動作に影響がないことを確認
  • --protection-level strict --create-branches でブランチ作成・保護が適用されることを確認
  • CI ワークフローが pre-production/production ブランチでトリガーされることを確認

🤖 Generated with Claude Code

Summary by CodeRabbit

  • New Features

    • Added configurable branch protection levels (standard and strict modes) with distinct reviewer requirements and enforcement policies.
    • Extended CI and security workflow triggers to include pre-production and production branches alongside main and master.
  • Documentation

    • Updated branch protection setup guidance with comprehensive examples and new configuration scenarios.

環境ブランチ(pre-production, production)の作成・保護に対応するため、
setup-team-protection.sh に --protection-level strict オプションを追加し、
CI ワークフローのトリガー対象ブランチも拡張した。

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Mar 13, 2026

Copy link
Copy Markdown

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: bb97ba35-cd4d-48e5-8f8f-80219d086a34

📥 Commits

Reviewing files that changed from the base of the PR and between e28c65c and 5bd7aa2.

📒 Files selected for processing (2)
  • .github/workflows/ci.yml
  • script/setup-team-protection.sh

📝 Walkthrough

Walkthrough

This PR extends branch protection configuration and CI/security workflows to cover additional branches (pre-production and production) alongside main, while introducing a new protection level feature with strict mode that enforces additional security requirements like signed commits and stricter reviewer policies.

Changes

Cohort / File(s) Summary
Documentation Updates
.claude/commands/repo-maintenance.md
Japanese table formatting and alignment adjustments; typography improvements without logic changes.
Protection Configuration Guidance
.claude/commands/setup-team-protection.md
Added guidance for strict vs. standard protection levels, branch-specific protection scenarios, and updated examples for main, develop, pre-production, and production branches.
Workflow Branch Expansion
.github/workflows/ci.yml, .github/workflows/container-security.yml, .github/workflows/security.yml
Extended push and pull_request triggers to include pre-production and production branches alongside main/master.
Protection Script Implementation
script/setup-team-protection.sh
Introduced --protection-level argument with standard/strict modes; strict mode enforces 2+ reviewers, admin enforcement, linear history, signed commits, and conversation resolution; added GitHub API call for signed-commit requirements.

Sequence Diagram(s)

sequenceDiagram
    actor User
    participant Script as setup-team-protection.sh
    participant GitHubAPI as GitHub API
    participant Repo as Repository
    
    User->>Script: Run with --protection-level strict
    Script->>Script: Parse protection level argument
    Script->>Script: Set variables (reviewers=2,<br/>enforce_admins=true,<br/>require_signed_commits=true, ...)
    Script->>Script: Display protection level in confirmation
    User->>Script: Confirm setup
    Script->>GitHubAPI: POST branch protection config<br/>(require_signed_commits field)
    GitHubAPI->>Repo: Apply standard protection
    GitHubAPI-->>Script: Success response
    Script->>GitHubAPI: POST required_signatures endpoint<br/>(enforce signed commits)
    GitHubAPI->>Repo: Enable signed commit requirement
    GitHubAPI-->>Script: Success/warning response
    Script-->>User: Display final protection status
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

Poem

🐰 Branches bundled, shields fortified,
Strict protection far and wide,
Signatures signed, reviewers plenty,
Production safe, security's bounty!

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly describes the main changes: adding pre-production/production branch support and introducing strict protection level feature, which aligns with the substantial modifications across documentation, workflows, and scripts.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
  • 📝 Generate docstrings (stacked PR)
  • 📝 Generate docstrings (commit on current branch)
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch feat/add-environment-branches
📝 Coding Plan
  • Generate coding plan for human review comments

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@keito4

keito4 commented Mar 13, 2026

Copy link
Copy Markdown
Owner Author

🔍 AI Code Review (Local Hook)

Models: Codex (default) / Gemini (default)

🤖 Codex Review

指摘事項はありません。変更はドキュメント整形、ワークフローの対象ブランチ拡張、ブランチ保護スクリプトの保護レベル追加で、いずれも整合しています。新規パラメータやAPI呼び出しの構造も既存の保護設定フローに自然に組み込まれており、重大なリグレッションは見当たりません。

判定: patch is correct
理由: 変更は主に設定追加とドキュメント更新であり、既存ロジックと矛盾せず、保護設定も整合しているため。
信頼度: 0.62

✨ Gemini Review

MCP server 'supabase' requires authentication using: /mcp auth supabaseMCP server 'vercel' requires authentication using: /mcp auth vercelご提示いただいたGit Diffのレビュー結果を報告します。

レビュー結果

1. GitHub API リクエストボディのデータ型不整合

ファイル: script/setup-team-protection.sh
行範囲: 240-244行目 (および 211-212行目の既存部分)
説明: GitHub REST API の Update branch protection エンドポイントにおいて、required_linear_history, required_conversation_resolution, allow_force_pushes, allow_deletionsboolean 値 (true/false) として直接指定する必要があります。
現在の実装のように {"enabled": true} というオブジェクト形式で送信すると、API は 422 Unprocessable Entity を返します(このオブジェクト形式は GET レスポンスの形式であり、PUT リクエストの仕様とは異なります)。一方で、229行目の require_last_push_approval は正しく boolean として構築されており、実装内で不整合が生じています。

2. CIワークフローのトリガー設定の不足(一貫性の欠如)

ファイル: .github/workflows/ci.yml
行範囲: 17行目付近
説明: security.ymlcontainer-security.yml では pull_request トリガーの対象ブランチに pre-productionproduction が追加されていますが、ci.yml では push トリガーのみに追加され、pull_request 側が [main, master] のままになっています。これらのブランチをターゲットとしたPRに対してもテストを実行する必要がある場合、設定漏れとなります。

3. JSON 構築方法の堅牢性

ファイル: script/setup-team-protection.sh
行範囲: 181-245行目
説明: Bash での文字列連結による JSON 構築は、引用符のエスケープや型の扱いでミスが発生しやすく、保守性が低いです。
今回のデータ型不整合の問題を避けるためにも、jq を使用して jq -n --argjson ... のように安全に JSON を生成することを推奨します。


判定: patch is incorrect

理由: script/setup-team-protection.sh で構築されている JSON ペイロードのデータ型が GitHub API の仕様と合致しておらず、ブランチ保護設定の適用に失敗するため。また、ワークフロー間でのブランチトリガー設定に不整合があるため。

信頼度: 0.95


⚠️ 修正が必要です

上記のレビューで問題が指摘されています。修正してからマージしてください。


🤖 Generated by post_pr_ai_review.py hook

@keito4

keito4 commented Mar 13, 2026

Copy link
Copy Markdown
Owner Author

🔍 AI Code Review (Local Hook)

Models: Codex (default) / Gemini (default)

🤖 Codex Review

指摘事項なし。

全体判定: patch is correct。理由: 変更はワークフローの対象ブランチ拡張とスクリプトの保護レベル機能追加・ドキュメント整形であり、正確性/性能/セキュリティ/保守性/開発者体験に影響する新規の問題は見当たりませんでした。信頼度: 0.61

✨ Gemini Review

MCP server 'supabase' requires authentication using: /mcp auth supabaseMCP server 'vercel' requires authentication using: /mcp auth vercelご提示いただいたGit diffのレビュー結果を報告します。

指摘事項

  1. GitHub API スキーマの不整合

    • ファイル: script/setup-team-protection.sh
    • 行範囲: 241-244行目
    • 説明: allow_force_pushes, allow_deletions, required_linear_history、および新設の required_conversation_resolution は、GitHub REST API (PUT /protection) において、オブジェクト形式 {"enabled": ...} ではなく boolean値 として定義されています。
    • 影響: 設定が無視されるか、APIが422エラーを返す可能性があります(既存のコードからの踏襲と思われますが、新機能が動作しないリスクがあります)。
    • 対策: \"required_linear_history\":$require_linear_history のように直接値を渡す形式に修正してください。
  2. CI ワークフローのトリガー不足

    • ファイル: .github/workflows/ci.yml
    • 行範囲: 17行目付近(pull_request トリガー)
    • 説明: push トリガーには pre-production, production が追加されていますが、pull_request トリガー(diffのコンテキスト部分)にはこれらのブランチが含まれていないようです。
    • 影響: pre-productionproduction ブランチに向けたPull Requestに対してCIが実行されず、マージ前に安全性を確認できません。
    • 対策: pull_request.branches にも同様にブランチを追加してください。
  3. JSON 構文の型安全性(軽微)

    • ファイル: script/setup-team-protection.sh
    • 行範囲: 228行目
    • 説明: require_last_push_approval も boolean 値です。シェル変数が true/false 文字列であれば動作しますが、JSON生成時に型を意識した実装(引用符の有無など)を徹底することを推奨します。
  4. ドキュメントのノイズ

    • ファイル: .claude/commands/repo-maintenance.md
    • 説明: 大量のテーブル列の空白調整が含まれており、実質的な変更(コスト最適化項目の更新)の確認を妨げています。
    • 対策: フォーマット調整とロジック変更はコミットを分けるのが望ましいです。

判定: patch is incorrect
理由: strict レベルで導入された主要なプロテクション項目(線形履歴、会話の解決)のAPIパラメータ形式が誤っている可能性が高く、機能が正しく動作しない恐れがあるためです。また、CIのPRトリガー漏れもリリースプロセスの安全性に影響します。

信頼度スコア: 0.92


⚠️ 修正が必要です

上記のレビューで問題が指摘されています。修正してからマージしてください。


🤖 Generated by post_pr_ai_review.py hook

@claude

claude Bot commented Mar 13, 2026

Copy link
Copy Markdown
Contributor

コードレビュー

全体的に有用な機能追加ですが、いくつか注意すべき点があります。


🔴 重大な懸念

docker-image.yml への pre-production/production 追加

# .github/workflows/docker-image.yml
branches: [main, pre-production, production]  # ← 追加

docker-image.yml は semantic-release でバージョン付きDockerイメージを ビルド&リリース するワークフローです。pre-production/production ブランチへのpushでもリリースが走ることになり、以下のリスクがあります:

  • pre-production ブランチからの push が意図せず新しいバージョンタグを作成する可能性
  • main 以外のブランチから latest タグが上書きされる可能性
  • semantic-release の設定で main ブランチのみを release channel として認識している場合、ビルドは成功してもリリースは行われず、無駄なCIコストが発生

提案: docker-image.ymlmain のみを対象に維持し、CI/Security系のワークフローのみ pre-production/production に拡張することを推奨します。


🟡 中程度の懸念

--protection-level の入力バリデーション欠如

# script/setup-team-protection.sh
PROTECTION_LEVEL="standard"
# ...
if [[ "$PROTECTION_LEVEL" == "strict" ]]; then
  # strict処理
fi
# standard以外の無効な値を渡すとサイレントにstandardとして動作

無効な値(例: --protection-level invalid)を渡してもエラーにならずサイレントに standard として動作します。

提案:

case "$PROTECTION_LEVEL" in
  standard|strict) ;;
  *) error "Invalid protection level: $PROTECTION_LEVEL. Use 'standard' or 'strict'."; exit 1 ;;
esac

Dry-run で strict の実際の設定値が表示されない

--dry-run 実行時のインタラクティブ確認では $REVIEWERS$ENFORCE_ADMINS(元の値)が表示されますが、strict モードで上書きされる値(reviewers=2, enforce_admins=true等)は表示されません。ユーザーが「何が適用されるか」を確認できません。

提案: setup_branch_protection() 内の計算後にdry-run出力を追加するか、事前に presets を表示する。


🟠 技術的な注意点

GitHub API の非推奨ヘッダー

-H "Accept: application/vnd.github.zzzax-preview+json"

zzzax-preview は非推奨のプレビューAPIヘッダーです。現在はまだ動作しますが、将来的に削除される可能性があります。

提案: application/vnd.github+json への変更を検討してください。


✅ 良い点

  • strict モードの設計(レビュアー2名、管理者適用、リニア履歴、署名コミット等)は本番環境保護として適切な設定
  • signed commits の有効化に別APIエンドポイントが必要な点を正しく対応している
  • require_signed_commits が失敗しても warning として継続する安全なフォールバック
  • dry-run チェックの内側に signed commits APIコールを配置しているのは正しい
  • repo-maintenance.md のテーブル整形は可読性向上

テスト計画について

PR説明のテスト項目がすべて未チェックです。CLAUDE.md の「Done」基準にある「すべての Quality Gate Pass」のため、少なくとも --dry-run での動作確認結果をPRに記載することを推奨します。


優先対応: docker-image.yml の変更の意図を再確認し、意図しないリリースを防ぐ対応を検討してください。

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e28c65c790

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

reviewers=2
fi
enforce_admins=true
require_linear_history=true

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Prevent strict mode from conflicting with merge defaults

When --protection-level strict is used, this enables linear-history enforcement, but the script still uses MERGE_METHOD="merge" by default in setup_repository_settings unless callers override it. In that default path, strict mode can make PRs effectively unmergeable (merge commits are the only allowed method while linear history forbids them), or cause API updates to fail depending on repository settings. Add a compatibility check or auto-select a linear-history-compatible merge method (squash/rebase) when strict mode is requested.

Useful? React with 👍 / 👎.

local require_conversation_resolution=false
local require_signed_commits=false

if [[ "$PROTECTION_LEVEL" == "strict" ]]; then

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Reject unknown protection levels

Any value other than strict silently falls back to standard behavior because the script only special-cases strict and never validates the user input. A typo such as --protection-level strcit will complete successfully while applying weaker protection than intended, which is especially risky for production-branch hardening. Validate PROTECTION_LEVEL against allowed values and exit on invalid input.

Useful? React with 👍 / 👎.

Comment on lines +262 to +263
if [[ "$require_signed_commits" == "true" ]]; then
if gh api "repos/$REPO/branches/$branch/protection/required_signatures" \

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Make signed-commit setting reversible

The script enables required signed commits with POST .../required_signatures in strict mode, but it never disables that requirement when strict mode is not selected. If a branch was previously configured as strict, rerunning with standard leaves signed commits enforced, so --protection-level standard is not idempotent and cannot restore the documented baseline. Add the corresponding disable call (DELETE .../required_signatures) when require_signed_commits is false.

Useful? React with 👍 / 👎.

- docker-image.yml を main のみに戻す(リリースWFの誤発火防止)
- ci.yml の pull_request にも pre-production/production ブランチ追加
- protection-level の入力バリデーション追加
- strict + merge method "merge" の競合を自動解決(squash に切替)
- GitHub API のオブジェクト形式を boolean 形式に修正
- standard モードで signed commits を無効化(冪等性確保)
- zzzax-preview ヘッダーを application/vnd.github+json に修正
- dry-run で strict の実際の適用値を表示

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@keito4
keito4 merged commit f9feb2c into main Mar 13, 2026
13 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

🎉 This PR is included in version 1.95.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

released リリース済み

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant