• GitLab Pages 호스트명 구성
  • 와일드카드를 사용하지 않고 호스트 파일을 편집하는 경우
  • DNS 와일드카드 대체 옵션 사용하는 경우
• GDK 없이 GitLab Pages 구성
  • 매뉴얼으로 GitLab Pages 실행
• GDK로 GitLab Pages 구성
  • GDK로 GitLab Pages 실행
  • 매뉴얼으로 GitLab Pages 실행
    • FIPS 모드에서 GitLab Pages 빌드
  • GitLab Pages 사이트 생성
  • 액세스 제어 활성화
  • 객체 리포지터리 활성화
• Linting
• 테스팅
• 기여하기
  • 피처 플래그
• 관련 주제
• GitLab Pages 유지 보수자가 되기
  • 기대사항
  • 리뷰어
  • 유지보수자

GitLab Pages 개발에 기여하기

GitLab Pages를 구성하는 방법을 배우고 기능 개발에 도움을 줄 수 있습니다.

GitLab Pages 호스트명 구성

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

• 와일드카드를 사용하지 않고 호스트 파일을 편집하는 경우.
• DNS 와일드카드 대체 옵션 사용하는 경우.

와일드카드를 사용하지 않고 호스트 파일을 편집하는 경우

/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 와일드카드를 사용하려면 다음을 사용할 수 있습니다:

• nip.io
• dnsmasq

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는 private site를 지원합니다. Private site는 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 Pages는 아티팩트 저장을 위해 객체 리포지터리 사용을 지원하지만 기본적으로 객체 리포지터리는 비활성화되어 있습니다. GDK에서 이를 활성화할 수 있습니다:

1. GitLab 자체의 객체 리포지터리를 활성화하려면 gdk.yml을 편집하세요:

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

2. 명령 gdk reconfigure와 gdk restart를 실행하여 GitLab을 다시 설정하고 다시 시작합니다.

더 많은 정보는 GDK 문서를 참조하세요.

Linting

# 로컬에서 린터 실행
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 테스트가 최신으로 빌드된 최신 변경 사항을 사용하기 때문에 acceptance 테스트에서
# 가장 최근의 빌드를 사용하려면 `make`를 추가해야 합니다.
make && go test ./ -run TestRedirect

기여하기

피처 플래그

중요한 변경에 대해 피처 플래그를 추가하는 것을 고려해보세요. 피처 플래그를 추가하면 이러한 변경 사항의 릴리스 및 롤백이 쉬워지며 사고와 다운타임을 피할 수 있습니다. GitLab Pages에 새로운 피처 플래그를 추가하려면:

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

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

관련 주제

• GitLab 개발 중의 피처 플래그

GitLab Pages 유지 보수자가 되기

이 문서는 GitLab Pages 프로젝트의 유지 보수자가 되고자 하는 GitLab 팀 멤버를 위한 매뉴얼로 작성되었습니다. 유지 보수자는 GitLab Pages 코드베이스에 대한 심층적인 이해를 가져야합니다. 프로젝트의 유지 보수자가 되기 전에 사람은 코드베이스에 대한 좋은 이해, 하나 이상의 기능에 대한 전문 지식 및 코딩 표준에 대한 깊은 이해를 가져야합니다.

기대사항

GitLab에서 유지자가 되는 프로세스는 핸드북에서 정의되어 있습니다 and it is the baseline for this process. 하나 기대되는 것은 높은 리뷰 횟수이지만; GitLab Pages의 변경 속도는 GitLab Rails 프로젝트의 변경 속도에 비해 매우 느립니다.

문제를 해결하려면 코드베이스의 다음 영역에 익숙해져야합니다:

주요 영역:

• Namespace/project resolution
• ZIP serving and the virtual file system
• Authentication

보다 작은 영역:

• Redirects
• Artifacts proxying
• Handling of TLS certificates
• Rate-limiting
• Metrics and monitoring

이를 달성하기 위해 주요 영역과 위에서 언급한 2-3가지 작은 영역에 관련된 기여를 하여 기능에 대한 이해를 높일 수 있도록 노력해야합니다. 관련된 기여는 버그 수정, 성능 향상, 새로운 기능 또는 중요한 리팩터링일 수 있습니다.

리뷰어

유지자가 되기 전에 프로젝트의 리뷰어가 먼저되어야합니다. 이는 문서를 포함한 코드베이스의 모든 변경 사항을 포함해야합니다.

리뷰어가 되기 위해 핸드북에 나와 있는 단계를 따라야합니다. 유지보수자가 되기 전에 리뷰어로서 활동할 기간에 대한 명시적인 시간표는 없지만, 이 문서의 기대사항 섹션에서 언급된 영역에서 충분한 경험을 쌓아야합니다.

유지보수자

유지 보수자가 되려면 핸드북에 나와 있는 단계을 따라야합니다. 유닌지 있는 유지자로 활동할 준비가 되었다고 느낄 때:

• 검토한 MR(Merge Request)가 유지자 검토 없이 적극적으로 통과합니다.
• 작성한 MR가 리뷰어 및 유지자 검토 없이 적극적으로 통과합니다.
• 운영 작업을 처리하는 데 편안함을 느낍니다.

만약 그 주관적인 요구사항을 충족한다면, 당신을 유지자로 승격시키는 MR을 열고 기존의 유지자를 태그하세요.