• GitLab Pages 호스트 이름 구성
  • 와일드카드 없이, hosts 파일 편집하기
  • 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 호스트 이름을 설정할 수 있습니다:

• 와일드카드 없이, hosts 파일 편집하기.
• DNS 와일드카드 대안 사용하기.

와일드카드 없이, hosts 파일 편집하기

/etc/hosts는 와일드카드 호스트 이름을 지원하지 않으므로, GitLab Pages에 대한 항목 하나와 각 페이지 사이트에 대한 항목을 하나씩 설정해야 합니다:

127.0.0.1 gdk.test           # GDK를 사용하는 경우
127.0.0.1 pages.gdk.test     # Pages 호스트
# 모든 네임스페이스/그룹/사용자는
# pages 호스트의 서브도메인으로 추가되어야 합니다. 
# 이는 /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         # gdk에서 GitLab Pages를 관리하도록 활성화
     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. api 범위로 인스턴스 전체 OAuth 애플리케이션을 생성합니다.

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 문서를 참조하세요.

린트(코드 검사)

# 로컬에서 린터 실행
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 기능 플래그를 활성화하는 병합 요청의 예시:

GitLab Pages 속도 제한 적용

관련 주제

• GitLab 개발에서의 기능 플래그

GitLab Pages 유지 관리자가 되는 법

이 문서는 GitLab 팀원이 GitLab Pages 프로젝트의 유지 관리자가 되고자 할 때의 가이드라인 역할을 합니다.

유지 관리자는 GitLab Pages 코드베이스에 대한 고급 이해가 필요합니다.

프로젝트의 유지 관리자로 지원하기 전에, 후보자는 코드베이스에 대한 좋은 감각, 하나 이상의 기능에 대한 전문 지식, 그리고 우리의 코딩 표준에 대한 깊은 이해를 가져야 합니다.

기대 사항

GitLab에서 유지 관리자가 되는 절차는 핸드북에 정의되어 있습니다, 그리고 이것은 이 과정의 기준입니다. 기대되는 한 가지는 높은 리뷰 수입니다; 그러나 GitLab Pages의 변화 속도는 GitLab Rails 프로젝트에 비해 너무 적습니다.

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

주요 영역:

• 네임스페이스/프로젝트 해결
• ZIP 제공 및 가상 파일 시스템
• 인증

작은 영역:

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

이것을 달성하기 위해, 위에서 언급한 모든 주요 영역과 2-3개의 작은 영역에서 관련 기여를 시도해야 하며, 이를 통해 기능에 대한 더 나은 이해를 가질 수 있습니다. 관련 기여는 버그 수정, 성능 개선, 새로운 기능 또는 중요한 리팩토링일 수 있습니다.

검토자

유지보수가 되기 전에, 먼저 프로젝트의 검토자가 되어야 합니다. 이는 문서를 포함하여 코드베이스의 모든 부분에 대한 변경 사항을 포함해야 합니다.

검토자가 되려면 설명된 단계를 따라야 합니다.

유지보수가 되기 전에 검토자로 있는 기간에 대한 정해진 시간은 없지만, 이 문서의 기대 사항 섹션에 언급된 분야에서 충분한 경험을 쌓아야 합니다.

유지보수자

유지보수가 되기 위해서는 설명된 단계를 따라야 합니다.

이러한 진술이 사실처럼 느껴질 때, 당신은 유지보수가 될 준비가 되었을 가능성이 높습니다:

• 당신이 검토한 MR이 유지보수자 검토를 거치면서 추가적으로 요구되는 변경 사항 없이 일관되게 통과합니다.
• 당신이 생성한 MR이 검토자 및 유지보수자 검토를 거치면서 추가적으로 요구되는 변경 사항 없이 일관되게 통과합니다.
• 운영 작업을 수행하는 것이 편안합니다.

이러한 주관적인 요구 사항이 충족되면, MR을 열어 유지보수자로 승진하고 기존 유지보수자를 태그하세요.