PRビルド、デフォルトブランチ、タグ、定期実行の役割ごとにワークフローを分け、各開始条件を必要な範囲に絞ってください。新しいビルドが古い結果を置き換えられる条件だけ、自動キャンセルを残すのが基本です。
PR検証が重複する独立開発者、PR・リリース・定期実行を整理したいCIエンジニア向けです。
マージやリリースの検証記録を保ちつつ、不要な起動とキャンセルを減らしたい開発基盤の担当者にも役立ちます。
まず分けるべき「開始条件」と「実行内容」
Xcode Cloudでは、ブランチ変更、PR変更、タグ変更、スケジュールを開始条件として設定できます。条件がワークフローを起動することと、その後に実行するビルドやテストのアクションは別の設定です。まずこの二つを分けて確認してください。Appleの開始条件の設定説明とワークフローアクションの設定説明では、それぞれの役割が説明されています。
| 開始条件 | 主な用途 | 先に確認する点 |
|---|---|---|
| ブランチ変更 | ブランチ上の更新を検証する | 対象ブランチが広すぎないか |
| PR変更 | PRの更新をマージ前に検証する | 対象ブランチの方向が合っているか |
| タグ変更 | タグを契機とする処理を実行する | リリース用の用途と一致するか |
| スケジュール | 定期的なテストなどを実行する | PRやブランチの条件と重複していないか |
| 見えている症状 | 確認する設定 | 変更の考え方 |
|---|---|---|
| デフォルトブランチ更新でPR向け処理も起動 | ブランチ条件とPR条件 | 検証目的が異なるなら条件またはワークフローを分ける |
| 対象外のブランチでも起動 | ブランチの対象範囲 | 目的のブランチだけに絞って試す |
| PR更新で必要な検証が動かない | PR条件と対象ブランチ | 実際のマージ方針に沿って対象を確認する |
| 新しい更新で実行中の処理が終了する | 該当条件の自動キャンセル | 古い結果を残す必要があるか判断する |
| 夜間テストが更新のたびに起動 | スケジュールとPR・ブランチ条件 | 定期テストを日常のPR検証から分離する |
Appleは、最初のワークフローを構成する際にブランチ変更条件を扱っています。デフォルトの推奨設定を使っている場合も、実際の開始条件とチームが意図する検証範囲が一致しているとは限りません。Appleの最初のXcode Cloudワークフロー設定を確認し、起動記録と設定を照合してください。
デフォルトブランチ更新でPR検証も動く場合
デフォルトブランチの更新後にPR向けビルドが重なるときは、まず何を検証する条件なのかを分けます。 ブランチ変更を契機にする検証と、PR変更を契機にする検証は、目的や対象が異なる場合があります。両方を同じ条件やワークフローに寄せていると、意図した範囲を判断しにくくなります。
デフォルトブランチの変更がPR検証にも結び付くのはなぜですか。 推測で原因を決めず、該当するワークフローの開始条件、対象ブランチ、実際のトリガー記録を確認します。ブランチ条件が広く設定されていれば、その条件自体を絞るか、PR用とブランチ用のワークフローを分けてください。AppleのXcode Cloudワークフロー戦略も、目的に応じたワークフロー設計の確認に使えます。
対象外のブランチから起動する場合
公開ブランチ、作業用ブランチ、デフォルトブランチが同じ条件に含まれていると、期待しないブランチ更新でも起動する可能性があります。ただし、起動記録を確認するまでは、特定のブランチが原因だと断定しないでください。
確認では、ワークフロー名、起動元、対象ブランチを記録し、条件の変更後に想定したブランチだけで試します。 起動条件の対象を限定したうえで、対象外の更新では起動しないことも確かめます。ブランチ開始条件の仕様はAppleのブランチ開始条件に関する説明で確認できます。
PR更新時の検証漏れと対象範囲
PR更新時だけ起動させたい場合は、PR変更を開始条件に設定し、条件が対象とするブランチがチームのマージ方針に合っているか確認します。条件を追加しただけで解決したと判断せず、PR更新後の記録に表示された起動元と、実際に実行されたアクションを照合してください。
スクリプト内でPR向けの処理を分岐する場合、環境変数をいつ参照できますか。 どの開始条件で起動したかを確認し、その条件で利用できる環境変数だけを使ってください。起動条件に関係なくPR用の値が常に利用できると見なすのは避けます。Appleの環境変数リファレンスで、使用する変数と利用条件を確認できます。
マージ時に必要なチェックと、PR更新時に実行する検証も同一視しないでください。チームのマージ要件と照らす際は、AppleのPRマージ要件に関する説明を参照し、必要な検証結果が残る設定か確認します。
自動キャンセルの判断
開始条件ごとに自動キャンセルの設定を確認してください。Appleのワークフロー資料では、自動キャンセルは開始条件ごとに既定で有効とされ、条件単位で調整できます。Xcode Cloudワークフローリファレンスに沿って、どの条件に適用される設定か確かめてください。
自動キャンセルを常に無効にすべきでしょうか。 一律に無効化せず、後続のビルドが先行する結果を置き換えてよい条件では維持し、各更新の記録や比較結果が必要な条件では無効化を検討します。複数の開始条件を使っている場合は、すべてに同じ判断を適用しないでください。
注意：キャンセルされたビルドが意図した条件だけに限られているか、連続した更新を使って確認してください。自動キャンセルの切り替えだけでは、どの開始条件で終了したのかは説明できません。
夜間UIテストと日常のPR検証
PR更新のたびに夜間UIテストまで起動する場合は、長時間の定期テストを日常のPR向けフィードバックから分けます。 複数のシミュレーターを対象にするテストなど、目的の異なる処理を別ワークフローにし、スケジュール条件とPR・ブランチ条件のどれに結び付いているかを確認してください。
分離後は、スケジュールによる起動とPR更新による起動をそれぞれ試し、記録上の起動元が意図と一致するか確かめます。Appleのワークフロー戦略ガイドも、用途ごとの構成を検討する際の参照先です。起動頻度や節約できる時間を、確認していない状態で見積もる必要はありません。
設定変更後の確認チェックリスト
以下を上から実施すれば、構成と実際の記録の食い違いを段階的に調べられます。
- [ ] 該当するワークフロー名と開始条件を控え、ブランチ・PR・タグ・スケジュールのどれが設定されているか確認します。
- [ ] 各条件の対象ブランチや対象範囲を見直し、ワークフローの目的に不要な対象を外します。
- [ ] PR検証とデフォルトブランチ検証の目的が異なる場合、条件またはワークフローを分けます。
- [ ] 起動記録の起動元、対象ブランチ、実行されたアクションを設定と照合します。
- [ ] PR条件で使うスクリプト分岐がある場合、環境変数の利用条件を公式リファレンスで確かめます。
- [ ] 自動キャンセルを開始条件ごとに確認し、新しい結果が古い結果を置き換えてよいか判断します。
- [ ] 変更後に対象ブランチの更新、PR更新、定期実行を個別に試し、意図した経路だけが動くか確かめます。
- [ ] キャンセルの結果も記録し、どの条件で前のビルドが終了したのか説明できる状態にします。
記録は、ワークフロー名、起動元、対象ブランチ、キャンセル状態を同じ形式で残すと比較しやすくなります。設定と記録を突き合わせても説明できない場合は、まず開始条件を一つずつ切り分けて再確認してください。
持続的なMac実行環境が必要な場合
まずXcode Cloud内で条件とワークフローを整理し、それでも自分で管理するホスト、独自ツールチェーン、より細かな環境制御が必要なら、実行環境を別に評価します。ビルドの過剰起動を、ただちに計算資源不足と見なすのは適切ではありません。
現在の管理型ワークフローは運用負担を抑えられる一方、ホスト環境を継続的に占有したり、要件に応じて環境を細かく制御したりする用途には合わない場合があります。Mac miniの自前運用ならホストを直接管理できますが、ハードウェアの購入と保守が必要です。Linux環境はmacOS専用のXcode実行環境の代替にはなりません。まずはリモートMacの利用場面で必要な実行形態を整理し、期間限定の環境が適するならKVMFLUXの利用プランも比較対象にできます。
PR、リリース、定期実行を分けても、持続的なMacホストや独自ツールチェーンが必要な場合に限り、リモートMacを実行環境の候補に加えてください。環境を継続利用する予定があり、自前のMacを購入・保守するほうが合理的なら、レンタルを選ぶ必要はありません。まずは実際の起動記録で問題の条件を特定し、その後に必要な実行環境だけを選ぶのが確実です。