db:check-migrations job

요약

이 job은 머지 리퀘스트 파이프라인의 test Stage에서 실행되며, 다음을 확인합니다. 이 job은 실패가 허용되지 않지만, 거짓 양성이 발생할 수 있습니다. 이런 경우에는 MR에 pipeline:skip-check-migrations 레이블을 추가해 이 job을 건너뛰는 편이 안전합니다.

이 job은 머지 리퀘스트 파이프라인의 test Stage에서 실행되며, 다음을 확인합니다.

새 마이그레이션을 롤백한 다음, 작성자의 작업 브랜치와 대상 브랜치 사이의 스키마 덤프 비교. 이 검사는 새 마이그레이션 실행 이전 상태로 스키마가 올바르게 되돌아가는지 검증합니다.
작성자의 작업 브랜치와 작성자가 커밋한 db/structure.sql 파일 사이의 스키마 덤프 비교. 이 검사는 마이그레이션에서 예상되는 모든 변경이 포함돼 있는지 검증합니다.
작성자가 커밋한 db/schema_migrations와 마이그레이션 실행 후 스크립트가 생성한 결과 사이의 Git diff. 이 검사는 모든 내용이 제대로 커밋됐는지 검증합니다.

문제 해결#

거짓 양성#

이 job은 실패가 허용되지 않지만, 거짓 양성이 발생할 수 있습니다.

예시:

칼럼을 삭제한 뒤 롤백하면 해당 칼럼은 항상 칼럼 목록의 맨 끝에 다시 추가됩니다. 그 칼럼이 이전에 마지막 칼럼이 아니었다면 롤백으로 스키마를 이전 상태와 완전히 동일하게 되돌릴 수 없습니다. 참고: job 실패.
PostgreSQL 마이너 버전 업그레이드 과정에서 pg_dump가 제약 조건과 기타 데이터베이스 객체의 정렬 순서를 바꾸는 경우가 있습니다. 이 경우 MR과 무관한 스키마 구문의 정렬 순서를 문제 삼으며 job 이 실패합니다. 참고: job 실패.
- 이 문제는 모든 기능 MR에 영향을 주므로, 아직 다른 사람이 보고하지 않았다면 #database Slack 채널에 알리거나 이슈를 생성합니다.

이런 경우에는 MR에 pipeline:skip-check-migrations 레이블을 추가해 이 job을 건너뛰는 편이 안전합니다.

롤백 후 스키마 덤프 비교 실패#

이 실패는 작업 브랜치가 대상 브랜치보다 뒤처져 있을 때 자주 발생합니다. 실제 시나리오는 다음과 같습니다.

Mermaid 다이어그램 (9줄)

소스 코드 보기

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph LR
    accTitle: Schema dump comparison fails after rollback
    accDescr: Diagram showing how schema dump comparison failures occur if a working branch is behind the target branch
Main((main&lt;br&gt;commit A)) ===&gt; |remove constraint&lt;br&gt;fk_rails_dbebdaa8fe| MainB((main&lt;br&gt;commit B))
Main((main&lt;br&gt;commit A)) --&gt; |checkout&lt;br&gt;dev| DevA((dev&lt;br&gt;commit A)):::dev
DevA((dev&lt;br&gt;commit A)) --&gt; |add column&lt;br&gt;dependency_proxy_size| DevC((dev&lt;br&gt;commit C)):::dev
DevC -.-&gt; |CI pipeline&lt;br&gt;executes| JOB-FAILED((JOB FAILED!)):::error</code></pre></details></div>


main 대상 브랜치에서 dev 작업 브랜치를 체크아웃합니다. 이 시점에
두 브랜치의 HEAD는 모두 커밋 A를 가리킵니다.
다른 사람이 main 브랜치에서 작업하며 fk_rails_dbebdaa8fe 제약 조건을 삭제해
main에 커밋 B가 생성됩니다.
본인은 dev 브랜치에 dependency_proxy_size 칼럼을 추가합니다.
structure.sql 파일이 기대한 상태로 롤백되지 않았기 때문에
dev 브랜치의 CI/CD 파이프라인에서 db:check-migrations job 이 실패합니다.

이 상황은 dev 브랜치가 커밋 A와 C만 포함하고 B는 포함하지 않았기 때문에 발생했습니다. dev 브랜치의 데이터베이스 스키마는
fk_rails_dbebdaa8fe 제약 조건이 삭제된 사실을 알지 못했습니다. 두 스키마를 비교할 때
dev 브랜치에는 이 제약 조건이 있었지만 main 브랜치에는 없었습니다.
이 예시는 실제로 발생한 사례입니다. job 실패 로그를 참고합니다.
이런 종류의 문제를 해결하려면 작업 브랜치를 대상 브랜치에 리베이스해 최신 변경 사항을 받아옵니다.

홈/GitLab/개발/Database/Dbcheck-migrations-job

`db:check-migrations job`

GitLab v19.4

원문 보기
번역일: 2026-09-18

요약
이 job은 머지 리퀘스트 파이프라인의 test Stage에서 실행되며, 다음을 확인합니다. 이 job은 실패가 허용되지 않지만, 거짓 양성이 발생할 수 있습니다. 이런 경우에는 MR에 pipeline:skip-check-migrations 레이블을 추가해 이 job을 건너뛰는 편이 안전합니다.

이 job은 머지 리퀘스트 파이프라인의 test Stage에서 실행되며, 다음을 확인합니다.



새 마이그레이션을 롤백한 다음, 작성자의 작업 브랜치와 대상 브랜치 사이의
스키마 덤프 비교. 이 검사는 새 마이그레이션 실행 이전 상태로 스키마가
올바르게 되돌아가는지 검증합니다.
작성자의 작업 브랜치와 작성자가 커밋한 db/structure.sql 파일 사이의
스키마 덤프 비교. 이 검사는 마이그레이션에서 예상되는 모든 변경이
포함돼 있는지 검증합니다.
작성자가 커밋한 db/schema_migrations와 마이그레이션 실행 후 스크립트가 생성한
결과 사이의 Git diff. 이 검사는 모든 내용이 제대로 커밋됐는지
검증합니다.

문제 해결#
거짓 양성#
이 job은 실패가 허용되지 않지만, 거짓 양성이 발생할 수 있습니다.
예시:

칼럼을 삭제한 뒤 롤백하면 해당 칼럼은 항상
칼럼 목록의 맨 끝에 다시 추가됩니다. 그 칼럼이 이전에 마지막 칼럼이 아니었다면
롤백으로 스키마를 이전 상태와 완전히 동일하게 되돌릴 수 없습니다. 참고: job 실패.
PostgreSQL 마이너 버전 업그레이드 과정에서 pg_dump가 제약 조건과 기타 데이터베이스 객체의 정렬 순서를 바꾸는 경우가 있습니다.
이 경우 MR과 무관한 스키마 구문의 정렬 순서를 문제 삼으며
job 이 실패합니다. 참고: job 실패.

이 문제는 모든 기능 MR에 영향을 주므로, 아직 다른 사람이 보고하지 않았다면
#database Slack 채널에 알리거나 이슈를 생성합니다.



이런 경우에는 MR에 pipeline:skip-check-migrations 레이블을 추가해 이 job을 건너뛰는 편이 안전합니다.
롤백 후 스키마 덤프 비교 실패#
이 실패는 작업 브랜치가 대상 브랜치보다 뒤처져 있을 때 자주 발생합니다.
실제 시나리오는 다음과 같습니다.
Mermaid 다이어그램 (9줄)
소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
graph LR
    accTitle: Schema dump comparison fails after rollback
    accDescr: Diagram showing how schema dump comparison failures occur if a working branch is behind the target branch
Main((main&lt;br&gt;commit A)) ===&gt; |remove constraint&lt;br&gt;fk_rails_dbebdaa8fe| MainB((main&lt;br&gt;commit B))
Main((main&lt;br&gt;commit A)) --&gt; |checkout&lt;br&gt;dev| DevA((dev&lt;br&gt;commit A)):::dev
DevA((dev&lt;br&gt;commit A)) --&gt; |add column&lt;br&gt;dependency_proxy_size| DevC((dev&lt;br&gt;commit C)):::dev
DevC -.-&gt; |CI pipeline&lt;br&gt;executes| JOB-FAILED((JOB FAILED!)):::error</code></pre></details></div>


main 대상 브랜치에서 dev 작업 브랜치를 체크아웃합니다. 이 시점에
두 브랜치의 HEAD는 모두 커밋 A를 가리킵니다.
다른 사람이 main 브랜치에서 작업하며 fk_rails_dbebdaa8fe 제약 조건을 삭제해
main에 커밋 B가 생성됩니다.
본인은 dev 브랜치에 dependency_proxy_size 칼럼을 추가합니다.
structure.sql 파일이 기대한 상태로 롤백되지 않았기 때문에
dev 브랜치의 CI/CD 파이프라인에서 db:check-migrations job 이 실패합니다.

이 상황은 dev 브랜치가 커밋 A와 C만 포함하고 B는 포함하지 않았기 때문에 발생했습니다. dev 브랜치의 데이터베이스 스키마는
fk_rails_dbebdaa8fe 제약 조건이 삭제된 사실을 알지 못했습니다. 두 스키마를 비교할 때
dev 브랜치에는 이 제약 조건이 있었지만 main 브랜치에는 없었습니다.
이 예시는 실제로 발생한 사례입니다. job 실패 로그를 참고합니다.
이런 종류의 문제를 해결하려면 작업 브랜치를 대상 브랜치에 리베이스해 최신 변경 사항을 받아옵니다.