• GitLab Pages 호스트명 구성
  • 와일드카드 없이 호스트 파일 편집
  • DNS 와일드카드 대안 사용
• GDK 없이 GitLab Pages 구성
  • 수동으로 GitLab Pages 실행
• GDK로 GitLab Pages 구성
  • GDK로 GitLab Pages 실행
  • 수동으로 GitLab Pages 실행
    • FIPS 모드에서 GitLab Pages 빌드
  • GitLab Pages 사이트 생성
  • 액세스 제어 활성화
  • 객체 스토리지 활성화
• 린팅
• 테스트
• 기여하기
  • 기능 플래그
• 관련 주제
• 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는 비공개 사이트를 지원합니다. 비공개 사이트는 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. gdk.yml을 편집하여 GitLab 자체의 객체 스토리지를 활성화합니다:

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

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

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

린팅

# 로컬에서 린터 실행
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 && go test ./ -run TestRedirect

기여하기

기능 플래그

경고: 새로 도입된 기능 플래그는 기본적으로 비활성화되어야 합니다.

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

1. 기능 플래그를 만듭니다. internal/feature/feature.go에 기능 플래그를 만들어야 하며, 기본적으로 off여야 합니다.
2. Feature flag 템플릿을 사용하여 기능 플래그를 추적하는 이슈를 생성합니다.
3. 기능 플래그를 처리하는 머지 리퀘스트에 ~"feature flag" 라벨을 추가합니다.

GitLab Pages의 기능 플래그는 글로벌 수준에서 환경 변수에 의해 제어됩니다. 기능 플래그의 상태를 변경하려면 서비스 수준의 배포가 필요합니다. GitLab Pages 기능 플래그를 활성화하는 머지 리퀘스트 예시: Enforce GitLab Pages rate limits

관련 주제

• GitLab 개발 중의 기능 플래그

GitLab Pages 유지 보수자가 되는 방법

이 문서는 GitLab 팀원이 GitLab Pages 프로젝트의 유지 보수자가 되고자 하는 경우의 지침으로 제공됩니다. 유지 보수자는 GitLab Pages 코드베이스에 대해 고급 이해를 가져야 합니다. 프로젝트의 유지 보수자가 되기 전에 해당 프로젝트의 코드베이스에 대해 좋은 감을 가져야 하며, 하나 이상의 기능에 대한 전문 지식과 코딩 표준에 대한 심층적인 이해가 필요합니다.

기대사항

GitLab에서 유지 보수자가 되는 과정은 핸드북에서 정의되어 있으며, 이러한 프로세스는 이 기준의 기본이 됩니다. 기대되는 것 중 하나는 리뷰의 수가 많아야 하지만; GitLab Pages의 변경 속도는 GitLab Rails 프로젝트보다 적기 때문에 문제를 해결하려면 리뷰어와 메인테이너의 역할을 모두 잘 수행해야 합니다.

이 문제를 해결하기 위해 코드베이스의 다음 영역에 대해 편안해져야 합니다:

주요 영역:

• Namespace/프로젝트 해결
• ZIP 서빙 및 가상 파일 시스템
• 인증

작은 영역:

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

이를 실현하기 위해 해당 기능들의 주요 영역과 위에 언급된 작은 영역에서 관련 있는 기여를 하여 기능에 대한 더 나은 이해를 갖도록 노력해야 합니다. 관련 있는 기여는 버그 수정이나 성능 개선, 새로운 기능, 또는 중요한 리팩터링일 수 있습니다.

리뷰어

유지 보수자가 되기 전에 해당 프로젝트의 리뷰어가 되어야 합니다. 이는 문서를 포함한 코드베이스의 아무 부분에 대한 변경 사항을 포함해야 합니다.

리뷰어가 되기 위해서는 핸드북에서 기술한 절차를 따라야 합니다. 유지 보수자가 되기 전에 리뷰어로 활동할 기간에 대한 명확한 타임라인은 없지만, 기대 사항 섹션에서 언급된 영역에 대한 충분한 경험을 쌓아야 합니다.

유지 보수자

유지 보수자가 되기 위해서는 핸드북에서 기술한 절차를 따라야 합니다. 다음의 주관적인 요구 사항이 충족된 경우 유지 보수자가 준비된 상태일 것입니다:

• 리뷰한 MR이 추가로 필요한 변경 없이 유지 보수자 리뷰를 통과하는 것이 일관적
• 만든 MR이 리뷰어와 유지 보수자 리뷰를 통과하는 것이 일관적
• 운영 작업을 수행하는 데 편안함을 느끼는 것

이러한 주관적인 요구 사항이 충족된 경우, 유지 보수자로 승격할 수 있도록 MR을 엽니다 그리고 기존 유지 보수자를 태그합니다.