• 문제 해결
  • 잘못된 긍정적 결과
  • 롤백 이후에 스키마 덤프 비교가 실패하는 경우

db:check-migrations 작업

이 작업은 병합 요청 파이프라인의 테스트 단계에서 실행됩니다. 다음을 확인합니다:

1. 새로운 마이그레이션을 실행한 후 작성자의 작업 브랜치와 대상 브랜치 간의 스키마 덤프 비교를 통해 롤백을 수행합니다. 이 체크는 새로운 마이그레이션을 실행하기 전의 스키마가 올바르게 이전 상태로 재설정되는지를 확인합니다.
2. 작성자가 커밋한 db/structure.sql 파일과 작업 브랜치 사이의 스키마 덤프 비교를 수행합니다. 이 체크는 마이그레이션에 예상대로 모든 변경 내용이 포함되어 있는지 확인합니다.
3. 작성자가 커밋한 db/schema_migrations와 마이그레이션 실행 후에 스크립트가 생성한 것 간의 Git 차이를 확인합니다. 이 체크는 모든 것이 올바르게 커밋되었는지를 확인합니다.

문제 해결

잘못된 긍정적 결과

이 작업은 가끔 잘못된 긍정적 결과를 발생시킬 수 있기 때문에 실패할 수 있습니다.

예를 들어, 열을 삭제한 다음 롤백할 때, 이 열은 항상 열 목록의 끝에 다시 추가됩니다. 만약 이 열이 이전에 목록의 중간에 있었다면 롤백은 스키마를 이전 상태로 정확하게 되돌릴 수 없습니다. 작업은 실패하지만 수용 가능한 상황입니다.

실제 예시를 보려면 이 실패한 작업을 참조하세요. 여기서 작성자가 position 열을 삭제했습니다.

롤백 이후에 스키마 덤프 비교가 실패하는 경우

이 실패는 작업 브랜치가 대상 브랜치보다 뒤처진 경우에 종종 발생합니다. 실제 시나리오:

1. 개발 작업 브랜치를 메인 대상 브랜치에서 체크아웃합니다. 이 시점에서 각 브랜치는 각각 커밋 A에 HEAD를 두고 있습니다.
2. 누군가 메인 브랜치에서 작업을 하고 fk_rails_dbebdaa8fe 제약 조건을 제거하여 메인에 커밋 B를 만듭니다.
3. 개발 브랜치에 dependency_proxy_size 컬럼을 추가합니다.
4. db:check-migrations 작업은 dev 브랜치의 CI/CD 파이프라인에서 실패합니다. 왜냐하면 structure.sql 파일이 예상한 상태로 롤백되지 않았기 때문입니다.

이는 dev 브랜치에는 커밋 A와 C가 있었으며 B는 없었기 때문에 발생했습니다. 그것의 데이터베이스 스키마는 fk_rails_dbebdaa8fe 제약 조건의 제거를 알지 못했습니다. 두 스키마를 비교할 때, dev 브랜치에는 이 제약 조건이 있었지만 메인 브랜치에는 그것이 없었습니다.

이 예시는 실제로 발생한 일입니다. 작업 실패 로그를 읽어보세요.

이러한 문제를 해결하려면 작업 브랜치를 대상 브랜치로 리베이스하여 최신 변경 사항을 가져오세요.