CIとマージ条件

PRで走るチェックと、実際にマージを止めるもの・止めないもの。

PRを開くと自動チェックが走り、プレビューURLが投稿されます。このページでは、そのチェックが何であるか、 そして同じくらい重要なこととして、あなたのPRと main の間に何も立っていないことを説明します。

すべてのPRで走るチェック

ワークフローはpushで自動実行されます。

TypeScriptエラーでビルドが壊れるとチェックが赤くなります — だからこそコミット前に必ず pnpm build:<your-app> をローカル実行しましょう。

マージを止めるものは何もありません

このリポジトリには branch protection も ruleset もありません。つまり:

• 承認は不要です。 自分のPRを自分でマージできます。
• チェックが赤でも止まりません。 チェックは助言であって、ゲートではありません。

これは便利さではなく、責任です。壊れた変更が本番に届くのを実際に止められるのは、コミット前の ローカルビルドだけです。その先には何も無いからです。

以前はゲートのように見えるものが2つありました

どちらも削除済みで、どちらも一度も機能していませんでした:

• すべてのPRに「自動承認しました」「開発者のレビューが必要です」とコメントするワークフロー。 コメントを投稿するだけで、承認を記録したこともマージを止めたこともありません。
• .github/CODEOWNERS。パスを @org/developers と @org/vibe-coders に割り当てていましたが、 org という GitHub 組織は実在せず、GitHub は全行を無視していました。

あるリポジトリで実際に何が強制されているかを知りたいときは、ワークフローファイルを読むのではなく GitHub に聞いてください:

gh api repos/<owner>/<repo>/rulesets

空のリストが返っても、private リポジトリで ruleset が使えないプランで 403 が返っても、 意味は同じ「ゲートは無い」です。

期待できる挙動

• アプリコードを編集 → チェック実行、プレビューURL投稿。プレビューを自分で確認し、納得したらマージ。
• 共有テーブル追加や schema.md 変更 → 上記に加え、マージ時に Neon main へマイグレーションが適用されます。 強制はされませんが、スキーマ変更は誰かに見てもらってください。
• CI/ルート設定を触る → 同上。ここでのミスは全アプリに波及するので、相応に慎重に。

マージ後

• 影響のあるアプリが本番に自動デプロイ。
• スキーママイグレーションがNeon mainデータベースに適用。
• PRのNeonプレビューブランチが削除。

Claudeに聞く

クイズ