병렬 배포를 사용하면 GitLab Pages 사이트의 여러 버전을 동시에 게시할 수 있습니다. 각 버전은 지정한 경로 접두사를 기반으로 고유한 URL을 가집니다.

다음 용도로 병렬 배포를 사용합니다:

• 프로덕션에 병합하기 전에 개발 브랜치에서 변경 사항을 테스트하는 워크플로우를 향상합니다.
• 피드백을 위해 이해관계자와 작업 중인 미리보기를 공유합니다.
• 여러 소프트웨어 버전에 대한 문서를 동시에 유지합니다.
• 다양한 대상을 위한 현지화된 콘텐츠를 게시합니다.
• 최종 게시 전 검토를 위한 스테이징 환경을 만듭니다.

각 사이트 버전은 지정한 경로 접두사를 기반으로 고유한 URL을 가집니다. 이 병렬 배포가 존재하는 기간을 제어합니다. 기본적으로 24시간 후에 만료되지만 검토 일정에 맞게 이 기간을 커스터마이징할 수 있습니다.

병렬 배포 만들기#

사전 요건:

• 루트 레벨 네임스페이스에 사용 가능한 병렬 배포 슬롯이 있어야 합니다.

병렬 배포를 만들려면:

1. .gitlab-ci.yml 파일에 path_prefix가 있는 Pages 작업을 추가합니다:

   pages:
     stage: deploy
     script:
       - echo "Pages accessible through ${CI_PAGES_URL}"
     pages:  # specifies that this is a Pages job and publishes the default public directory
       path_prefix: "$CI_COMMIT_BRANCH"
   

   path_prefix 값:

   • 소문자로 변환됩니다.
   • 숫자(0-9), 문자(a-z), 마침표(.)를 포함할 수 있습니다.
   • 다른 모든 문자는 하이픈(-)으로 대체됩니다.
   • 하이픈(-) 또는 마침표(.)로 시작하거나 끝날 수 없으므로 제거됩니다.
   • 63바이트 이하여야 합니다. 더 긴 것은 잘립니다.

2. 선택 사항. 동적 접두사를 원하면 path_prefix에 CI/CD 변수를 사용합니다. 예:

   pages:
     path_prefix: "mr-$CI_MERGE_REQUEST_IID" # Results in paths like mr-123
   

3. 선택 사항. 배포에 만료 시간을 설정하려면 expire_in을 추가합니다:

   pages:
     pages:
       path_prefix: "$CI_COMMIT_BRANCH"
       expire_in: 1 week
   

   기본적으로 병렬 배포는 24시간 후에 만료됩니다.

4. 변경 사항을 커밋하고 리포지터리에 푸시합니다.

배포는 다음에서 접근할 수 있습니다:

• 고유 도메인이 있는 경우: https://project-123456.gitlab.io/your-prefix-name.
• 고유 도메인이 없는 경우: https://namespace.gitlab.io/project/your-prefix-name.

사이트 도메인과 공개 디렉토리 사이의 URL 경로는 path_prefix에 의해 결정됩니다. 예를 들어 메인 배포에 /index.html에 콘텐츠가 있는 경우 접두사 staging이 있는 병렬 배포는 /staging/index.html에서 동일한 콘텐츠에 접근할 수 있습니다.

경로 충돌을 방지하려면 사이트의 기존 폴더 이름과 일치하는 경로 접두사를 사용하지 마세요. 자세한 내용은 경로 충돌을 참조하세요.

예시 구성#

https://gitlab.example.com/namespace/project와 같은 프로젝트를 고려하세요. 기본적으로 메인 Pages 배포는 다음을 통해 접근할 수 있습니다:

• 고유 도메인을 사용하는 경우: https://project-123456.gitlab.io/.
• 고유 도메인을 사용하지 않는 경우: https://namespace.gitlab.io/project.

pages.path_prefix가 프로젝트 브랜치 이름(예: path_prefix = $CI_COMMIT_BRANCH)으로 구성되고 username/testing_feature라는 브랜치가 있는 경우 이 병렬 Pages 배포는 다음을 통해 접근할 수 있습니다:

• 고유 도메인을 사용하는 경우: https://project-123456.gitlab.io/username-testing-feature.
• 고유 도메인을 사용하지 않는 경우: https://namespace.gitlab.io/project/username-testing-feature.

한도#

병렬 배포 수는 루트 레벨 네임스페이스에 의해 제한됩니다. 다음에 대한 특정 한도:

• GitLab.com은 기타 한도를 참조하세요.
• GitLab Self-Managed는 병렬 Pages 배포 수를 참조하세요.

네임스페이스의 활성 배포 수를 즉시 줄이려면 일부 배포를 삭제합니다. 자세한 내용은 배포 삭제를 참조하세요.

오래된 배포를 자동으로 삭제하는 만료 시간을 구성하려면 만료되는 배포를 참조하세요.

만료#

기본적으로 병렬 배포는 24시간 후에 만료되고 이후 삭제됩니다. 셀프 호스팅 인스턴스를 사용하는 경우 인스턴스 관리자가 다른 기본 기간을 구성할 수 있습니다.

만료 시간을 커스터마이징하려면 pages.expire_in을 구성합니다.

배포가 자동으로 만료되지 않도록 하려면 pages.expire_in을 never로 설정합니다.

경로 충돌#

pages.path_prefix는 CI/CD 변수에서 동적 값을 가져와 사이트의 기존 경로와 충돌할 수 있는 Pages 배포를 만들 수 있습니다. 예를 들어 다음 경로가 있는 기존 GitLab Pages 사이트를 고려하세요:

/index.html
/documents/index.html

pages.path_prefix가 documents이면 해당 버전은 기존 경로를 재정의합니다. 즉, https://namespace.gitlab.io/project/documents/index.html은 사이트의 main 배포의 documents/index.html이 아닌 사이트의 documents 배포의 /index.html을 가리킵니다.

CI/CD 변수를 다른 문자열과 혼합하면 경로 충돌 가능성을 줄일 수 있습니다. 예:

create-pages:
  stage: deploy
  script:
    - echo "Pages accessible through ${CI_PAGES_URL}"
  variables:
    PAGES_PREFIX: "" # No prefix by default (main)
  pages:  # specifies that this is a Pages job and publishes the default public directory
    path_prefix: "$PAGES_PREFIX"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # Run on default branch (with default PAGES_PREFIX)
    - if: $CI_COMMIT_BRANCH == "staging" # Run on main (with default PAGES_PREFIX)
      variables:
        PAGES_PREFIX: '_stg' # Prefix with _stg for the staging branch
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # Conditionally change the prefix for Merge Requests
      when: manual # Run pages manually on Merge Requests
      variables:
        PAGES_PREFIX: 'mr-$CI_MERGE_REQUEST_IID' # Prefix with the mr-<iid>, like `mr-123`

동적 접두사를 위한 변수와 문자열을 혼합하는 다른 예시:

• pages.path_prefix: 'mr-$CI_COMMIT_REF_SLUG': mr-가 접두사로 붙은 브랜치 또는 태그 이름(예: mr-branch-name).
• pages.path_prefix: '_${CI_MERGE_REQUEST_IID}_': _가 접두사와 접미사로 붙은 머지 리퀘스트 번호(예: _123_).

이전 YAML 예시는 사용자 정의 작업 이름을 사용합니다.

병렬 배포를 사용하여 Pages 환경 만들기#

병렬 GitLab Pages 배포를 사용하여 새 환경을 만들 수 있습니다. 예:

create-pages:
  stage: deploy
  script:
    - echo "Pages accessible through ${CI_PAGES_URL}"
  variables:
    PAGES_PREFIX: "" # no prefix by default (run on the default branch)
  pages:  # specifies that this is a Pages job and publishes the default public directory
    path_prefix: "$PAGES_PREFIX"
  environment:
    name: "Pages ${PAGES_PREFIX}"
    url: $CI_PAGES_URL
  rules:
    - if: $CI_COMMIT_BRANCH == "staging" # ensure to run on the default branch (with default PAGES_PREFIX)
      variables:
        PAGES_PREFIX: '_stg' # prefix with _stg for the staging branch
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # conditionally change the prefix on Merge Requests
      when: manual # run pages manually on Merge Requests
      variables:
        PAGES_PREFIX: 'mr-$CI_MERGE_REQUEST_IID' # prefix with the mr-<iid>, like `mr-123`

이 구성으로 사용자는 UI를 통해 각 GitLab Pages 배포에 접근할 수 있습니다. Pages에 환경을 사용할 때 모든 Pages 환경이 프로젝트 환경 목록에 나열됩니다.

유사한 환경을 그룹화할 수도 있습니다.

이전 YAML 예시는 사용자 정의 작업 이름을 사용합니다.

자동 정리#

path_prefix가 있는 머지 리퀘스트에 의해 만들어진 병렬 Pages 배포는 머지 리퀘스트가 닫히거나 병합될 때 자동으로 삭제됩니다.

리디렉션과 함께 사용#

리디렉션은 절대 경로를 사용합니다. 병렬 배포는 하위 경로에서 사용 가능하므로 리디렉션은 병렬 배포에서 작동하려면 _redirects 파일에 추가 수정이 필요합니다.

기존 파일은 항상 리디렉션 규칙보다 우선순위가 높으므로 접두사가 붙은 경로에 대한 요청을 잡기 위해 와일드카드 플레이스홀더를 사용할 수 있습니다.

path_prefix가 /mr-${$CI_MERGE_REQUEST_IID}인 경우 이 _redirect 파일 예시를 적용하여 기본 배포와 병렬 배포 모두에 대한 요청을 리디렉션합니다:

# Redirect the primary deployment
/will-redirect.html /redirected.html 302

# Redirect parallel deployments
/*/will-redirect.html /:splat/redirected.html 302