• トラブルシューティング
  • 偽陽性
  • ロールバック後にスキーマダンプの比較に失敗

db:check-migrations ジョブ

このジョブはマージリクエストパイプラインのテストステージで実行されます。このジョブは

1. 新しいマイグレーションのロールバックを実行した後の、作成者の作業ブランチとターゲットブランチのスキーマダンプ比較。このチェックは、スキーマがこの新しいマイグレーションを実行する前の状態に正しくリセットされているかどうかを検証します。
2. 作成者の作業ブランチと、作成者がコミットしたdb/structure.sql ファイルのスキーマダンプ比較。このチェックでは、マイグレーションで予想されるすべての変更がコンテナに含まれていることを検証します。
3. 作成者がコミットしたdb/schema_migrations とマイグレーション実行後にスクリプトが生成したものとの Git diff。このチェックは、すべてが適切にコミットされたことを検証します。

トラブルシューティング

偽陽性

このジョブは失敗してもかまいません。

例えば、カラムを削除してロールバックすると、このカラムは常にカラムのリストの最後に追加されます。このカラムが以前はリストの中ほどにあった場合、ロールバックはスキーマを以前の状態に正確に戻すことはできません。ジョブは失敗しますが、許容できる状況です。

実際の例として、この失敗したジョブを参照してください。ここでは、作成者はposition 列を削除しました。

ロールバック後にスキーマダンプの比較に失敗

この失敗は、作業ブランチがターゲットブランチより遅れている場合によく起こります。実際のシナリオです：

1. main ターゲットブランチからdev 作業ブランチをチェックアウトしたとします。この時点で、各ブランチのHEAD はコミット A になっています。
2. 誰かがmain ブランチで作業し、fk_rails_dbebdaa8fe 制約を削除してmain にコミット B を作成します。
3. あなたはdev ブランチにカラムdependency_proxy_size を追加します。
4. structure.sql ファイルが期待した状態にロールバックされなかったため、db:check-migrations のジョブはdev ブランチの CI/CD パイプラインで失敗しました。

これは、ブランチdev にコミット B ではなく A と C が含まれていたためです。ブランチのデータベーススキーマは、fk_rails_dbebdaa8fe 制約の削除について知りませんでした。2つのスキーマを比較すると、dev ブランチにはこの制約が含まれていましたが、main ブランチには含まれていませんでした。

この例は実際に起こりました。ジョブの失敗ログを読んでください。

このようなイシューを修正するには、作業ブランチをターゲットブランチにリベースして最新の変更を取得します。