GitLab 16 변경 사항

Tier: Free, Premium, Ultimate Offering: Self-Managed

이 페이지에는 GitLab 16의 마이너 버전 및 패치 버전에 대한 업그레이드 정보가 포함되어 있습니다. 다음 사항에 대해 이 지침을 검토해야 합니다. - 설치 유형. - 현재 버전 및 대상 버전 사이의 모든 버전.

GitLab Helm 차트를 업그레이드하는 자세한 내용은 7.0 릴리즈 노트를 참조하십시오.

15.11에서 업그레이드할 때 주의할 사항

  • GitLab 16 부터 PostgreSQL 12가 지원되지 않습니다. GitLab 16.0 이상으로 업그레이드하기 전에 PostgreSQL을 적어도 13.6 버전으로 업그레이드하세요.
  • GitLab 인스턴스가 먼저 15.11.0, 15.11.1 또는 15.11.2로 업그레이드된 경우 데이터베이스 스키마가 올바르지 않습니다. 16.x로 업그레이드하기 전에 대책을 수행하세요.
  • 16.0부터, GitLab 온프레미스 설치는 기본적으로 기본값으로 두 개의 데이터베이스 연결을 갖게 됩니다. 이 변경으로 PostgreSQL 연결 수가 두 배가 됩니다. 온프레미스 버전의 GitLab이 GitLab.com과 유사하게 작동하도록 하는 것입니다. 또한 온프레미스 버전의 GitLab에 대한 CI 기능을 위한 별도의 데이터베이스를 활성화하는 단계 중 하나입니다. 16.0으로 업그레이드하기 전에 PostgreSQL의 최대 연결 수를 늘려아 하는지 확인하세요.

  • 대부분의 설치는 16.0, 16.1 및 16.2를 건너뛸 수 있습니다. 업그레이드 경로상의 첫 필수 중지점은 16.3입니다. 모든 경우에 중간 버전에 대한 노트를 확인해야 합니다.

    사용하는 기능과 환경의 크기에 따라 일부 GitLab 설치는 중간 버전에서 중지해야 합니다. - 16.0.8: 사용자 테이블에 많은 레코드가 있는 인스턴스 자세한 내용은 긴 시간이 필요한 사용자 유형 데이터 변경을 참조하십시오. - 16.1.5: NPM 패키지 레지스트리를 사용하는 인스턴스 - 16.2.8: 많은 파이프라인 변수(이전 파이프라인 포함)가 있는 인스턴스

    인스턴스에 영향을 받고 이러한 중지를 건너뛰면: - 업그레이드에 몇 시간이 걸릴 수 있습니다. - 데이터베이스 변경이 완료될 때까지 인스턴스가 500 오류를 생성하고 난 후에는 Puma와 Sidekiq을 다시 시작해야 합니다. - 리눅스 패키지 설치에서 시간 초과가 발생하고 이를 해결하기 위해 결함 처리를 완료하는 매뉴얼 대책 이 필요합니다.

  • GitLab 16.0에서 프로젝트 사이즈에 대한 제한을 강제로 변경했습니다. 온프레미스에서 이러한 제한을 사용하는 경우, 한 그룹 내의 영향을받지 않는 Git 리포지터리로 푸시할 때 제한에 도달한 프로젝트는 오류 메시지가 발생합니다. 이 오류는 종종 0 바이트의 제한(0 B의 제한)을 초과한다고 합니다.

    푸시는 성공하나, 오류는 그렇지 않은 것처럼 보이며 자동화 문제를 일으킬 수 있습니다. 해당 문제에 대해 문제에서 자세히 읽기 및 버그는 GitLab 16.5 이후에 수정되었습니다.

  • 일반적으로 PgBouncer가 있는 환경의 백업은 GITLAB_BACKUP_로 접두사가 있는 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에 정의된 직접 연결 대신에 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업이 실패합니다. 이 문제를 해결하기 위해 pg_dump를 직접 사용해야 합니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 내용
    15.11 모든 없음
    16.0 모든 없음
    16.1 모든 없음
    16.2 모든 없음
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

리눅스 패키지 설치

  • GitLab 16에서 Gitaly 및 Praefect 구성 구조를 업그레이드하기 전에 변경해야 합니다. 데이터 손실을 피하려면 먼저 Praefect를 다시 구성하고, 새 구성을 하는 일환으로 메타데이터 확인을 비활성화하세요. 자세한 내용은 다음을 참조하십시오:

  • 만약 Gitaly를 /var/opt/gitlab/git-data/repositories 이외의 위치에 Git 데이터를 저장할 수 있도록 재구성한다면, 패키지화된 GitLab 16.0 이상은 자동으로 디렉터리 구조를 생성하지 않습니다. 자세한 내용 및 대책은 이슈를 참조하십시오.

16.11.0

리눅스 패키지 설치

GitLab 16.11에서, PostgreSQL은 다음과 같은 경우를 제외하고 자동으로 14.x로 업그레이드됩니다.

  • Patroni를 사용하여 고가용성으로 데이터베이스를 실행 중인 경우.
  • 데이터베이스 노드가 GitLab Geo 구성의 일부인 경우.
  • 명시적으로 PostgreSQL 자동 업그레이드에서 제외된 경우.
  • /etc/gitlab/gitlab.rb에 postgresql['version'] = 13이 있는 경우.

고가용성 및 Geo 설치는 PostgreSQL 14로 매뉴얼 업그레이드를 지원합니다. 고가용성/Geo 클러스터에 배포된 패키지화된 PostgreSQL을 참조하십시오.

16.10.0

GitLab 16.10 이상으로 업그레이드하는 동안 다음 오류가 발생할 수 있습니다: 

PG::UndefinedColumn: ERROR:  column namespace_settings.delayed_project_removal does not exist

이 오류는 삭제된 후 나중에 삭제된 열을 참조하는 후속 마이그레이션이 실행되기 전에 열을 제거하는 마이그레이션을 실행할 때 발생할 수 있습니다. 이 버그에 대한 수정은 16.11에서 발표될 예정입니다.

문제를 해결하기 위해 다음을 수행하세요:

  1. 임시로 열을 다시 생성하세요. gitlab-psql을 사용하거나 매뉴얼으로 데이터베이스에 연결하여 다음을 실행하세요: 

    ALTER TABLE namespace_settings ADD COLUMN delayed_project_removal BOOLEAN DEFAULT NULL;

  2. 보류 중인 마이그레이션을 적용하세요: 

    gitlab-ctl reconfigure

  3. 최종 확인: 

    gitlab-ctl upgrade-check

  4. 열을 제거하세요. gitlab-psql을 사용하거나 매뉴얼으로 데이터베이스에 연결하여 다음을 실행하세요: 

    ALTER TABLE namespace_settings DROP COLUMN delayed_project_removal;

Linux package installations

GitLab 16.10의 Linux 패키지 설치에는 Patroni의 새 주 버전인 3.0.1로의 업그레이드가 포함되어 있습니다. 이전에는 버전 2.1.0을 사용하고 있었습니다.

If you’re using one of the reference architectures that enables High Availability (HA) (3k users or more), you’re using PostgreSQL replication and failover for Linux package installations, which uses Patroni.

이 경우에 해당한다면, 멀티 노드 인스턴스를 업그레이드하는 방법에 대해 멀티 노드 다운타임으로 업그레이드를 참조하세요.

자세한 내용은 버전 2.1.0과 버전 3.0.1 사이의 변경 사항을 살펴보려면 Patroni 릴리스 노트를 참조하세요.

16.9.0

GitLab 16.9.0으로 업그레이드하는 동안 다음 오류를 만날 수 있습니다: 

PG::UndefinedTable: ERROR:  relation "p_ci_pipeline_variables" does not exist

모든 마이그레이션이 완료되고 모든 Rails 및 Sidekiq 노드를 재시작했는지 확인하세요. 이 버그에 대한 수정은 16.9.1에서 예정되어 있습니다.

Geo 설치

  • 컨테이너 복제의 버그로 인해 잘못 구성된 보조 사이트가 실패한 컨테이너 복제를 성공으로 표시할 수 있습니다. 이후의 검증에서 체크섬 불일치로 인해 컨테이너를 실패로 표시할 수 있습니다. 해결책은 보조 사이트 구성을 수정하는 것입니다. 영향을 받는 릴리즈:

    영향을 받는 마이너 릴리즈 영향을 받는 패치 릴리즈 수정된 내역
    모두 모두 16.10.2

  • GitLab 16.5에서 발생한 버그로 인해 개인 스니펫이 보조 Geo 사이트로 복제되지 않습니다. 이로 인해 Geo 장애 조치 시 개인 스니펫 데이터가 손실될 수 있습니다. 이슈 #439933에서 문제에 대한 자세한 내용 및 해결 방법을 확인하세요.

    영향을 받는 릴리즈:

    영향을 받는 마이너 릴리즈 영향을 받는 패치 릴리즈 수정된 내역
    16.5 모두 없음
    16.6 모두 없음
    16.7 모두 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

  • 기본 사이트와 보조 사이트 간 체크섬 불일치로 일부 컨테이너 레지스트리 이미지의 검증 실패를 경험할 수 있습니다. 이슈 442667에 자세한 내용이 나와 있습니다. 데이터는 보조 사이트로 올바르게 복제되고 있지만 검증에는 성공하지 못하고 있는 것으로 알려진 해결 방법은 현재까지 없습니다.

    영향을 받는 릴리즈:

    영향을 받는 마이너 릴리즈 영향을 받는 패치 릴리즈 수정된 내역
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

Linux package installations

  • GitLab 16.9.0에서 Sidekiq의 min_concurrency 및 max_concurrency 옵션이 폐기되었으며 GitLab 17.0.0에서 제거 예정입니다. GitLab 16.9.0 이상에서는 GitLab 17.0.0에서의 대규모 변경 사항을 피하기 위해 새로운 concurrency 옵션을 설정하고 min_concurrency 및 max_concurrency 옵션을 제거하세요.

16.8.0

  • GitLab 16.8.0 및 16.8.1에서 Sidekiq gem이 업그레이드되었으며, 새로운 버전은 Redis 6.2 이상이 필요합니다. Redis 6.0을 사용 중이라면 16.8.2로 직접 업그레이드하면 Redis 6.0과의 호환성을 복원할 수 있습니다.

  • 참고: 더 이상 Redis 6.0은 지원되지 않습니다.

  • 일반적으로 PgBouncer가있는 환경에서는 백업해야하는 배경이 있습니다. 그러나 이슈로 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통해 일반적인 데이터베이스 연결을 사용하고 데이터베이스 백업이 실패합니다. 해결 방법은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리즈:

    영향을 받는 마이너 릴리즈 영향을 받는 패치 릴리즈 수정된 내역
    15.11 모두 없음
    16.0 모두 없음
    16.1 모두 없음
    16.2 모두 없음
    16.3 모두 없음
    16.4 모두 없음
    16.5 모두 없음
    16.6 모두 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Geo installations

  • GitLab 16.7 및 이후의 신규 설치에 대해 PostgreSQL 버전 14가 기본 버전으로 설정됩니다. 기존 Geo 보조 사이트는 PostgreSQL 버전 14로 업그레이드할 수 없습니다. 자세한 내용은 이슈 7768을 참조하세요. 모든 Geo 사이트는 동일한 버전의 PostgreSQL을 실행해야 합니다. GitLab 16.7부터 16.8.1에 새로운 Geo 보조 사이트를 추가하려면 다음 중 한 가지 조치를 취해야 합니다.

    • 첫 번째 Geo 보조 사이트를 추가하려면: 새로운 Geo 보조 사이트를 설정하기 전에 기본 사이트를 PostgreSQL 14로 업그레이드하세요. 기본 사이트가 이미 PostgreSQL 14를 실행하고 있다면 특별한 조치가 필요하지 않습니다.
    • 기존 사이트이 모든 사이트가 PostgreSQL 13을 실행 중인 경우, 새로운 Geo 보조 사이트를 고정된 PostgreSQL 버전 13으로 설치하세요.
    • 기존 사이트이 모든 사이트가 PostgreSQL 14를 실행 중인 경우: 특별한 조치가 필요하지 않습니다.
    • 새로운 Geo 보조 사이트를 기존 보조 사이트에 추가하려면:
      • 모든 기존 사이트를 GitLab 16.8.2 이상 및 PostgreSQL 14로 업그레이드한 다음, 새로운 Geo 보조 사이트를 배치하세요.

  • GitLab 16.5에서 도입된 버그로 인해 개인 스니펫이 보조 Geo 사이트로 복제되지 않습니다. 이로 인해 Geo 장애 조치 시 개인 스니펫 데이터가 손실될 수 있습니다. 이슈 #439933에서 문제에 대한 자세한 내용 및 해결 방법을 확인하세요.

    영향을 받는 릴리즈:

    영향을 받는 마이너 릴리즈 영향을 받는 패치 릴리즈 수정된 내역
    16.5 모두 없음
    16.6 모두 없음
    16.7 모두 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

  • 일부 컨테이너 레지스트리 이미지의 기본 사이트와 보조 사이트 간 체크섬 불일치로 유효성 검사 실패가 발생할 수 있습니다. 데이터가 올바르게 보조 사이트로 복제되고 있지만 검증에는 성공하지 못하는 경우입니다. 현재까지 알려진 해결 방법은 없습니다.

    영향을 받는 릴리즈:

    영향을 받는 마이너 릴리즈 영향을 받는 패치 릴리즈 수정된 내역
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

16.7.0

  • GitLab 16.7는 필수 업그레이드 단계입니다. 이렇게 하면 GitLab 16.7 이전에 소개된 모든 데이터베이스 변경 사항이 모든 Self-Managed 인스턴스에 구현되었음이 보장됩니다. 그런 다음 종속 변경 사항은 GitLab 16.8 이후에 출시될 수 있습니다. 이슈 429611에서 자세한 내용을 확인할 수 있습니다.

  • 보통, PgBouncer를 사용하는 환경에서는 GITLAB_BACKUP_로 접두사가 붙은 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신에 PgBouncer를 통해 정규 데이터베이스 연결을 사용하고 데이터베이스 백업이 실패합니다. 해결책은 pg_dump을 직접 사용하는 것입니다.

    영향 받는 릴리스:

    영향을 받는 부 버전 릴리스 영향을 받는 패치 릴리스 해결된 부분
    15.11 전체 없음
    16.0 전체 없음
    16.1 전체 없음
    16.2 전체 없음
    16.3 전체 없음
    16.4 전체 없음
    16.5 전체 없음
    16.6 전체 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Linux 패키지 설치

Linux 패키지 설치에는 특정 정보가 적용됩니다:

  • GitLab 16.7부터 PostgreSQL 14가 Linux 패키지와 함께 기본 버전으로 설치됩니다. 패키지 업그레이드 중에는 데이터베이스가 PostgreSQL 14로 업그레이드되지 않습니다. PostgreSQL 14로 업그레이드하려면 매뉴얼으로 해야 합니다.

    PostgreSQL 13을 사용하려면 /etc/gitlab/gitlab.rb에서 postgresql['version'] = 13을 설정해야 합니다.

Geo 설치

  • GitLab 16.7 이후의 새로운 설치의 경우 PostgreSQL 버전 14가 기본값입니다. 이미 있는 Geo secondary site는 PostgreSQL 버전 14로 업그레이드할 수 없는 알려진 문제로 인해 제약이 있습니다. 모든 Geo 사이트는 동일한 버전의 PostgreSQL을 실행해야 합니다. GitLab 16.7부터 16.8.1로 기반을 둔 새로운 Geo secondary site를 추가하려면 구성에 따라 다음 작업 중 하나를 수행해야 합니다:

    • 첫 번째 Geo secondary site를 추가하는 경우: 새로운 Geo secondary site를 설정하기 전에 Primary site를 PostgreSQL 14로 업그레이드하세요. 기존 Primary site가 이미 PostgreSQL 14를 실행 중인 경우 별도의 조치가 필요하지 않습니다.
    • 하나 이상의 기존 Geo secondary site에 새로운 Geo secondary site를 추가하는 경우:
      • 기존 사이트가 모두 PostgreSQL 13을 실행 중인 경우: Pinned PostgreSQL 버전 13으로 새로운 Geo secondary site를 설치하세요.
      • 모든 기존 사이트가 PostgreSQL 14를 실행 중인 경우: 별도의 작업이 필요하지 않습니다.
      • 기존 사이트를 GitLab 16.8.2 이상 및 PostgreSQL 14로 업그레이드한 후에 새로운 Geo secondary site를 배포에 추가하기 전에 모든 기존 사이트를 업그레이드하세요.

  • 기존 Geo secondary site와 Primary site 간에 체크섬 불일치로 일부 프로젝트의 검증 실패가 발생할 수 있습니다. 자세한 내용은 이슈에서 추적되고 있습니다. 데이터가 올바르게 복제되고 있기 때문에 데이터 손실의 위험은 없습니다. 영향을 받은 프로젝트를 Geo secondary site에서 복제하는 사용자는 항상 Primary site로 리디렉션됩니다. 이 시점에는 알려진 해결책이 없습니다. 문제를 해결하기 위해 노력하고 있습니다.

    영향 받는 릴리스:

    영향을 받는 부 버전 릴리스 영향을 받는 패치 릴리스 해결된 부분
    16.3 전체 없음
    16.4 전체 없음
    16.5 전체 없음
    16.6 16.6.0 - 16.6.5 16.6.6
    16.7 16.7.0 - 16.7.3 16.7.4

  • GitLab 16.5에서 소개된 버그로 인해 개인 스니펫이 Geo secondary site에 복제되지 않습니다. 이로 인해 Geo 장애 조치 시 개인 스니펫 데이터가 손실될 수 있습니다. 문제의 세부 정보 및 해결책은 이슈 #439933에서 확인할 수 있습니다.

    영향 받는 릴리스:

    영향을 받는 부 버전 릴리스 영향을 받는 패치 릴리스 해결된 부분
    16.5 전체 없음
    16.6 전체 없음
    16.7 전체 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

16.6.0

  • GitLab 16.6으로 업그레이드한 후 CI Environment destroy jobs may be spawned할 수 있습니다.

  • 보통, PgBouncer를 사용하는 환경에서는 GITLAB_BACKUP_로 접두사가 붙은 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신에 PgBouncer를 통해 정규 데이터베이스 연결을 사용하고 데이터베이스 백업이 실패합니다. 해결책은 pg_dump을 직접 사용하는 것입니다.

    영향 받는 릴리스:

    영향을 받는 부 버전 릴리스 영향을 받는 패치 릴리스 해결된 부분
    15.11 전체 없음
    16.0 전체 없음
    16.1 전체 없음
    16.2 전체 없음
    16.3 전체 없음
    16.4 전체 없음
    16.5 전체 없음
    16.6 전체 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Geo 설치

  • 주요 사이트와 보조 사이트 간의 체크섬 불일치로 일부 프로젝트에서 확인 실패를 경험할 수 있습니다. 이에 대한 자세한 내용은 이슈에서 추적됩니다. 데이터는 올바르게 보조 사이트로 복제되고 있기 때문에 데이터 손실의 위험이 없습니다. 영향을 받는 프로젝트를 Geo 보조 사이트에서 클론하는 사용자는 항상 주요 사이트로 리디렉션됩니다. 현재는 알려진 해결책이 없습니다. 우리는 현재 문제를 해결하기 위해 노력하고 있습니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 16.6.0 - 16.6.5 16.6.6
    16.7 16.7.0 - 16.7.3 16.7.4

  • GitLab 16.5에서 발생한 버그로 인해 개인 스니펫이 보조 Geo 사이트로 복제되지 않습니다. 이로 인해 Geo 장애 발생 시 개인 스니펫 데이터의 손실이 발생할 수 있습니다. 문제의 자세한 내용 및 해결 방법은 이슈 #439933 에서 확인할 수 있습니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    16.5 모든 없음
    16.6 모든 없음
    16.7 모든 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

16.5.0

  • Gitaly에서는 Git 2.42.0 이상이 필요합니다. 직접 컴파일한 설치에서는 Gitaly에서 제공하는 Git 버전을 사용해야 합니다.
  • 때때로 회귀가 발생하여 그룹을 탐색할 때 HTTP 500 오류가 발생할 수 있습니다. GitLab 16.6 이상으로 업그레이드하면 문제가 해결됩니다.
  • 회귀로 인해 선택되지 않은 고급 검색 facet가 로드되지 않을 수 있습니다. 16.6 이상으로 업그레이드하면 문제가 해결됩니다.

  • unique_batched_background_migrations_queued_migration_version 인덱스가 16.5에서 도입되었으며, 특정 마이그레이션(DeleteOrphansScanFindingLicenseScanningApprovalRules2)이 이 고유 제약 조건을 깨뜨릴 수 있습니다. 이를 해결하는 이슈 #437291에 대체하는 해결책이 제공되어 있습니다.

  • PgBouncer가 있는 환경에서는 보통 백업을 할 때 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에서 정의한 직접 연결 대신 PgBouncer를 통한 일반 데이터베이스 연결을 사용하고 데이터베이스 백업이 실패합니다. 해결책은 pg_dump를 직접 사용하는 것입니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    15.11 모든 없음
    16.0 모든 없음
    16.1 모든 없음
    16.2 모든 없음
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

리눅스 패키지 설치

  • SSH 클론 URL은 /etc/gitlab/gitlab.rb에서 gitlab_rails['gitlab_ssh_host']를 설정하여 사용자 정의할 수 있습니다. 이 설정은 이제 유효한 호스트 이름이어야 합니다. 이전에는 리포지터리 클론 URL에 사용되는 사용자 정의 호스트 이름과 포트를 보여주기 위해 임의의 문자열을 사용할 수 있었습니다.

    예를 들어, GitLab 16.5 이전에는 다음 설정이 작동했습니다: 

    gitlab_rails['gitlab_ssh_host'] = "gitlab.example.com:2222"

    GitLab 16.5부터는 호스트 이름과 포트를 별도로 지정해야 합니다: 

    gitlab_rails['gitlab_ssh_host'] = "gitlab.example.com"
gitlab_rails['gitlab_shell_ssh_port'] = 2222

    설정을 변경한 후에는 GitLab을 다시 구성해야 합니다: 

    sudo gitlab-ctl reconfigure

Geo 설치

Geo를 사용하는 설치에 특정 정보가 적용됩니다:

  • 16.3.0에서 일부 Prometheus 메트릭이 잘못 제거되어 대시보드와 경고를 망가뜨릴 수 있습니다.

    영향 받는 메트릭 16.5.2 및 이후에 메트릭 추가 16.3+에서 사용 가능한 대체
    geo_repositories_synced 예 geo_project_repositories_synced
    geo_repositories_failed 예 geo_project_repositories_failed
    geo_repositories_checksummed 예 geo_project_repositories_checksummed
    geo_repositories_checksum_failed 예 geo_project_repositories_checksum_failed
    geo_repositories_verified 예 geo_project_repositories_verified
    geo_repositories_verification_failed 예 geo_project_repositories_verification_failed
    geo_repositories_checksum_mismatch 아니요 없음 available
    geo_repositories_retrying_verification 아니요 없음 available
    • 영향을 받는 버전:
      • 16.3.0 ~ 16.5.1
    • 수정 사항이 포함된 버전:
      • 16.5.2 이후

    더 많은 정보는 이슈 429617에서 확인하세요.

  • 객체 리포지터리 검증은 GitLab 16.4에서 추가되었습니다. 이슈로 인해 일부 Geo 설치에서 메모리 사용량이 높게 보고되어 주요 GitLab 응용 프로그램이 응답하지 않을 수 있습니다.

    당신의 설치가 객체 리포지터리를 사용하도록 구성하고 GitLab 관리 객체 리포지터리 복제를 활성화한 경우에 영향을 받을 수 있습니다.

    이 문제가 해결될 때까지 객체 리포지터리 검증을 비활성화해야 합니다. 주요 사이트의 Rails 노드 중 하나에서 다음 명령을 실행하십시오: 

    sudo gitlab-rails runner 'Feature.disable(:geo_object_storage_verification)'

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    16.4 16.4.0 - 16.4.2 16.4.3
    16.5 16.5.0 - 16.5.1 16.5.2

  • GitLab 16.3에서 그룹 위키 검증이 추가된 후, 누락된 그룹 위키 리포지터리가 검증 실패로 잘못 표시되고 있습니다. 이 문제는 Geo 내에서 이러한 누락된 리포지터리의 유효하지 않은 내부 상태로 인한 것으로, 로그에서 오류 및 검증 진행에서 이러한 그룹 위키 리포지터리에 대한 실패한 상태가 잘못 표시됩니다.

    문제의 자세한 내용 및 해결 방법은 이슈 #426571에서 확인할 수 있습니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    16.3 모든 없음

  • 주요 사이트와 보조 사이트 간의 체크섬 불일치로 일부 프로젝트에서 확인 실패를 경험할 수 있습니다. 이에 대한 자세한 내용은 이슈에서 추적됩니다. 데이터는 올바르게 보조 사이트로 복제되고 있기 때문에 데이터 손실의 위험이 없습니다. 영향을 받는 프로젝트를 Geo 보조 사이트에서 클론하는 사용자는 항상 주요 사이트로 리디렉션됩니다. 현재는 알려진 해결책이 없습니다. 우리는 현재 문제를 해결하기 위해 노력하고 있습니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 16.6.0 - 16.6.5 16.6.6
    16.7 16.7.0 - 16.7.3 16.7.4

  • GitLab 16.5에서 발생한 버그로 인해 개인 스니펫이 보조 Geo 사이트로 복제되지 않습니다. 이로 인해 Geo 장애 발생 시 개인 스니펫 데이터의 손실이 발생할 수 있습니다. 문제의 자세한 내용 및 해결 방법은 이슈 #439933에서 확인할 수 있습니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    16.5 모든 없음
    16.6 모든 없음
    16.7 모든 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

16.4.0

  • 받은 버그 수정은 16.3에 도입된 데이터베이스 인덱스를 사용하는 그룹 경로를 업데이트합니다.

    16.4로 업그레이드하는 경우, 16.3보다 낮은 버전에서 ANALYZE packages_packages;를 데이터베이스에서 실행해야 사용할 수 있습니다.

  • GitLab 16.4 이후 업그레이드하는 동안 다음 오류가 발생할 수 있습니다: 

    main: == 20230830084959 ValidatePushRulesConstraints: migrating =====================
main: -- execute("SET statement_timeout TO 0")
main:    -> 0.0002초
main: -- execute("ALTER TABLE push_rules VALIDATE CONSTRAINT force_push_regex_size_constraint;")
main:    -> 0.0004초
main: -- execute("RESET statement_timeout")
main:    -> 0.0003초
main: -- execute("ALTER TABLE push_rules VALIDATE CONSTRAINT delete_branch_regex_size_constraint;")
rails 중단됨!
StandardError: 오류가 발생했습니다, 이후의 모든 마이그레이션 진행이 취소되었습니다:
  
PG::CheckViolation: 오류: 몇몇 행들에 의해 "push_rules"의 check constraint "delete_branch_regex_size_constraint"가 위배되었습니다

    이러한 제약 조건으로 오류가 발생할 수 있습니다:

    • author_email_regex_size_constraint
    • branch_name_regex_size_constraint
    • commit_message_negative_regex_size_constraint
    • commit_message_regex_size_constraint
    • delete_branch_regex_size_constraint
    • file_name_regex_size_constraint
    • force_push_regex_size_constraint

    오류를 수정하려면, 511자 제한을 초과하는 push_rules 테이블의 레코드를 찾으세요. 

    ;; `delete_branch_regex`를 사용한 필드 이름으로 대체하세요
SELECT id FROM push_rules WHERE LENGTH(delete_branch_regex) > 511;

    푸시 규칙이 프로젝트, 그룹 또는 인스턴스에 속하는지 확인하려면 Rails console에서 이 스크립트를 실행하세요 

    # `delete_branch_regex`를 사용한 필드 이름으로 대체하세요
long_rules = PushRule.where("length(delete_branch_regex) > 511")
  
array = long_rules.map do |lr|
  if lr.project
    "ID #{lr.id}를 가진 푸시 규칙은 프로젝트 #{lr.project.full_name}에 구성되어 있습니다."
  elsif lr.group
    "ID #{lr.id}를 가진 푸시 규칙은 그룹 #{lr.group.full_name}에 구성되어 있습니다."
  else
    "ID #{lr.id}를 가진 푸시 규칙은 인스턴스 수준에서 구성되어 있습니다."
  end
end
  
puts "총 장규한 규칙 수: #{array.count}"
puts array.join("\n")

    영향을 받는 푸시 규칙 레코드의 정규식 필드 값을 줄이고, 이후에 마이그레이션을 다시 시도하세요.

    너무 많은 영향을 받는 푸시 규칙이 있고, GitLab UI를 통해 업데이트할 수 없는 경우 GitLab 지원팀에 문의하세요.

  • PgBouncer가 있는 환경에서 일반적으로 백업을 우회해야 하지만, 이슈로 인해 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하는 gitlab-backup은 백업에 실패합니다. 대안은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    15.11 모두 없음
    16.0 모두 없음
    16.1 모두 없음
    16.2 모두 없음
    16.3 모두 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0부터 16.7.6까지 16.7.7
    16.8 16.8.0부터 16.8.3까지 16.8.4

자체 컴파일 설치

Geo 설치

Geo를 사용하는 설치에는 특정 정보가 적용됩니다:

  • 16.3.0에서 잘못 제거된 Prometheus 메트릭의 수는 대시보드와 경고를 중단할 수 있습니다:

    영향을 받는 메트릭 16.5.2 및 이후에 복구된 메트릭 16.3+에서 사용 가능한 대체
    geo_repositories_synced 예 geo_project_repositories_synced
    geo_repositories_failed 예 geo_project_repositories_failed
    geo_repositories_checksummed 예 geo_project_repositories_checksummed
    geo_repositories_checksum_failed 예 geo_project_repositories_checksum_failed
    geo_repositories_verified 예 geo_project_repositories_verified
    geo_repositories_verification_failed 예 geo_project_repositories_verification_failed
    geo_repositories_checksum_mismatch 아니요 사용 가능한 것 없음
    geo_repositories_retrying_verification 아니요 사용 가능한 것 없음
    • 영향을 받는 버전:
      • 16.3.0부터 16.5.1까지
    • 수정된 버전을 포함하는 버전:
      • 16.5.2 및 이후

    자세한 정보는 이슈 429617을 참조하세요.

  • GitLab 16.4에서 객체 리포지터리 검증이 추가되었습니다. 이슈로 인해 일부 Geo 설치에서는 메모리 사용량이 높아져 기본 사이트의 GitLab 애플리케이션이 응답하지 않을 수 있습니다.

    객체 리포지터리를 사용하도록 구성하고 GitLab 관리 객체 리포지터리 복제를 활성화한 경우 설치에 영향을 미칠 수 있습니다.

    이 문제가 수정되기 전까지 객체 리포지터리 검증을 비활성화하세요. 기본 사이트의 Rails 노드 중 하나에서 다음 명령을 실행하세요. 

    sudo gitlab-rails runner 'Feature.disable(:geo_object_storage_verification)'

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.4 16.4.0 - 16.4.2 16.4.3
    16.5 16.5.0 - 16.5.1 16.5.2

  • 동기화 상태가 대기 상태에 걸린 문제는 영향을 받는 아이템에 대한 계속된 동기화로 이어져 위험부담을 초래할 수 있습니다. 이 문제는 주로 리포지터리 동기화에 영향을 주지만 컨테이너 레지스트리 동기화에도 영향을 줄 수 있습니다. 데이터 손실 위험을 피하려면 수정된 버전으로 업그레이드하는 것이 좋습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.3 16.3.0 - 16.3.5 16.3.6
    16.4 16.4.0 - 16.4.1 16.4.2

  • GitLab 16.3에 그룹 위키 검증이 추가된 이후에, 누락된 그룹 위키 리포지터리가 잘못된 검증 실패로 표시됩니다. 이 문제는 실제 복제/검증 실패의 결과가 아니라 Geo 내부에 누락된 이러한 리포지터리들에 대한 잘못된 내부 상태로 로그 및 검증 진행상태에 대한 오류를 발생시키고 있습니다.

    이슈 #426571에서 문제와 대책에 대한 세부 정보를 참조하세요.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.3 모든 없음
    16.4 모든 없음
    16.5 16.5.0 - 16.5.1 16.5.2

  • 기본 사이트와 보조 사이트 간의 체크섬 불일치로 일부 프로젝트의 확인 실패를 경험할 수 있습니다. 데이터는 올바르게 보조 사이트로 복제되므로 데이터 손실 위험이 없습니다. 영향을 받는 프로젝트를 클론하는 사용자는 항상 주 사이트로 리디렉션됩니다. 현재 알려진 해결 방법은 없습니다. 문제에 대해 노력하고 있습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영햁을 받는 패치 릴리스 수정된 버전
    16.3 모두 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 16.6.0부터 16.6.5 16.6.6
    16.7 16.7.0부터 16.7.3 16.7.4

16.3.0

  • GitLab 16.3.5 이상으로 업데이트하세요. 이렇게 하면 문제 425971가 발생하지 않아 GitLab 16.3.3 및 16.3.4의 데이터베이스 디스크 공간을 지나치게 사용하는 것을 피할 수 있습니다.

  • 중복된 NPM 패키지가 데이터베이스에 없도록 하기 위해 고유한 인덱스가 추가되었습니다. 중복된 NPM 패키지가 있는 경우 16.1로 먼저 업그레이드해야 하거나 다음 오류에 직면할 가능성이 높습니다: PG::UniqueViolation: ERROR: could not create unique index "idx_packages_on_project_id_name_version_unique_when_npm".

  • Go 애플리케이션의 경우, crypto/tls: verifying certificate chains containing large RSA keys is slow (CVE-2023-29409) 에서 RSA 키의 경우 하드 리미트를 8192비트로 설정했습니다. GitLab의 Go 애플리케이션에서, RSA 키는 다음에 구성될 수 있습니다:

    업그레이드하기 전에 위 애플리케이션 중 하나에 대한 RSA 키의 크기를 확인해야 합니다(openssl rsa -in <your-key-file> -text -noout | grep "Key:").

  • BackfillCiPipelineVariablesForPipelineIdBigintConversion 백그라운드 마이그레이션이 EnsureAgainBackfillForCiPipelineVariablesPipelineIdIsFinished 포스트-디플로이 마이그레이션과 완료되었습니다. GitLab 16.2.0에서는 배치 백그라운드 마이그레이션을 ci_pipeline_variables 테이블의 bigint pipeline_id 값을 backfill하기 위해 소개되었습니다. 이 마이그레이션은 대규모 GitLab 인스턴스에서 오랜 시간이 걸릴 수 있습니다(한 경우에 5000만 행을 처리하는 데 4시간이 소요되었습니다). 업그레이드 다운타임을 방지하기 위해 업그레이드 전에 마이그레이션이 성공적으로 완료되었는지 확인하세요.

    데이터베이스 콘솔에서 ci_pipeline_variables 테이블의 크기를 확인할 수 있습니다: 

    select count(*) from ci_pipeline_variables;

  • 일반적으로 PgBouncer가있는 환경에서 백업을 가져야한다면 GITLAB_BACKUP_로 접두어가 붙은 변수를 설정하여 PgBouncer를 피할 필요가 있습니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하여 데이터베이스 백업이 실패합니다. 이 문제를 해결하기 위한 해결책은pg_dump를 직접 사용하는 것입니다.

    영향 받는 릴리스:

    영향을받는 마이너 릴리즈 영향을 받는 패치 릴리즈 수정됨
    15.11 모든 없음
    16.0 모든 없음
    16.1 모든 없음
    16.2 모든 없음
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

리눅스 패키지 설치

리눅스 패키지 설치에 특정 정보가 적용됩니다:

  • GitLab 16.0에서는 배포된 기본 Docker 이미지의 업그레이드를 발표했습니다. 이 Docker 이미지에는 새 버전의 OpenSSH Server가 포함되어 있습니다. 새 버전의 의도하지 않은 결과로 인해 기본적으로 SSH RSA SHA-1 서명을 수락하지 않도록 설정되었습니다. 이 문제는 매우 오래된 SSH 클라이언트를 사용하는 사용자에만 영향을 미칠 것으로 보입니다.

    SHA-1 서명을 사용할 수 없게되는 문제를 피하기 위해 사용자는 보안상의 이유로 SHA-1 서명 사용을 지양하는 것으로 록 상위 라이브러리에 의해 권장하는대로 SSH 클라이언트를 업데이트해야합니다.

    사용자가 즉시 SSH 클라이언트를 업그레이드할 수 없는 전환 기간을 허용하기 위해 GitLab 16.3 이상에서는 Dockerfile에 GITLAB_ALLOW_SHA1_RSA 환경 변수를 지원합니다. GITLAB_ALLOW_SHA1_RSA가 true로 설정된 경우 이러한 서명이 활성화됩니다.

    보안 모베를 촉진하고 상위 upstream 의견을 따르기를 원하기 때문에 이 환경 변수는 GitLab 17.0 때까지만 사용할 수 있습니다.

    자세한 내용은 다음을 참조하십시오:

Geo 설치

Geo를 사용하는 설치에 특정 정보가 적용됩니다:

  • 보조 Geo 사이트에서 Git pull이 최신 상태인 경우에도 주 Geo 사이트로 프록시되는 문제가 있습니다. 이 문제는 Git pull 요청을 가속화하기 위해 Geo를 사용하는 경우 영향을 받습니다.

    • 영향을받는 버전:
      • 16.3.0에서 16.3.3까지
    • 수정된 버전:
      • 16.3.4 및 이후

    자세한 내용은 이슈 425224를 참조하십시오.

  • 16.3.0에서는 잘못된 Prometheus 메트릭이 제거되어 대시 보드 및 경고가 중단될 수 있습니다.

    영향을받는 메트릭 16.5.2 및 이후에 복구됨 16.3 이상에서 사용 가능한 대체 품목
    geo_repositories_synced 예 geo_project_repositories_synced
    geo_repositories_failed 예 geo_project_repositories_failed
    geo_repositories_checksummed 예 geo_project_repositories_checksummed
    geo_repositories_checksum_failed 예 geo_project_repositories_checksum_failed
    geo_repositories_verified 예 geo_project_repositories_verified
    geo_repositories_verification_failed 예 geo_project_repositories_verification_failed
    geo_repositories_checksum_mismatch 아니요 사용 불가능
    geo_repositories_retrying_verification 아니요 사용 불가능
    • 영향을 받는 버전:
      • 16.3.0에서 16.5.1까지
    • 수정된 버전:
      • 16.5.2 및 이후

    자세한 내용은 이슈 429617를 참조하십시오.

  • 보류 중인 상태에서 동기화 상태가 멈추는 문제로 인해 영향을 받는 항목의 복제가 무기한으로 멈추어 데이터 손실이 발생할 수 있습니다.

  • 기본 사이트와 보조 사이트 간의 체크섬 불일치로 일부 프로젝트에서 검증 실패를 경험할 수 있습니다. 자세한 내용은 이슈 427493를 참조하십시오.

    영향을 받는 릴리스:

    영향을받는 마이너 릴리스 영향을 받는 패치 릴리스 수정됨
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 16.6.0 - 16.6.5 16.6.6
    16.7 16.7.0 - 16.7.3 16.7.4

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정됨
    16.3 16.3.0 - 16.3.5 16.3.6
    16.4 16.4.0 - 16.4.1 16.4.2

  • GitLab 16.3에 그룹 위키 검증이 추가된 후, 누락된 그룹 위키 리포지터리가 검증 실패로 잘못 표시됩니다. 이 문제는 실제 복제/검증 실패의 결과가 아니라 내부적으로 이 그룹 위키 리포지터리를 누락시키는 부적절한 내부 상태이며 Geo 안의 로그 및 검증 진행 상태에 대한 오류로 이어집니다.

    문제의 세부 내용과 해결책은 이슈 #426571에서 확인하세요.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정됨
    16.3 모든 없음
    16.4 모든 없음
    16.5 16.5.0 - 16.5.1 16.5.2

16.2.0

  • 레거시 LDAP 구성 설정은 NoMethodError: undefined method 'devise' for User:Class 에러를 발생시킬 수 있습니다. 이 오류는 tls_options 해시에 지정되지 않은 TLS 옵션(예: ca_file) 또는 레거시 gitlab_rails['ldap_host'] 옵션을 사용한 경우 발생합니다. 자세한 내용은 구성 우회 방법을 참조하세요.

  • GitLab 데이터베이스가 15.11.0 - 15.11.2 버전을 통해 생성되었거나 업그레이드된 경우, GitLab 16.2로 업그레이드하는 것이 실패합니다: 

    PG::UndefinedColumn: ERROR:  column "id_convert_to_bigint" of relation "ci_build_needs" does not exist
LINE 1: ...db_config_name:main*/ UPDATE "ci_build_needs" SET "id_conver...

    자세한 내용 및 해결 방법은 세부 사항 및 해결 방법을 참조하세요.

  • GitLab 16.2 이상으로 업그레이드하는 중 다음 오류가 발생할 수 있습니다: 

    main: == 20230620134708 ValidateUserTypeConstraint: migrating =======================
main: -- execute("ALTER TABLE users VALIDATE CONSTRAINT check_0dd5948e38;")
rake aborted!
StandardError: An error has occurred, all later migrations canceled:
PG::CheckViolation: ERROR:  check constraint "check_0dd5948e38" of relation "users" is violated by some row

    자세한 내용은 이슈 421629을 참조하세요.

  • GitLab 16.2 이상으로 업그레이드한 후 다음 오류가 발생할 수 있습니다: 

    PG::NotNullViolation: ERROR:  null value in column "source_partition_id" of relation "ci_sources_pipelines" violates not-null constraint

    이 문제를 해결하려면 Sidekiq 및 Puma 프로세스를 다시 시작해야 합니다.

  • 일반적으로 PgBouncer가 있는 환경에서 백업을 하려면 GITLAB_BACKUP_로 접두어가 지정된 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업에 실패합니다. 이 문제를 해결하기 위한 우회 방법은 pg_dump을 직접 사용하는 것입니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    15.11 모든 없음
    16.0 모든 없음
    16.1 모든 없음
    16.2 모든 없음
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Linux 패키지 설치

Linux 패키지 설치에 대한 특정 정보가 적용됩니다:

  • GitLab 16.2부터 PostgreSQL 13.11과 14.8이 함께 Linux 패키지와 함께 제공됩니다. 패키지 업그레이드 중 데이터베이스를 PostgreSQL 14로 업그레이드하지 않습니다. PostgreSQL 14로 업그레이드하려면 매뉴얼으로 해야 합니다: 

    sudo gitlab-ctl pg-upgrade -V 14

    PostgreSQL 14는 Geo 배포에서 지원되지 않으며 계획에 포함되어 있습니다.

  • 16.2에서는 Redis를 6.2.11에서 7.0.12로 업그레이드합니다. 이 업그레이드는 완전히 하위 호환성이 있을 것으로 예상됩니다.

    Redis는 gitlab-ctl reconfigure의 일부로 자동으로 다시 시작되지 않습니다. 따라서 사용자는 sudo gitlab-ctl restart redis를 실행하여 새로운 Redis 버전을 사용해야 합니다. 다시 설정 후 종료되기 전에 새로 설치된 Redis 버전이 실행 중이 아닌 경우 경고가 표시됩니다.

    Redis HA 클러스터를 업그레이드하는 방법에 대한 제로 다운타임 지침을 따르세요.

사용자 컴파일 설치

Geo 설치

Geo를 사용하는 설치에 대한 특정 정보가 적용됩니다:

  • 새로운 작업 artifact는 객체 리포지터리에 저장되고 direct_upload가 활성화되었을 경우 Geo에 의해 복제되지 않습니다. 이 버그는 GitLab 버전 16.1.4, 16.2.3, 16.3.0 및 이후에 수정되었습니다.
    • 영향을 받는 버전: GitLab 버전 16.1.0 - 16.1.3 및 16.2.0 - 16.2.2.
    • 영향을 받는 버전의 경우, 실제로 동기화된 것으로 보이는 아티팩트가 실제로 보조 사이트에서 누락될 수 있습니다. 영향을 받는 아티팩트는 16.1.5, 16.2.5, 16.3.1, 16.4.0 또는 이후 버전으로 업그레이드하면 자동으로 재동기화됩니다. 필요한 경우 영향을 받는 작업 artifact를 매뉴얼으로 재동기화할 수 있습니다.

보조 사이트에서 LFS 개체 복제가 완전히 동기화된 상태에서도 기본 사이트에서 다운로드됩니다.

LFS 객체에 대한 Geo 프록시 로직의 버그로 인해 보조 사이트로부터의 모든 LFS 복제 요청이 기본 사이트로 프록시되며 보조 사이트가 최신 상태인 경우에도 이것은 증가된 부하와 사용자의 LFS 객체에 대한 더 긴 액세스 시간으로 이어질 수 있습니다.

GitLab 15.1에서 프록시 기능이 기본적으로 활성화되었습니다.

영향을 받지 않는 경우:

  • LFS 객체를 사용하지 않도록 설정한 경우
  • 원격 사용자의 가속화를 위해 Geo를 사용하지 않는 경우
  • 원격 사용자의 가속화를 위해 Geo를 사용하지만 프록시 기능을 비활성화한 경우
영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정 버전
15.1 - 16.2 모든 16.3 및 이후 버전

해결 방법: 프록시 기능을 비활성화하는 것이 가능한 해결 방법입니다. 클론 시점에서 복제되지 않은 LFS 파일을 보조 사이트가 제공하지 못하는 문제가 있습니다.

16.1.0

  • BackfillPreparedAtMergeRequests 배경 마이그레이션이 FinalizeBackFillPreparedAtMergeRequests 포스트-디플로이 마이그레이션으로 완료되었습니다. GitLab 15.10.0에서는 일괄 배경 마이그레이션을 소개하여 준비된_at 값을 merge_requests` 테이블에 채우기 위한 작업 마이그레이션을 도입했습니다. 이 마이그레이션은 더 큰 GitLab 인스턴스에서 여러 일이 소요될 수 있습니다. 16.1.0으로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하세요.
  • GitLab 16.1.0에는 일괄 배경 마이그레이션 MarkDuplicateNpmPackagesForDestruction이 포함되어 중복 NPM 패키지를 표시하는데 사용됩니다. 16.3.0 이상으로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하세요.

  • BackfillCiPipelineVariablesForBigintConversion 배경 마이그레이션이 EnsureBackfillBigintIdIsCompleted 포스트-디플로이 마이그레이션으로 완료되었습니다. GitLab 16.0.0에서는 일괄 배경 마이그레이션을 도입하여 ci_pipeline_variables 테이블의 bigint id 값을 채우기 위한 작업 마이그레이션을 도입했습니다. 이 마이그레이션은 더 큰 GitLab 인스턴스에서 오랜 시간이 걸릴 수 있습니다. 긴 시간 동안 업그레이드 다운타임을 피하기 위해 16.1으로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하세요.

    데이터베이스 콘솔에서 ci_pipeline_variables 테이블의 크기를 확인할 수 있습니다.: 

    select count(*) from ci_pipeline_variables;

자체 컴파일 설치

  • Puma worker killer와 관련된 설정을 포함하고 있던 puma.rb 구성 파일을 삭제해야 합니다. 해당 설정은 제거되었기 때문입니다. 자세한 내용은 puma.rb.example 파일을 참조하세요.

  • PgBouncer가 있는 환경에서는 일반적으로 GITLAB_BACKUP_로 접두어가 지정된 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업에 실패합니다. 해결책은 pg_dump를 직접 사용하는 것입니다. 영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 릴리스
    15.11 모두 없음
    16.0 모두 없음
    16.1 모두 없음
    16.2 모두 없음
    16.3 모두 없음
    16.4 모두 없음
    16.5 모두 없음
    16.6 모두 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Geo 설치

세부 사항: Tier: Premium, Ultimate Offering: Self-Managed

Geo를 사용하는 설치에는 특정 정보가 적용됩니다:

  • 일부 프로젝트 가져오기는 프로젝트 생성 시 위키 리포지터리를 초기화하지 않습니다. 자세한 내용 및 해결 방법은 자세한 내용 및 해결 방법을 참조하십시오.
  • 프로젝트 디자인을 SSF로 마이그레이션했기 때문에 실패한 검증으로 표시된 누락된 디자인 리포지터리를 잘못된 상태로 플래그 처리하고 있습니다. 이 문제는 실제 복제/검증 실패가 아니라 이러한 누락된 리포지터리에 대한 내부 상태가 잘못되어 있고 로그 및 검증 진행이 이러한 디자인 리포지터리의 실패한 상태를 보고하며 에러가 발생합니다. 프로젝트를 가져오지 않았더라도 이 문제에 영향을 받을 수 있습니다.
    • 영향을 받는 버전: GitLab 버전 16.1.0 - 16.1.2
    • 수정된 버전이 포함된 버전: GitLab 16.1.3 및 이후
  • 새로운 작업 artifacts는 direct_upload가 활성화되어 있고 작업 artifacts가 객체 리포지터리에 저장되도록 구성된 경우 Geo에 의해 복제되지 않습니다. 이 버그는 GitLab 버전 16.1.4, 16.2.3, 16.3.0 및 이후에서 수정되었습니다.
    • 영향을 받는 버전: GitLab 버전 16.1.0 - 16.1.3 및 16.2.0 - 16.2.2.
    • 영향을 받는 버전을 실행하는 동안 동기화된 것처럼 보이는 artifacts가 실제로 누락 될 수 있습니다. 영향을 받은 artifacts는 16.1.5, 16.2.5, 16.3.1, 16.4.0 또는 이후 버전으로 업그레이드하면 자동으로 재동기화됩니다. 필요한 경우 영향을 받는 작업 artifacts를 매뉴얼으로 재동기화할 수 있습니다.
    • 보조 사이트에서 LFS 객체를 복제할 때 보조 사이트가 완전히 동기화되었더라도 주 사이트에서 다운로드됩니다. 자세한 내용 및 해결 방법을 참조하세요.

프로젝트 생성시 위키 리포지터리 초기화되지 않음

영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 릴리스
15.11 모두 없음
16.0 모두 없음
16.1 16.1.0 - 16.1.2 16.1.3 및 이후

일부 프로젝트 가져오기는 프로젝트 생성 시 위키 리포지터리를 초기화하지 않습니다. 프로젝트 위키를 SSF로 마이그레이션한 이후부터는 실패한 검증으로 표시된 누락된 위키 리포지터리가 잘못된 상태로 플래그 처리됩니다. 이것은 실제 복제/검증 실패의 결과가 아니며 이러한 누락된 리포지터리에 대한 내부 상태가 잘못되어 있고 로그 및 검증 진행이 이러한 위키 리포지터리의 실패한 상태를 보고하며 에러가 발생합니다. 프로젝트를 가져오지 않은 경우 이 문제에 영향을 받지 않습니다.

16.0.0

  • /etc/gitlab/gitlab.rb 파일에 비ASCII 문자가 포함되어 있으면 Sidekiq가 충돌합니다. 이슈 412767의 해결책을 참조하여 이 문제를 해결할 수 있습니다.
  • 기본적으로 Sidekiq 작업은 default 및 mailers 대기열로만 라우팅되며, 그 결과로 모든 Sidekiq 프로세스가 모든 대기열에서 작업이 처리되도록 듣게 됩니다. 이 동작은 라우팅 규칙을 구성하지 않았다면 적용되지 않습니다.
  • GitLab 도커 이미지를 실행하려면 Docker 20.10.10 이상이 필요합니다. 이전 버전은 시작 시 오류가 발생합니다.

  • Azure 리포지터리를 사용하는 컨테이너 레지스트리는 태그가 0개인 상태일 수 있습니다. 중단 변경 지침을 따라 이 문제를 해결할 수 있습니다.

  • PgBouncer가 있는 환경에서는 일반적으로 GITLAB_BACKUP_로 접두어가 지정된 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업에 실패합니다. 해결책은 pg_dump를 직접 사용하는 것입니다. 영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 릴리스
    15.11 모두 없음
    16.0 모두 없음
    16.1 모두 없음
    16.2 모두 없음
    16.3 모두 없음
    16.4 모두 없음
    16.5 모두 없음
    16.6 모두 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Linux 패키지 설치

리눅스 패키지 설치에 특정 정보가 적용됩니다:

  • PostgreSQL 12의 실행 파일이 제거되었습니다.

    업그레이드 전, 리눅스 패키지 설치의 관리자는 PostgreSQL 13를 사용하는지 확인해야 합니다.

  • GitLab에서 번들로 제공되던 Grafana는 사용이 중단되었으며 더는 지원되지 않습니다. GitLab 16.3에서 제거되었습니다.

  • 이로 openssh-server가 1:8.9p1-3로 업그레이드되었습니다.

    오래된 OpenSSH 클라이언트에서 ssh-keyscan -t rsa를 사용하여 공개 키 정보를 가져오는 것은 더 이상 유효하지 않습니다. 이는 OpenSSH 8.7 릴리스 노트에 나열된 사용 중단 사항 때문입니다.

    해결책으로 다른 키 유형을 사용하거나 클라이언트 OpenSSH를 버전 8.7 이상으로 업그레이드하여 사용하세요.

  • Praefect 구성을 새 구조로 이전하여 모든 praefect['..'] 설정이 GitLab 16.0 이후에 계속 작동하도록하세요.

  • Gitaly 구성을 새 구조로 이전하여 모든 gitaly['..'] 설정이 GitLab 16.0 이후에 계속 작동하도록하세요.

Geo 설치

Tier: Premium, Ultimate Offering: Self-Managed

Geo 사용 설치에 특정 정보가 적용됩니다:

  • 일부 프로젝트 가져오기는 프로젝트가 생성될 때 위키 리포지터리를 초기화하지 않습니다. 상세정보 및 해결 방법을 확인하세요.
  • 보조 사이트에서 LFS 객체를 복제하면 보조 사이트가 완전히 동기화되었을 때에도 기본 사이트에서 다운로드됩니다. 상세정보 및 해결 방법을 확인하세요.

Gitaly 구성 구조 변경

GitLab 16.0에서 리눅스 패키지의 Gitaly 구성 구조가 변경되어 자체 컴파일 설치에서 사용되는 Gitaly 구성 구조와 일관성을 갖추게 됩니다.

이 변경으로 인해 gitaly['configuration'] 하위의 단일 해시가 대부분의 Gitaly 구성을 보유하게 됩니다. 일부 gitaly['..'] 구성 옵션은 GitLab 16.0 이후에 계속 사용됩니다:

  • enable
  • dir
  • bin_path
  • env_directory
  • env
  • open_files_ulimit
  • consul_service_name
  • consul_service_meta

기존 구성을 새 구조로 이동하여 마이그레이션하세요. git_data_dirs는 GitLab 17.0까지 지원됩니다. 새 구조는 GitLab 15.10부터 지원됩니다.

새 구조로 마이그레이션

caution
Gitaly 클러스터를 실행 중인 경우, 먼저 Praefect를 새 구성 구조로 마이그레이션하세요. 이 변경이 테스트되면 Gitaly 노드를 진행하세요. Gitaly가 구성 구조 변경의 일부로 잘못 구성된 경우, 리포지터리 검증이 Gitaly 클러스터 작동에 필요한 메타데이터를 삭제합니다.(https://gitlab.com/gitlab-org/gitaly/-/issues/5529) 이를 방지하기 위해 Praefect에서 일시적으로 리포지터리 확인을 비활성화하세요.
  1. Gitaly 클러스터를 실행 중이면 모든 Praefect 노드에서 리포지터리 확인이 비활성화되어 있는지 확인하세요. verification_interval: 0으로 구성하고, gitlab-ctl reconfigure를 적용하세요.
  2. 구성에 새 구조를 적용할 때
    • ...을 이전 키의 값으로 바꿉니다.
    • storage를 구성할 때, 경로에 /repositories를 추가해야 함을 아래 설명된대로 문서화하세요. 이것을 빠뜨리면 구성이 수정될 때까지 Git 리포지터리에 접근할 수 없습니다. 이러한 잘못 구성으로 인해 메타데이터가 삭제되고 리포지터리 확인이 비활성화된 이유입니다.
    • 이전에 값을 구성하지 않은 키는 건너뛰세요.
    • 모든 해시 키에 대해 마지막에 쉼표를 포함하세요. 키가 다시 정렬되거나 추가 키가 추가될 때 해시가 유효하게 유지되도록 권장됩니다.
  3. 변경사항을 gitlab-ctl reconfigure로 적용하세요.
  4. GitLab에서 Git 리포지터리 기능을 테스트하세요.
  5. 이전에 마이그레이션한 후 구성에서 이전 키를 제거한 다음, gitlab-ctl reconfigure를 다시 실행하세요.
  6. Gitaly 클러스터를 실행 중이면 Praefect 리포지터리 확인을 다시 설정하세요. verification_interval: 0을 제거하세요.

새 구조는 이전 키가 새 키 위에 설명되는 주석과 함께 아래에 문서화되어 있습니다. 

gitaly['configuration'] = {
  # gitaly['socket_path']
  socket_path: ...,
  # gitaly['runtime_dir']
  runtime_dir: ...,
  # gitaly['listen_addr']
  listen_addr: ...,
  # gitaly['prometheus_listen_addr']
  prometheus_listen_addr: ...,
  # gitaly['tls_listen_addr']
  tls_listen_addr: ...,
  tls: {
    # gitaly['certificate_path']
    certificate_path: ...,
    # gitaly['key_path']
    key_path: ...,
  },
  # ... (기존 키에 대한 설명)
}

Praefect 구성 구조 변경

Linux 패키지의 Praefect 구성 구조는 변경되어 GitLab 16.0에서 자체 컴파일된 설치에 사용되는 Praefect 구성 구조와 일관성을 유지합니다.

이 변경으로 praefect['configuration'] 하위에 단일 해시가 대부분의 Praefect 구성을 보유하게 됩니다. 일부 praefect['..'] 구성 옵션은 GitLab 16.0 이후에도 계속 사용됩니다:

  • enable
  • dir
  • log_directory
  • env_directory
  • env
  • wrapper_path
  • auto_migrate
  • consul_service_name

기존 구성을 새 구조로 이동하여 마이그레이션합니다. 새 구조는 GitLab 15.9부터 지원됩니다.

새 구조로 마이그레이션

caution
먼저 Praefect를 새 구성 구조로 마이그레이션하세요. 이 변경이 테스트된 후 Gitaly 노드를 계속 진행하세요. 구성 구조 변경의 일환으로 Gitaly가 잘못 구성된 경우, 리포지터리 확인가 Gitaly 클러스터 작업에 필요한 메타데이터를 삭제합니다. 구성 오류를 방지하려면 Praefect에서 임시로 리포지터리 확인을 비활성화하세요.
  1. 구성에 새 구조를 적용할 때:
    • ...을(를) 이전 키의 값으로 대체합니다.
    • 아래에 표시된대로 verification_interval: 0를 사용하여 리포지터리 확인을 비활성화합니다.
    • 이전에 값을 구성하지 않은 경우 키를 건너뜁니다.
    • 모든 해시 키에 대한 후행 쉼표를 권장하여 키가 재정렬되거나 추가 키가 추가될 때 해시가 유효한 상태를 유지합니다.
  2. 변경 사항을 gitlab-ctl reconfigure로 적용합니다.
  3. GitLab에서 Git 리포지터리 기능을 테스트합니다.
  4. 마이그레이션 후에 이전 키를 구성에서 제거한 다음 gitlab-ctl reconfigure를 다시 실행합니다.

새 구조는 아래에 문서화되어 있으며, 새 키 위에 이전 키가 설명된 주석으로 설명되어 있습니다. 

praefect['configuration'] = {
  # praefect['listen_addr']
  listen_addr: ...,
  # praefect['socket_path']
  socket_path: ...,
  # praefect['prometheus_listen_addr']
  prometheus_listen_addr: ...,
  # praefect['tls_listen_addr']
  tls_listen_addr: ...,
  # praefect['separate_database_metrics']
  prometheus_exclude_database_from_default_metrics: ...,
  auth: {
    # praefect['auth_token']
    token: ...,
    # praefect['auth_transitioning']
    transitioning: ...,
  },
  logging: {
    # praefect['logging_format']
    format: ...,
    # praefect['logging_level']
    level: ...,
  },
  failover: {
    # praefect['failover_enabled']
    enabled: ...,
  },
  background_verification: {
    # praefect['background_verification_delete_invalid_records']
    delete_invalid_records: ...,
    # praefect['background_verification_verification_interval']
    #
    # 중요:
    # Praefect 재구성의 일환으로이 기능을 비활성화합니다.
    # 위에 관련 내용을 읽으세요.
    #
    verification_interval: 0,
  },
  reconciliation: {
    # praefect['reconciliation_scheduling_interval']
    scheduling_interval: ...,
    # praefect['reconciliation_histogram_buckets']. 이전 값은 문자열로 구성되었습니다
    # 예: '[0, 1, 2]' 새 값은 [0, 1, 2]와 같은 배열이어야 합니다.
    histogram_buckets: ...,
  },
  tls: {
    # praefect['certificate_path']
    certificate_path: ...,
   # praefect['key_path']
    key_path: ...,
  },
  database: {
    # praefect['database_host']
    host: ...,
    # praefect['database_port']
    port: ...,
    # praefect['database_user']
    user: ...,
    # praefect['database_password']
    password: ...,
    # praefect['database_dbname']
    dbname: ...,
    # praefect['database_sslmode']
    sslmode: ...,
    # praefect['database_sslcert']
    sslcert: ...,
    # praefect['database_sslkey']
    sslkey: ...,
    # praefect['database_sslrootcert']
    sslrootcert: ...,
    session_pooled: {
      # praefect['database_direct_host']
      host: ...,
      # praefect['database_direct_port']
      port: ...,
      # praefect['database_direct_user']
      user: ...,
      # praefect['database_direct_password']
      password: ...,
      # praefect['database_direct_dbname']
      dbname: ...,
      # praefect['database_direct_sslmode']
      sslmode: ...,
      # praefect['database_direct_sslcert']
      sslcert: ...,
      # praefect['database_direct_sslkey']
      sslkey: ...,
      # praefect['database_direct_sslrootcert']
      sslrootcert: ...,
    }
  },
  sentry: {
    # praefect['sentry_dsn']
    sentry_dsn: ...,
    # praefect['sentry_environment']
    sentry_environment: ...,
  },
  prometheus: {
    # praefect['prometheus_grpc_latency_buckets']. 이전 값은 문자열로 구성되었습니다
    # 예: '[0, 1, 2]' 새 값은 [0, 1, 2]와 같은 배열이어야 합니다.
    grpc_latency_buckets: ...,
  },
  # praefect['graceful_stop_timeout']
  graceful_stop_timeout: ...,
  # praefect['virtual_storages']. 이전 값은 해시 맵이지만 새 값은 배열입니다.
  virtual_storage: [
    {
      # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]. 이전에 키는
      # 'virtual_storages' 해시의 키였습니다.
      name: ...,
      # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]['nodes'][NODE_NAME]. 이전 값은 해시 맵
      # 새 값은 배열입니다.
      node: [
        {
          # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]['nodes'][NODE_NAME]. NODE_NAME 키를 사용하여
          # 리포지터리를 사용합니다.
          storage: ...,
          # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]['nodes'][NODE_NAME]['address'].
          address: ...,
          # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]['nodes'][NODE_NAME]['token'].
          token: ...,
        },
      ],
    }
  ]
}

장기 실행 사용자 유형 데이터 변경

GitLab 16.0은 users 테이블에 많은 레코드가 있는 대형 GitLab 인스턴스에 필수적인 업데이트입니다.

임계값은 30,000 사용자로 다음을 포함합니다:

  • 개발자 및 기타 사용자(활성, 차단, 승인 대기 중인 사용자 포함)
  • 프로젝트 및 그룹 액세스 토큰의 봇 계정

GitLab 16.0에서는 일괄 배치 백그라운드 마이그레이션을 NULL에서 0으로 user_type 값을 마이그레이션하도록 변경되었습니다. 이 마이그레이션은 큰 GitLab 인스턴스에서 여러 일이 걸릴 수 있습니다. 16.1.0 이상으로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하세요.

GitLab 16.1에서는 16.0 MigrateHumanUserType 백그라운드 마이그레이션이 완료되도록 하는 FinalizeUserTypeMigration 마이그레이션이 도입되어, 완료되지 않은 경우 업그레이드 중에 16.0 변경을 동기적으로 실행합니다.

GitLab 16.2는 NOT NULL 데이터베이스 제약조건을 구현하여 16.0 마이그레이션이 완료되지 않았을 경우 실패합니다.

16.0이 건너뛰어졌거나(또는 16.0 마이그레이션이 완료되지 않은 경우) 이후의 Linux 패키지(Omnibus) 및 Docker 업그레이드는 1시간 후에 실패할 수 있습니다: 

FATAL: Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails]
[..]
Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:

이 문제에 대한 고정 순방법이 있습니다.

고정 작업이 데이터베이스 변경을 완료하는 동안 GitLab은 사용할 수 없는 상태일 가능성이 높습니다. 이 오류는 데이터베이스 스키마와 호환되지 않는 애플리케이션 코드를 수행하는 Sidekiq와 Puma로 인한 것입니다.

고정 프로세스의 끝에서 Sidekiq와 Puma가 다시 시작되어 이 문제를 해결합니다.

16.2 이상으로 업그레이드 시 정의되지 않은 열 오류

GitLab 15.11의 버그로 인해, Self-Managed 인스턴스에서 데이터베이스 변경이 잘못되었습니다. 자세한 내용은 이슈 408835를 참조하세요.

만약 GitLab 인스턴스가 먼저 15.11.0, 15.11.1 또는 15.11.2로 업그레이드된 경우 데이터베이스 스키마가 잘못되어 GitLab 16.2 이상으로 업그레이드하면 오류가 발생합니다. 이전 수정 사항은 반드시 적용되어야 합니다: 

PG::UndefinedColumn: ERROR:  column "id_convert_to_bigint" of relation "ci_build_needs" does not exist
LINE 1: ...db_config_name:main*/ UPDATE "ci_build_needs" SET "id_conver...

GitLab 15.11.3에는 이 버그에 대한 수정 사항이 포함되어 있지만, 이미 이전의 15.11 버전을 실행 중인 인스턴스에는 문제가 해결되지 않습니다.

인스턴스가 영향을 받았는지 확실하지 않은 경우 데이터베이스 콘솔에서 해당 열을 확인하세요: 

select pg_typeof (id_convert_to_bigint) from public.ci_build_needs limit 1;

해결책이 필요한 경우, 이 쿼리는 실패합니다: 

ERROR:  column "id_convert_to_bigintd" does not exist
LINE 1: select pg_typeof (id_convert_to_bigintd) from public.ci_buil...

영향을 받지 않는 인스턴스는 다음을 반환합니다: 

 pg_typeof
-----------
 bigint

이 문제에 대한 해결책은 GitLab 인스턴스의 데이터베이스 스키마가 최근에 생성된 경우 다릅니다:

설치 버전 해결책
15.9 이하 15.9
15.10 15.10
15.11 15.11

대부분의 인스턴스는 15.9 절차를 사용해야 합니다. 매우 새로운 인스턴스만 15.10이나 15.11 절차를 필요로 합니다. 백업 및 복원을 사용하여 GitLab을 마이그레이션했다면, 데이터베이스 스키마는 원본 인스턴스에서 가져옵니다. 소스 인스턴스에 따라 해결책을 선택하세요.

다음 절에 있는 명령어들은 리눅스 패키지 설치를 위한 것이며, 다른 설치 유형에 대해 다를 수 있습니다:

Docker
  • sudo 는 생략합니다.

  • GitLab 컨테이너로 이동하여 동일한 명령을 실행합니다: 

    docker exec -it <container-id> bash
Self-compiled (source)
Helm chart (Kubernetes)

해결 방법: 15.9 이하로 생성된 인스턴스 

# 스키마 복원
sudo gitlab-psql -c "DELETE FROM schema_migrations WHERE version IN ('20230130175512', '20230130104819');"
sudo gitlab-rake db:migrate:up VERSION=20230130175512
sudo gitlab-rake db:migrate:up VERSION=20230130104819

# 백그라운드 마이그레이션 다시 예약
sudo gitlab-rake db:migrate:down VERSION=20230130202201
sudo gitlab-rake db:migrate:down VERSION=20230130110855
sudo gitlab-rake db:migrate:up VERSION=20230130202201
sudo gitlab-rake db:migrate:up VERSION=20230130110855

해결 방법: 15.10으로 생성된 인스턴스 

# sent_notifications에 대한 스키마 복원
sudo gitlab-psql -c "DELETE FROM schema_migrations WHERE version = '20230130175512';"
sudo gitlab-rake db:migrate:up VERSION=20230130175512

# sent_notifications를 위한 백그라운드 마이그레이션 다시 예약
sudo gitlab-rake db:migrate:down VERSION=20230130202201
sudo gitlab-rake db:migrate:up VERSION=20230130202201

# ci_build_needs에 대한 스키마 복원
sudo gitlab-rake db:migrate:down VERSION=20230321163547
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230321163547');"

해결 방법: 15.11으로 생성된 인스턴스 

# sent_notifications에 대한 스키마 복원
sudo gitlab-rake db:migrate:down VERSION=20230411153310
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230411153310');"

# ci_build_needs에 대한 스키마 복원
sudo gitlab-rake db:migrate:down VERSION=20230321163547
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230321163547');"