Go 버전 관리

GitLab에서 Go 바이너리의 버전 관리, 업그레이드 절차, 지원 버전 정책 및 의존성 컴포넌트 업데이트 방법을 설명합니다.

개요 # GitLab Runner 와 Security Projects 를 제외한 모든 Go 바이너리는 Distribution 팀 이 관리하는 프로젝트에서 빌드됩니다. Omnibus GitLab 프로젝트는 모든 바이너리를 포함하는 단일 모놀리식 운영 체제 패키지를 생성하며, Cloud-Native GitLab (CNG) 프로젝트는 Helm Charts 또는 GitLab Operator에 의해 배포 및 구성되는 Docker 이미지 세트를 게시합니다. 배포되는 Go 버전에 대한 테스트 # Go를 사용하는 모든 프로젝트의 테스트 매트릭스에는 Distribution이 배포하는 버전이 포함되어야 합니다. 다음에서 GO_VERSION 으로 설정된 Go 버전을 확인하세요: Linux 패키지 빌드 . Cloud-Native GitLab (CNG) . 여러 Go 버전 지원 # 개별 Go 프로젝트는 다음과 같은 이유로 여러 Go 버전을 지원해야 할 수 있습니다: Go의 새 버전이 릴리스되면, 이를 CI 파이프라인에 통합하여 향후 호환성을 검증해야 합니다. 백포트를 가능하게 하려면, 활성 마일스톤을 제외한 최신 3개의 마이너 GitLab 릴리스에서 Distribution이 배포하는 Go 버전을 지원해야 합니다. Go 버전 업데이트 # 항상 다음을 지켜야 합니다: Omnibus GitLab과 Cloud Native GitLab에 동일한 Go 버전을 사용합니다. 지원되는 버전 을 사용합니다. 보안 수정 사항을 최신 상태로 유지하기 위해 해당 버전의 가장 최신 패치 수준을 사용합니다. 버전을 변경하면 컴파일되는 모든 프로젝트에 영향을 미치므로, 패키지 빌더가 새 Go 버전을 사용하도록 변경하기 전에 모든 프로젝트가 새 Go 버전에 대한 테스트를 수행하도록 업데이트되었는지 확인하는 것이 중요합니다. Go의 호환성 약속 에도 불구하고, 마이너 버전 간의 변경 사항은 프로젝트에서 버그를 노출하거나 문제를 일으킬 수 있습니다. go.mod의 버전 # 주요 요구 사항: 패치 버전으로 항상 0 을 사용합니다(예: go 1.23.4 가 아닌 go 1.23.0 ). CNG 및 Omnibus에서 사용하는 버전보다 더 최신 버전을 설정하지 마세요. 그렇지 않으면 빌드 오류가 발생합니다. go.mod 파일에서 toolchain 디렉티브를 사용하지 마세요. 이는 다른 Go 버전으로 프로젝트를 빌드할 때 문제를 일으켰습니다. go.mod 의 Go 버전은 모든 다운스트림 프로젝트에 영향을 미칩니다. 최소 Go 버전을 지정하면, 패키지를 가져오는 모든 프로젝트는 해당 버전 이상을 사용해야 합니다. 이는 다른 Go 버전 제약 조건을 가진 프로젝트에서 불가능한 상황을 만들 수 있습니다. 예를 들어, CNG가 Go 1.23.4를 사용하지만 프로젝트가 최소 요구 버전으로 go 1.23.5 를 선언하면, CNG는 패키지 빌드에 실패합니다. 마찬가지로, 패키지를 가져오는 다른 프로젝트들도 Go 버전을 업그레이드해야 하는데, 이것이 불가능할 수 있습니다. CNG와 Omnibus에서 사용되는 버전을 알아