db:check-migrations 작업
이 작업은 병합 요청 파이프라인의 테스트 단계에서 실행됩니다. 다음을 확인합니다:
-
저자의 작업 브랜치와 대상 브랜치 간의 스키마 덤프 비교. 새로운 마이그레이션을 롤백한 후에 실행됩니다. 이 검사는 스키마가 새로운 마이그레이션을 실행하기 전의 상태로 올바르게 재설정되는지 확인합니다.
-
저자의 작업 브랜치와 저자가 커밋한
db/structure.sql
파일 간의 스키마 덤프 비교. 이 검사는 마이그레이션에서 예상되는 모든 변경 내용이 포함되어 있는지 확인합니다. -
저자가 커밋한
db/schema_migrations
와 마이그레이션 실행 후 스크립트가 생성한 것 간의 Git diff. 이 검사는 모든 것이 올바르게 커밋되었는지 확인합니다.
문제 해결
잘못된 긍정
이 작업은 실패해서는 안 되지만, 잘못된 긍정을 발생시킬 수 있습니다.
예를 들어, 열을 삭제한 후 롤백하면, 이 열은 항상 열 목록의 끝으로 다시 추가됩니다.
열이 이전에 목록의 중간에 있었다면, 롤백은 스키마를 이전 상태로 정확히 되돌릴 수 없습니다. 이러한 경우 pipeline:skip-check-migrations
레이블을 적용하여 이 검사를 건너뛸 수 있습니다.
실제 예제는
이 실패한 작업을 참조하세요.
여기서 저자는 position
열을 삭제했습니다.
롤백 후 스키마 덤프 비교 실패
이 실패는 종종 작업 브랜치가 대상 브랜치보다 뒤처져 있을 때 발생합니다.
실제 시나리오:
-
main
대상 브랜치에서dev
작업 브랜치로 체크아웃합니다. 이 시점에서 각 브랜치는 커밋 A에 HEAD가 있습니다. -
누군가가
main
브랜치에서 작업하면서fk_rails_dbebdaa8fe
제약 조건을 삭제하고,이는
main
에서 커밋 B를 생성합니다. -
dev
브랜치에dependency_proxy_size
열을 추가합니다. -
db:check-migrations
작업은dev
브랜치의 CI/CD 파이프라인에서 실패합니다.왜냐하면
structure.sql
파일이 예상 상태로 롤백되지 않았기 때문입니다.
이것은 dev
브랜치가 커밋 A와 C를 포함하고 B를 포함하지 않기 때문에 발생했습니다.
그의 데이터베이스 스키마는 fk_rails_dbebdaa8fe
제약 조건이 삭제된 사실을 알지 못했습니다. 두 스키마를 비교할 때, dev
브랜치에는 이 제약 조건이 포함되어 있었고, main
브랜치에는 없었습니다.
이 예시는 실제로 발생한 일입니다. 작업 실패 로그를 읽어보세요.
이러한 문제를 해결하려면 작업 브랜치를 대상 브랜치에 리베이스하여 최신 변경 사항을 가져와야 합니다.