GitLab Pages 개발에 기여하기

기능을 개발하는 데 도움이 되도록 GitLab Pages를 구성하는 방법을 배워보세요.

GitLab Pages 호스트 이름 구성

각기 다른 GitLab Pages 사이트는 서브도메인을 통해 액세스되므로 GitLab Pages에는 호스트명이나 도메인이 필요합니다. 다음과 같이 GitLab Pages 호스트명을 설정할 수 있습니다.

와일드카드 없이 호스트 파일을 편집합니다

/etc/hosts는 와일드카드 호스트명을 지원하지 않으므로 GitLab Pages에 대한 항목 하나, 그리고 각 페이지 사이트에 대한 항목 하나를 구성해야 합니다. 

127.0.0.1 gdk.test           # GDK를 사용하는 경우
127.0.0.1 pages.gdk.test     # 페이지 호스트
# 어떤 네임스페이스/그룹/사용자든 페이지 호스트의 서브도메인으로 추가해야 합니다. 왜냐하면
# /etc/hosts는 와일드카드를 허용하지 않기 때문입니다.
127.0.0.1 root.pages.gdk.test # 루트 페이지용

DNS 와일드카드 대안을 사용합니다

/etc/hosts 대신 DNS 와일드카드를 사용하고 싶은 경우 다음을 사용할 수 있습니다.

GDK 없이 GitLab Pages 구성하기

GitLab Pages 사이트의 루트에 gitlab-pages.conf를 만들어 다음과 같이 구성합니다. 

# 기본 포트는 3010이지만 다른 포트를 사용할 수 있습니다.
listen-http=:3010

# 로컬 GitLab Pages 도메인
pages-domain=pages.gdk.test

# 페이지가 저장된 디렉터리
pages-root=shared/pages

# 로그에 더 많은 정보 표시
log-verbose=true

더 많은 옵션을 보려면 internal/config/flags.go를 확인하거나 gitlab-pages --help를 실행하세요.

매뉴얼으로 GitLab Pages 실행하기

코드에 변경 사항이 있으면 앱을 빌드하기 위해 make를 실행해야 합니다. 앱을 시작하기 전에 항상 실행하는 것이 가장 좋습니다. 빌드하는 데 빨리 진행되므로 걱정하지 마세요! 

make && ./gitlab-pages -config=gitlab-pages.conf

GDK로 GitLab Pages 구성하기

다음 단계에서 $GDK_ROOT은 GDK를 복제한 디렉터리입니다.

  1. GDK 호스트명 설정

  2. gdk.yml에 GitLab Pages 호스트명 추가: 

    gitlab_pages:
  enabled: true         # GitLab Pages를 gdk로 관리하도록 설정
  port: 3010            # 기본 포트는 3010입니다
  host: pages.gdk.test  # GitLab Pages 도메인
  auto_update: true     # gdk가 GitLab Pages git을 업데이트해야 하는지 여부
  verbose: true         # 로그에 더 많은 정보 표시

GDK로 GitLab Pages 실행

이러한 구성을 설정한 후 GDK는 GitLab Pages 프로세스를 관리하며 다음과 같은 명령을 사용하여 액세스할 수 있습니다.

  • 시작: gdk start gitlab-pages
  • 중지: gdk stop gitlab-pages
  • 다시 시작: gdk restart gitlab-pages
  • 로그 참고: gdk tail gitlab-pages

매뉴얼으로 GitLab Pages 실행

GDK 프로세스 관리와는 별도로 앱을 빌드하고 시작할 수도 있습니다.

코드에 변경 사항이 있으면 앱을 빌드하기 위해 make를 실행해야 합니다. 앱을 시작하기 전에 항상 실행하는 것이 가장 좋습니다. 빌드하는 데 빨리 진행되므로 걱정하지 마세요! 

make && ./gitlab-pages -config=gitlab-pages.conf

FIPS 모드에서 GitLab Pages 빌드하기 

FIPS_MODE=1 make && ./gitlab-pages -config=gitlab-pages.conf

GitLab Pages 사이트 만들기

로컬로 GitLab Pages 사이트를 빌드하려면 gitlab-runner를 설정해야 합니다.

자세한 정보는 사용자 매뉴얼을 참조하세요.

액세스 제어 활성화

GitLab Pages는 비공개 사이트를 지원합니다. 비공개 사이트는 GitLab 프로젝트에 액세스 권한이 있는 사용자만 액세스할 수 있습니다.

GitLab Pages 액세스 제어는 기본적으로 비활성화되어 있습니다. 활성화하려면 다음을 수행하세요.

  1. GitLab 자체에서 GitLab Pages 액세스 제어를 활성화합니다. 두 가지 방법으로 수행할 수 있습니다:

    • GDK를 사용하지 않는 경우 gitlab.yml을 편집합니다: 

      # gitlab/config/gitlab.yml
pages:
  access_control: true

    • GDK를 사용하는 경우 gdk.yml을 편집합니다: 

      # $GDK_ROOT/gdk.yml
gitlab_pages:
  enabled: true
  access_control: true
  2. GitLab을 다시 시작합니다 (GDK를 통해 실행 중인 경우 gdk restart를 실행합니다). gdk reconfigure를 실행하면 config/gitlab.yml의 access_control 값이 덮어씌워집니다.
  3. 로컬 GitLab 인스턴스에서 브라우저를 열고 http://gdk.test:3000/admin/applications로 이동합니다.
  4. 인스턴스 전체 OAuth 애플리케이션을 생성합니다 (api 스코프 포함).

  5. redirect-uri 값을 pages-domain 승인 엔드포인트(예: http://pages.gdk.test:3010/auth)로 설정합니다. redirect-uri에는 GitLab Pages 사이트 도메인이 없어야 합니다.

  6. 인증 클라이언트 구성을 추가합니다:

    • GDK의 경우 gdk.yml에서: 

       gitlab_pages:
   enabled: true
   access_control: true
   auth_client_id: $CLIENT_ID           # http://gdk.test:3000/admin/applications에서 생성된 OAuth 애플리케이션 ID
   auth_client_secret: $CLIENT_SECRET   # http://gdk.test:3000/admin/applications에서 생성된 OAuth 애플리케이션 시크릿

      GDK는 무작위 auth_secret을 생성하고 GitLab Pages 호스트 구성에 기반하여 auth_redirect_uri를 빌드합니다.

    • GDK를 사용하지 않는 경우 gitlab-pages.conf에서: 

       ## 비공개 프로젝트에 대한 인증을 테스트하려면 다음 설정이 필요합니다
 auth-client-id=$CLIENT_ID                         # http://gdk.test:3000/admin/applications에서 생성된 OAuth 애플리케이션 ID
 auth-client-secret=$CLIENT_SECRET                 # http://gdk.test:3000/admin/applications에서 생성된 OAuth 애플리케이션 시크릿
 auth-secret=$SOME_RANDOM_STRING                   # 최소 32바이트 이상이어야 합니다.
 auth-redirect-uri=http://pages.gdk.test:3010/auth  # GitLab Pages에 대한 인증 콜백 URL

  7. GDK 안에서 Pages를 실행 중이면 gdk.yml의 gdk 아래 protected_config_files 섹션을 사용하여 gitlab-pages.conf 구성이 덮어쓰이지 않도록 설정할 수 있습니다: 

    gdk:
  protected_config_files:
  - 'gitlab-pages/gitlab-pages.conf'

객체 스토리지 활성화

GitLab 페이지는 아티팩트를 저장하는 데 객체 스토리지를 지원하지만, 객체 스토리지는 기본적으로 비활성화되어 있습니다. GDK에서 다음을 통해 활성화할 수 있습니다.

  1. gdk.yml을 수정하여 GitLab 자체의 객체 리포지터리를 활성화합니다: 

    # $GDK_ROOT/gdk.yml
object_store:
  enabled: true

  2. 다음 명령어를 실행하여 GitLab을 다시 구성하고 재시작합니다: gdk reconfigure 및 gdk restart.

자세한 내용은 GDK 설명서를 참조하십시오.

린팅 

# 지역에서 린터 실행
make lint

# 린터 실행 및 문제 해결 (린터에서 지원하는 경우)
make format

테스트

다음 명령어를 사용하여 테스트를 실행할 수 있습니다. 

# 코드베이스의 모든 테스트 실행
make test

# 특정 테스트 파일 실행
go test ./internal/serving/disk/

# 파일 내 특정 테스트 실행
go test ./internal/serving/disk/ -run TestDisk_ServeFileHTTP

# acceptance_test.go를 제외한 모든 단위 테스트 실행
go test ./... -short

# acceptance_test.go만 실행
make acceptance
# 특정 acceptance 테스트 실행
# acceptance 테스트에서 최신 변경 사항을 테스트하는 데 마지막으로 컴파일된 바이너리를 사용하므로
# 테스트할 빌드에 최신 변경 사항이 포함되도록 'make'를 추가합니다.
make && go test ./ -run TestRedirect

기여 방법

피처 플래그

caution
모든 최근 도입된 피처 플래그는 기본적으로 비활성화되어야 합니다.

복잡하지 않은 변경에도 피처 플래그를 추가하는 것을 고려하십시오. 피처 플래그를 사용하면 이러한 변경 사항의 릴리스 및 롤백을 보다 쉽게 할 수 있어 사건 및 다운타임을 피할 수 있습니다. GitLab 페이지에 새로운 피처 플래그를 추가하려면 다음을 수행하십시오:

  1. 기본적으로 off 상태여야 하는 internal/feature/feature.go에 피처 플래그를 생성합니다.
  2. 피처 플래그를 추적하기 위해 ‘피처 플래그’ 템플릿을 사용하여 이슈를 작성합니다.
  3. 피처 플래그를 처리하는 Merge Request에 ~"feature flag" 레이블을 추가합니다.

GitLab 페이지에서 피처 플래그는 글로벌 수준의 환경 변수에 의해 제어됩니다. 피처 플래그의 상태를 변경하려면 서비스 수준에서 배포가 필요합니다. GitLab 페이지 피처 플래그를 활성화하는 Merge Request의 예시: GitLab Pages 속도 제한 강제 적용

관련 주제

GitLab Pages 메인테이너가 되는 방법

이 문서는 GitLab 페이지 프로젝트의 메인터너가 되고자 하는 GitLab 팀 멤버들을 위한 매뉴얼로 작용합니다. 메인테이너는 GitLab Pages 코드베이스에 대한 심화된 이해를 가져야 합니다. 프로젝트의 메인테이너로 지원하기 전에 해당 프로젝트의 코드베이스를 숙달하고 하나 이상의 기능에 대한 전문 지식 및 코딩 표준에 대한 심도 있는 이해를 가져야 합니다.

기대사항

GitLab에서 메인테이너가 되는 과정은 핸드북에서 정의되어 있으며, 이는 이 프로세스의 기준이 됩니다. 기대되는 하나의 요소는 많은 리뷰를 하는 것이지만 GitLab Pages의 변경 속도는 GitLab Rails 프로젝트보다 매우 느립니다.

이 문제를 해결하기 위해 주요 코드베이스 영역에 편안함을 갖기 위해 다음 영역에서 아주 편안해야 합니다.

주요 영역:

  • 네임스페이스/프로젝트 해결
  • ZIP 서빙과 가상 파일 시스템
  • 인증

보다 작은 영역:

  • 리디렉션
  • 아티팩트 프록시
  • TLS 인증서 처리
  • 요청 제한
  • 메트릭 및 모니터링

이러한 것을 달성하기 위해 주요 영역 및 위에서 언급한 2-3개의 작은 영역에서 관련 기여를 통해 기능에 대한 더 나은 이해를 갖도록 노력해야 합니다. 관련 기여는 버그 수정, 성능 향상, 새로운 기능 또는 중요한 리팩터링일 수 있습니다.

리뷰어

메인터너가 되기 전에 해당 프로젝트의 리뷰어가 되어야 합니다. 이는 문서를 포함한 코드베이스의 어떤 부분이든 변경을 포함합니다.

리뷰어가 되려면 핸드북에 기술된 단계를 따라야 합니다. 리뷰어가 되어야 하는 기간이 명시적으로 정해져 있지는 않지만 이 문서의 기대사항 섹션에서 언급된 영역에 대한 충분한 경험을 얻어야 합니다.

메인테이너

핸드북에 기술된 단계를 따라 메인테이너가 되어야 합니다. 다음이 사실로 느껴질 때 메인테이너가 준비된 것입니다.

  • 메인터너 리뷰를 거치고나서 추가로 필요한 변경이 없는 상태에서 만든 MR이 일관되게 메인터너 리뷰를 거쳐갔습니다.
  • 만든 MR이 일관되게 리뷰어 및 메인터너 리뷰를 거쳐갔습니다.
  • 운영 작업을 수행하는 것에 대해 편안한 느낌이 듭니다.

만약 이러한 주관적 요구사항을 만족한다면, 메인터너로 승격하는 MR을 개방하고 기존의 메인터너를 태그합니다.