• GitLab 페이지 호스트 이름 구성
  • 와일드카드 없이 호스트 파일을 편집하는 경우
  • DNS 와일드카드 대안 사용
• GDK 없이 GitLab 페이지 구성
  • 수동으로 GitLab 페이지 실행
• GDK로 GitLab 페이지 구성
  • GDK로 GitLab 페이지 실행
  • 수동으로 GitLab 페이지 실행
    • FIPS 모드에서 GitLab 페이지 빌드
  • GitLab 페이지 사이트 생성
  • 접근 제어 활성화
  • 객체 저장 활성화
• 린팅
• 테스트
• 기여하기
  • 기능 플래그
• 관련 주제
• GitLab Pages 유지보수자가 되는 방법
  • 기대사항
  • 리뷰어
  • 유지보수자

GitLab 페이지 개발에 기여하기

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

GitLab 페이지 호스트 이름 구성

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

• 와일드카드 없이 호스트 파일을 편집하는 경우.
• DNS 와일드카드 대안 사용.

와일드카드 없이 호스트 파일을 편집하는 경우

/etc/hosts는 와일드카드 호스트 이름을 지원하지 않기 때문에 GitLab 페이지에 대한 항목 하나를 구성한 다음 각 페이지 사이트에 대해 항목 하나를 구성해야 합니다.

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 페이지 구성

다음과 같이 GitLab 페이지 사이트의 루트에 gitlab-pages.conf를 생성합니다.

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

# 로컬 GitLab 페이지 도메인
pages-domain=pages.gdk.test

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

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

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

수동으로 GitLab 페이지 실행

코드에 대한 변경 사항이 있을 경우 앱을 빌드하려면 make를 실행해야 합니다. 앱을 시작하기 전에 항상 실행하는 것이 가장 좋습니다. 빌드하는 데 빠르므로 걱정하지 마세요!

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

GDK로 GitLab 페이지 구성

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

1. GDK 호스트 이름 설정하기.

2. gdk.yml에 GitLab 페이지 호스트 이름을 추가하세요.

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

GDK로 GitLab 페이지 실행

위의 구성이 완료된 후, GDK는 GitLab 페이지 프로세스를 관리하며 다음과 같은 명령을 사용하여 액세스할 수 있습니다.

• 시작: gdk start gitlab-pages
• 중지: gdk stop gitlab-pages
• 재시작: gdk restart gitlab-pages
• 로그 보기: gdk tail gitlab-pages

수동으로 GitLab 페이지 실행

GDK 프로세스 관리와 독립적으로 앱을 빌드 및 시작할 수도 있습니다.

코드에 대한 변경 사항이 있을 경우 앱을 빌드하려면 make를 실행해야 합니다. 앱을 시작하기 전에 항상 실행하는 것이 가장 좋습니다. 빌드하는 데 빠르므로 걱정하지 마세요!

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

FIPS 모드에서 GitLab 페이지 빌드

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

GitLab 페이지 사이트 생성

로컬에서 GitLab 페이지 사이트를 빌드하려면 gitlab-runner를 구성해야 합니다.

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

접근 제어 활성화

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

GitLab 페이지 접근 제어는 기본적으로 비활성화되어 있습니다. 활성화하려면 다음을 수행하세요.

1. GitLab 자체에서 GitLab 페이지 접근 제어를 활성화합니다. 두 가지 방법으로 수행할 수 있습니다.

   • 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 페이지 사이트 도메인이 포함되어서는 안 됩니다.

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 페이지 호스트 구성을 기반으로 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 페이지를 위한 인증 콜백 URL
     

7. GDK 내에서 Pages를 실행하는 경우 protected_config_files 섹션을 gdk.yml의 gdk 아래에 사용하여 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 문서를 참조하세요.

린팅

# 로컬에서 린터 실행
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. 기능 플래그를 처리하는 MR에 ~"feature flag" 라벨을 추가하세요.

GitLab Pages의 기능 플래그는 전역 수준의 환경 변수를 통해 제어됩니다. 기능 플래그의 상태를 변경하려면 서비스 수준에서 배포가 필요합니다. GitLab Pages 기능 플래그를 활성화하는 MR의 예시: GitLab Pages 요율 제한 강제화

관련 주제

• GitLab 개발에서 기능 플래그

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

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

기대사항

GitLab에서 유지보수자가 되는 과정은 핸드북에서 정의되어 있으며 이 과정을 기준으로 합니다. 기대되는 한 가지는 많은 리뷰를 하는 것인데, 그러나; GitLab Pages의 변경 속도는 GitLab Rails 프로젝트와 비교하여 매우 적습니다.

이 문제를 해결하기 위해 코드베이스의 다음과 같은 영역에 익숙해져야 합니다:

주요 영역:

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

보조적인 영역:

• Redirects
• Artifacts proxying
• TLS 인증서 처리
• Rate-limiting
• 지표 및 모니터링

이를 달성하기 위해 위에서 언급한 주요 영역 및 2-3가지 보조 영역에서 관련 기여를 하여 기능에 대한 더 나은 이해를 가져야 합니다. 관련 기여란 버그 수정, 성능 개선, 새로운 기능 또는 중요한 리팩터링일 수 있습니다.

리뷰어

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

리뷰어가 되려면 핸드북에 개요된 단계를 따라야 합니다. 유지보수자가 되기 전에 리뷰어로 얼마나 오랫동안 있어야 하는지는 정해진 기간은 없지만, 이 문서의 기대사항 섹션에 언급된 영역에 대한 충분한 경험을 쌓아야 합니다.

유지보수자

유지보수자가 되려면 핸드북에 개요된 단계를 따라야 합니다. 만약 다음 명제들이 참이라고 느낄 경우 유지보수자가 준비된 것입니다:

• 당신이 리뷰한 MR들이 추가적인 필요한 변경 사항 없이 일관되게 유지보수자 리뷰를 통과하는 경우
• 당신이 만든 MR들이 추가적인 필요한 변경 사항 없이 일관되게 리뷰어와 유지보수자 리뷰를 통과하는 경우
• 당신이 운영 작업을 수행하는 데 편안하다고 느끼는 경우

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