gitlab-org/gitlab프로젝트의 Merge Request(MR) 테스트omnibus-gitlab프로젝트의 MR 테스트- GitLab 컴포넌트의 특정 브랜치 또는 버전 사용
- GitLab 컴포넌트의 특정 미러 또는 포크 사용
- 다른 운영 체제용 패키지 빌드
GitLab 팀원용 공식 빌드 인프라 사용 가이드
만약 당신이 GitLab 팀원이라면, 빌드 인프라에 액세스하거나 그러한 액세스가 있는 동료를 통해 빌드 패키지를 만들 수 있습니다.
gitlab-org/gitlab 프로젝트의 Merge Request(MR) 테스트
gitlab-org/gitlab 프로젝트에서 MR이 있다면, 해당 MR을 패키지나 Docker 이미지를 사용하여 테스트할 수 있습니다.
당신의 MR에 해당하는 CI 파이프라인에서, qa 단계의 e2e:package-and-test 작업을 실행하여 다음을 트리거하세요:
-
QA 미러에서
omnibus-gitlab의 하향 파이프라인, 여기에서 Ubuntu 22.04 패키지 및 테스트용 올인원 Docker 이미지를 얻을 수 있습니다. - 또한 이러한 아티팩트를 사용하여
gitlab-qa실행.
omnibus-gitlab 프로젝트의 MR 테스트
omnibus-gitlab 프로젝트에서 MR이 있다면, 해당 MR을 패키지나 Docker 이미지를 사용하여 테스트할 수 있습니다.
GitLab 프로젝트와 유사하게, omnibus-gitlab의 MR에 대한 파이프라인은 패키지 또는 Docker 이미지를 얻기 위한 매뉴얼 작업을 포함합니다. Trigger:ce-package 및 Trigger:ee-package 작업은 CE 및 EE 패키지 및 Docker 이미지를 빌드하고 QA 실행을 수행합니다.
GitLab 컴포넌트의 특정 브랜치 또는 버전 사용
GitLab Rails 또는 Gitaly와 같은 주요 GitLab 컴포넌트의 버전은 다음에 의해 제어됩니다:
-
omnibus-gitlab리포지터리의*_VERSION파일. - 빌드 중에 존재하는
*_VERSION환경 변수.
자세한 정보는 다음 표를 확인하세요.
| 파일 이름 | 환경 변수 | 설명 |
|---|---|---|
VERSION
| GITLAB_VERSION
| GitLab Rails 애플리케이션의 Git 참조를 제어합니다. 기본적으로 GitLab-FOSS 리포지터리의 master 브랜치를 가리킵니다. 만약 GitLab 리포지터리를 사용하려면, ee 환경 변수를 true로 설정하세요.
|
GITALY_SERVER_VERSION
| GITALY_SERVER_VERSION
| Gitaly 리포지터리의 Git 참조. |
GITLAB_PAGES_VERSION
| GITLAB_PAGES_VERSION
| GitLab Pages 리포지터리의 Git 참조. |
GITLAB_SHELL_VERSION
| GITLAB_SHELL_VERSION
| GitLab Shell 리포지터리의 Git 참조. |
GITLAB_ELASTICSEARCH_INDEXER_VERSION
| GITLAB_ELASTICSEARCH_INDEXER_VERSION
| GitLab Elasticsearch Indexer 리포지터리의 Git 참조. EE 빌드에서만 사용됩니다. |
GITLAB_KAS_VERSION
| GITLAB_KAS_VERSION
| GitLab Kubernetes Agent Server 리포지터리의 Git 참조. |
GitLab MR에서 e2e:package-and-test 작업을 실행 중이라면, GITLAB_VERSION 환경 변수가 해당 파이프라인에 해당하는 커밋 SHA로 설정됩니다. 다른 환경 변수는 명시되지 않으면 해당 파일에서 불러와 트리거된 파이프라인으로 전달됩니다.
*_VERSION 파일을 우선합니다.임시로 컴포넌트 버전 지정하기
임시로 컴포넌트 버전을 지정하는 방법은 다음 중 하나를 사용하세요:
-
*_VERSION파일을 편집하고, 해당 변경을 되돌리기 전에 MR이 Merge 준비 상태로 표시되기 전에 커밋 및 푸시하여 파이프라인을 시작합니다. 이 변경을 되돌릴 수 있도록 MR에서 이 차이에 대한 미해결한 토론을 시작하는 것을 권장합니다. -
.gitlab-ci.yml파일에서 환경 변수를 설정하고, 이 변경을 되돌리기 전에 MR이 Merge 준비 상태로 표시되기 전에 커밋 및 푸시하여 파이프라인을 시작합니다. 이 변경을 되돌릴 수 있도록 MR에서 이 차이에 대한 미해결한 토론을 시작하는 것을 권장합니다. -
Git push 옵션으로 환경 변수를 전달합니다.
git push <REMOTE> -o ci.variable="<ENV_VAR>=<VALUE>" # 여러 변수를 전달하는 경우 git push <REMOTE> -o ci.variable="<ENV_VAR_1>=<VALUE_1>" -o ci.variable="<ENV_VAR_2>=<VALUE_2>"참고: 변경 사항을 푸시할 내용이 있는 경우에만 작동합니다. 원격 리포지터리가 이미 로컬 브랜치로 업데이트된 경우에는 새로운 파이프라인이 생성되지 않습니다. -
환경 변수를 지정하면서 UI에서 파이프라인을 매뉴얼으로 실행합니다.
환경 변수는 QA 미러의 트리거된 하향 파이프라인으로 전달되어 빌드 중에 사용됩니다.
변경 사항을 되돌리는 추가 단계를 피하기 위해 *_VERSION 파일을 변경하는 대신 환경 변수를 사용해야 합니다. *_VERSION 파일은 omnibus-gitlab의 반복적인 패키지 빌드가 필요하고 변경 사항은 GitLab 컴포넌트만 있는 경우에 가장 효율적입니다. 이 경우에는 *_VERSION 파일을 변경한 후 파이프라인을 다시 실행하여 매뉴얼으로 새로운 파이프라인을 실행하는 대신 상위 컴포넌트 기능 브랜치에서 변경 사항을 끌어와서 새 패키지를 빌드할 수 있습니다.
GitLab 컴포넌트의 특정 미러 또는 포크 사용
Omnibus가 빌드하는 대부분의 소프트웨어의 리포지터리 소스는 omnibus-gitlab 리포지터리의 .custom_sources.yml 파일에 있습니다. 주요 GitLab 컴포넌트를 환경 변수를 사용하여 재정의할 수 있습니다. 자세한 내용은 아래 표를 확인하세요.
| 환경 변수 | 설명 |
|---|---|
ALTERNATIVE_PRIVATE_TOKEN
| 비공개 리포지터리에서 끌어오기 위해 사용되는 액세스 토큰입니다. |
GITLAB_ALTERNATIVE_REPO
| GitLab Rails 애플리케이션의 Git 리포지터리 위치입니다. |
GITLAB_SHELL_ALTERNATIVE_REPO
| GitLab Shell의 Git 리포지터리 위치입니다. |
GITLAB_PAGES_ALTERNATIVE_REPO
| GitLab Pages의 Git 리포지터리 위치입니다. |
GITALY_SERVER_ALTERNATIVE_REPO
| Gitaly의 Git 리포지터리 위치입니다. |
GITLAB_ELASTICSEARCH_INDEXER_ALTERNATIVE_REPO
| GitLab Elasticsearch Indexer의 Git 리포지터리 위치입니다. |
GITLAB_KAS_ALTERNATIVE_REPO
| GitLab Kubernetes Agent Server의 Git 리포지터리 위치입니다. |
다른 운영 체제용 패키지 빌드
전제 조건:
- 당신은
omnibus-gitlab릴리스 미러에 브랜치를 푸시할 권한이 있어야 합니다.
릴리스 미러를 사용하여 다음을 수행할 수 있습니다:
- Ubuntu 22.04 이외의 운영 체제용 패키지 빌드.
- 당신의 변경 사항이 있는 패키지들이 모든 운영 체제에서 빌드될 수 있도록 확인합니다.
다른 운영 체제용 패키지를 빌드하려면 다음을 수행하세요:
도움말