db:check-migrations job
GitLab v19.1이 job은 머지 리퀘스트 파이프라인의 test Stage에서 실행됩니다. 새 마이그레이션을 롤백한 후, 작성자의 작업 브랜치와 타깃 브랜치 간의 스키마 덤프 비교. 작성자의 작업 브랜치와 작성자가 커밋한 db/structure.sql 파일 간의 스키마 덤프 비교.
이 job은 머지 리퀘스트 파이프라인의 test Stage에서 실행됩니다. 다음을 확인합니다:
-
새 마이그레이션을 롤백한 후, 작성자의 작업 브랜치와 타깃 브랜치 간의 스키마 덤프 비교. 이 확인은 스키마가 새 마이그레이션 실행 이전 상태로 올바르게 재설정되는지 검증합니다.
-
작성자의 작업 브랜치와 작성자가 커밋한
db/structure.sql파일 간의 스키마 덤프 비교. 이 확인은 마이그레이션의 모든 예상 변경 사항이 포함되어 있는지 검증합니다. -
작성자가 커밋한
db/schema_migrations와 마이그레이션 실행 후 스크립트가 생성한 것 간의 Git diff. 이 확인은 모든 내용이 올바르게 커밋되었는지 검증합니다.
문제 해결#
거짓 양성(False positives)#
이 job은 실패가 허용되지 않지만, 거짓 양성이 발생할 수 있습니다.
예시:
-
칼럼을 삭제한 후 롤백하면, 해당 칼럼은 항상 칼럼 목록의 끝에 다시 추가됩니다. 칼럼이 이전에 마지막 칼럼이 아니었다면, 롤백이 스키마를 이전 상태로 정확히 되돌릴 수 없습니다. 참조: job 실패.
-
때때로 pg_dump는 마이너 PostgreSQL 버전 업그레이드 시 제약 조건 및 기타 데이터베이스 오브젝트의 정렬 방식을 변경할 수 있습니다. 이로 인해 MR과 관련 없는 스키마의 문(statement) 순서에 대한 불일치로 job이 실패합니다. 참조: job 실패.
아직 다른 사람이 보고하지 않았다면 #database Slack 채널에 보고하거나 이슈를 생성하세요. 이 문제는 모든 기능 MR에 영향을 미칩니다.
이러한 경우, MR에 pipeline:skip-check-migrations 라벨을 추가하여 이 job을 건너뛰는 것이 더 안전합니다.
롤백 후 스키마 덤프 비교 실패#
이 실패는 작업 브랜치가 타깃 브랜치보다 뒤처져 있을 때 자주 발생합니다. 실제 시나리오:
%%{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<br>commit A)) ===> |remove constraint<br>fk_rails_dbebdaa8fe| MainB((main<br>commit B))
Main((main<br>commit A)) --> |checkout<br>dev| DevA((dev<br>commit A)):::dev
DevA((dev<br>commit A)) --> |add column<br>dependency_proxy_size| DevC((dev<br>commit C)):::dev
DevC -.-> |CI pipeline<br>executes| JOB-FAILED((JOB FAILED!)):::error
-
main타깃 브랜치에서dev작업 브랜치를 체크아웃합니다. 이 시점에서 각 브랜치의HEAD는 커밋 A에 있습니다. -
누군가
main브랜치에서 작업하여fk_rails_dbebdaa8fe제약 조건을 삭제하고, 이로써main에 커밋 B가 생성됩니다. -
dev브랜치에 칼럼dependency_proxy_size를 추가합니다. -
dev브랜치의 CI/CD 파이프라인에서db:check-migrationsjob이 실패합니다.structure.sql파일이 예상 상태로 롤백되지 않았기 때문입니다.
이는 브랜치 dev가 커밋 A와 C만 포함하고 B는 포함하지 않았기 때문에 발생했습니다.
dev의 데이터베이스 스키마는 fk_rails_dbebdaa8fe 제약 조건 제거를 알지 못했습니다.
두 스키마를 비교할 때, dev 브랜치에는 이 제약 조건이 있었지만 main 브랜치에는 없었습니다.
이 예시는 실제로 발생한 사례입니다. job 실패 로그를 참고하세요.
이러한 종류의 문제를 수정하려면, 최신 변경 사항을 가져오기 위해 작업 브랜치를 타깃 브랜치 위로 리베이스하세요.