InfoGrab DocsInfoGrab Docs

JiHu(JH) 에디션 관련 머지 리퀘스트 리뷰 가이드라인

요약

JH와 관련된 변경 사항에는 두 가지 종류가 있습니다: 이는 EE 리포지터리의 범위를 벗어나며 이 문서의 목적이 아닙니다. 이러한 변경 사항은 EE 리포지터리에 위치해야 하므로, EE 리포지터리의 리뷰어와 메인테이너가 리뷰하고 유지 관리해야 합니다.

JH와 관련된 변경 사항에는 두 가지 종류가 있습니다:

  • jh/ 내부

이는 EE 리포지터리의 범위를 벗어나며 이 문서의 목적이 아닙니다.

  • jh/ 외부

이러한 변경 사항은 EE 리포지터리에 위치해야 하므로, EE 리포지터리의 리뷰어와 메인테이너가 리뷰하고 유지 관리해야 합니다. 여기에는 Gitlab.jh?와 같은 코드, 그리고 ee/ 하위 코드를 로드하는 방식과 마찬가지로 jh/ 하위 코드를 로드하려는 방식이 포함됩니다.

  • 이 문서는 jh/ 하위 코드를 조회하는 데 필요한 변경 사항을 더 잘 이해할 수 있도록, 해당 코드들이 어떤 형태를 가져야 하는지 안내하기 위한 것입니다.

  • 이를 일반화하여 EE와 JH 모두 동일한 메커니즘을 공유할 수 있도록 하면, 두 버전을 다르게 처리할 필요가 없어집니다.

  • JH 에디션 운영을 지원하기 위해 필요한 데이터베이스 마이그레이션 및 데이터베이스 스키마 변경 사항. 자세한 내용은 JiHu 데이터베이스 변경 가이드라인을 참조하세요.

필요한 경우, JH 리포지터리에 위치한 해당 JH 머지 리퀘스트를 리뷰하세요.

GitLab Inc. 리포지터리에 파일을 머지할 시점#

GitLab JH 리포지터리의 jh/ 외부에 추가된 파일은 GitLab Inc. 리포지터리에도 미러링되어야 합니다.

GitLab Inc. 리포지터리에 추가된 코드가 GitLab Inc. 코드베이스에 존재하지 않는 GitLab JH 파일을 참조하는 경우(예: render_if_exists), JiHu 머지 리퀘스트 또는 파일에 대한 링크가 포함된 주석을 추가하세요. 이는 해당 참조가 누락된 partial로 오인되어 gitlab 코드베이스에서 삭제되는 것을 방지하기 위함입니다.

프로세스 개요#

다음 프로세스 가이드를 읽어보세요:

jh/가 없거나 EE_ONLY=1인 경우 EE처럼 동작#

  • EE 리포지터리의 경우, jh/가 존재하지 않으므로 EE처럼(라이선스가 없는 경우 CE처럼) 동작해야 합니다.

  • JH 리포지터리의 경우, jh/가 존재하지만 EE_ONLY 환경 변수를 설정하여 EE 모드로 강제 실행할 수 있습니다.

FOSS_ONLY=1인 경우 FOSS처럼 동작#

  • JH 리포지터리의 경우, jh/가 존재하지만 FOSS_ONLY 환경 변수를 설정하여 FOSS(CE) 모드로 강제 실행할 수 있습니다.

JH 컨텍스트에서의 CI 파이프라인#

EE 리포지터리에는 jh/ 디렉터리가 없으므로 EE 리포지터리에서 JH 파이프라인을 실행할 방법이 없습니다. 모든 JH 테스트는 JH 리포지터리로 이동해야 합니다.

최상위 JH CI 구성은 jh/.gitlab-ci.yml(EE 리포지터리에는 존재하지 않음)에 위치하며, 이에 따라 EE CI 구성을 포함합니다. JH가 더 쉽게 커스터마이즈할 수 있도록 EE CI 구성을 업데이트해야 하는 경우가 있습니다.

CE 또는 EE 기능을 기반으로 하는 JH 기능#

기존 CE/EE 기능 위에 구축되는 기능의 경우, CE/EE 클래스/모듈에 주입되는 JH 네임스페이스의 모듈이 필요합니다. 이는 EE 기능에서 하는 방식과 동일합니다.

자세한 내용은 EE 백엔드 코드로 CE 기능 확장을 참조하세요.

예를 들어, User 클래스에 모듈을 prepend하려면 다음 방식을 사용합니다:

class User < ActiveRecord::Base
  # ... lots of code here ...
end

User.prepend_mod

EE에서 User.prepend_mod는 다음을 시도합니다:

  • EE 모듈 로드

JH에서 User.prepend_mod는 다음을 시도합니다:

  • EE 모듈 로드, 그리고:

  • JH 모듈 로드

prepend, extend, include와 같은 메서드를 사용하지 마세요. 대신 prepend_mod, extend_mod, 또는 include_mod를 사용하세요. 이 메서드들은 수신자 모듈의 이름으로 관련 EE 및 JH 모듈을 찾으려고 시도합니다.

해당 JH 파일을 리뷰해야 하는 경우, JH 리포지터리에서 찾을 수 있습니다.

경우에 따라 JH에서 우리가 필요로 하지 않는 무언가를 재정의해야 할 수도 있으며, 이 경우 해당 모듈에 prepend_mod를 추가하는 것도 괜찮습니다. 이렇게 할 때는 주석을 추가하고 해당 모듈을 사용하는 JH 모듈에 대한 링크를 포함하세요. 이렇게 하면 어디서 사용되는지, 언제 더 이상 필요하지 않을지를 알 수 있으며, JH를 의도치 않게 깨뜨리면서 사용하지 않는다는 이유만으로 삭제하는 일을 방지할 수 있습니다. 예시:

# Added for JiHu
# Used in https://jihulab.com/gitlab-cn/gitlab/-/blob/main-jh/jh/lib/jh/api/integrations.rb
API::Integrations.prepend_mod

JH 확장 작성을 위한 일반 지침#

일반적인 지침은 Enterprise Edition 기능 구현 가이드라인을 참조하세요.

JiHu(JH) 에디션 관련 머지 리퀘스트 리뷰 가이드라인

GitLab v19.1
원문 보기
요약

JH와 관련된 변경 사항에는 두 가지 종류가 있습니다: 이는 EE 리포지터리의 범위를 벗어나며 이 문서의 목적이 아닙니다. 이러한 변경 사항은 EE 리포지터리에 위치해야 하므로, EE 리포지터리의 리뷰어와 메인테이너가 리뷰하고 유지 관리해야 합니다.

JH와 관련된 변경 사항에는 두 가지 종류가 있습니다:

  • jh/ 내부

이는 EE 리포지터리의 범위를 벗어나며 이 문서의 목적이 아닙니다.

  • jh/ 외부

이러한 변경 사항은 EE 리포지터리에 위치해야 하므로, EE 리포지터리의 리뷰어와 메인테이너가 리뷰하고 유지 관리해야 합니다. 여기에는 Gitlab.jh?와 같은 코드, 그리고 ee/ 하위 코드를 로드하는 방식과 마찬가지로 jh/ 하위 코드를 로드하려는 방식이 포함됩니다.

  • 이 문서는 jh/ 하위 코드를 조회하는 데 필요한 변경 사항을 더 잘 이해할 수 있도록, 해당 코드들이 어떤 형태를 가져야 하는지 안내하기 위한 것입니다.

  • 이를 일반화하여 EE와 JH 모두 동일한 메커니즘을 공유할 수 있도록 하면, 두 버전을 다르게 처리할 필요가 없어집니다.

  • JH 에디션 운영을 지원하기 위해 필요한 데이터베이스 마이그레이션 및 데이터베이스 스키마 변경 사항. 자세한 내용은 JiHu 데이터베이스 변경 가이드라인을 참조하세요.

필요한 경우, JH 리포지터리에 위치한 해당 JH 머지 리퀘스트를 리뷰하세요.

GitLab Inc. 리포지터리에 파일을 머지할 시점#

GitLab JH 리포지터리의 jh/ 외부에 추가된 파일은 GitLab Inc. 리포지터리에도 미러링되어야 합니다.

GitLab Inc. 리포지터리에 추가된 코드가 GitLab Inc. 코드베이스에 존재하지 않는 GitLab JH 파일을 참조하는 경우(예: render_if_exists), JiHu 머지 리퀘스트 또는 파일에 대한 링크가 포함된 주석을 추가하세요. 이는 해당 참조가 누락된 partial로 오인되어 gitlab 코드베이스에서 삭제되는 것을 방지하기 위함입니다.

프로세스 개요#

다음 프로세스 가이드를 읽어보세요:

jh/가 없거나 EE_ONLY=1인 경우 EE처럼 동작#

  • EE 리포지터리의 경우, jh/가 존재하지 않으므로 EE처럼(라이선스가 없는 경우 CE처럼) 동작해야 합니다.

  • JH 리포지터리의 경우, jh/가 존재하지만 EE_ONLY 환경 변수를 설정하여 EE 모드로 강제 실행할 수 있습니다.

FOSS_ONLY=1인 경우 FOSS처럼 동작#

  • JH 리포지터리의 경우, jh/가 존재하지만 FOSS_ONLY 환경 변수를 설정하여 FOSS(CE) 모드로 강제 실행할 수 있습니다.

JH 컨텍스트에서의 CI 파이프라인#

EE 리포지터리에는 jh/ 디렉터리가 없으므로 EE 리포지터리에서 JH 파이프라인을 실행할 방법이 없습니다. 모든 JH 테스트는 JH 리포지터리로 이동해야 합니다.

최상위 JH CI 구성은 jh/.gitlab-ci.yml(EE 리포지터리에는 존재하지 않음)에 위치하며, 이에 따라 EE CI 구성을 포함합니다. JH가 더 쉽게 커스터마이즈할 수 있도록 EE CI 구성을 업데이트해야 하는 경우가 있습니다.

CE 또는 EE 기능을 기반으로 하는 JH 기능#

기존 CE/EE 기능 위에 구축되는 기능의 경우, CE/EE 클래스/모듈에 주입되는 JH 네임스페이스의 모듈이 필요합니다. 이는 EE 기능에서 하는 방식과 동일합니다.

자세한 내용은 EE 백엔드 코드로 CE 기능 확장을 참조하세요.

예를 들어, User 클래스에 모듈을 prepend하려면 다음 방식을 사용합니다:

class User < ActiveRecord::Base
  # ... lots of code here ...
end

User.prepend_mod

EE에서 User.prepend_mod는 다음을 시도합니다:

  • EE 모듈 로드

JH에서 User.prepend_mod는 다음을 시도합니다:

  • EE 모듈 로드, 그리고:

  • JH 모듈 로드

prepend, extend, include와 같은 메서드를 사용하지 마세요. 대신 prepend_mod, extend_mod, 또는 include_mod를 사용하세요. 이 메서드들은 수신자 모듈의 이름으로 관련 EE 및 JH 모듈을 찾으려고 시도합니다.

해당 JH 파일을 리뷰해야 하는 경우, JH 리포지터리에서 찾을 수 있습니다.

경우에 따라 JH에서 우리가 필요로 하지 않는 무언가를 재정의해야 할 수도 있으며, 이 경우 해당 모듈에 prepend_mod를 추가하는 것도 괜찮습니다. 이렇게 할 때는 주석을 추가하고 해당 모듈을 사용하는 JH 모듈에 대한 링크를 포함하세요. 이렇게 하면 어디서 사용되는지, 언제 더 이상 필요하지 않을지를 알 수 있으며, JH를 의도치 않게 깨뜨리면서 사용하지 않는다는 이유만으로 삭제하는 일을 방지할 수 있습니다. 예시:

# Added for JiHu
# Used in https://jihulab.com/gitlab-cn/gitlab/-/blob/main-jh/jh/lib/jh/api/integrations.rb
API::Integrations.prepend_mod

JH 확장 작성을 위한 일반 지침#

일반적인 지침은 Enterprise Edition 기능 구현 가이드라인을 참조하세요.