Omnibus GitLab에 새 소프트웨어 정의 추가
GitLab에 새 컴포넌트를 추가하려면 다음 단계를 따라야 합니다:
빌드 중에 소프트웨어 가져오고 컴파일
/config/software에 있는 소프트웨어 정의는 Omnibus가 소프트웨어를 가져오는 위치, 컴파일하는 방법, 필요한 폴더에 설치하는 방법을 지정합니다. 이 프로젝트의 이 부분은 GitLab의 Omnibus 패키지를 빌드할 때 실행됩니다.
Git에서 가져와야 하는 컴포넌트를 추가할 때, 로컬 미러와 업스트림의 리포지터리의 복제 주소를 /.custom_sources.yml에 추가해야 합니다.
로컬 미러는 배포 팀의 구성원이 omnibus-mirror 프로젝트에 생성해야 합니다.
소프트웨어 서비스를 포함하는 방법에 대한 예제는 디렉터리의 다른 소프트웨어 서비스를 참조하세요.
라이선스 처리
대부분의 소프트웨어 리포지터리에는 라이선스 파일이 포함되어 있습니다. 명시적으로 포함되지 않은 경우, 패치 파일을 사용하여 라이선스를 추가하세요. gem이나 pip와 같은 패키지 관리자를 사용하여 설치된 소프트웨어도 이 방법을 사용해야 합니다.
매뉴얼으로 추가된 라이선스에 대한 패치를 생성하고, config/patches/SOFTWARE_NAME/license/VERSION_NUMBER/add-license-file.patch와 같은 디렉터리 경로에 저장하세요.
프로젝트 수명 동안 라이선스가 변경될 수 있습니다. 이 방법은 고의적으로 기여자가 매뉴얼으로 설치된 라이선스를 확인하도록 하여 빌드가 실패하도록 의도되었습니다. 라이선스가 변경되지 않았다면
VERSION_NUMBER디렉터리를 새VERSION_NUMBER로 이동시켜주세요.
다른 컴포넌트에 대한 소프트웨어 정의의 의존성 추가
/config/projects/gitlab.rb에서 GitLab 프로젝트의 정의에 dependency 문을 추가하세요. 만일 더 구체적인 컴포넌트가 의존성으로써 더 많은 의미가 있다면(gitlab-rails가 필요한 컴포넌트의 경우 config/software/gitlab-rails.rb), 해당 정의에도 추가하세요.
Omnibus는 의존성 컴포넌트를 먼저 빌드한 후 /config/projects/gitlab.rb에 존재하는 순서대로 다른 컴포넌트를 빌드합니다. 따라서, 소프트웨어 컴포넌트 A가 다른 소프트웨어 B의 의존성으로 표시될 경우, A는 프로세스 시작 부분에 빌드됩니다. A가 자주 변경되는 컴포넌트인 경우, 캐시가 자주 무효화되어 모든 후속 컴포넌트가 다시 빌드되어 전체 빌드 시간이 증가합니다. A가 B보다 바로 전에 빌드되도록 보장하여 캐시 무효화를 피하는 해결책이 있습니다.
-
소프트웨어 A를
config/projects/gitlab.rb에 있는 소프트웨어 B 바로 앞에 추가하세요.이제 A와 B는 프로젝트의 최상위 의존성이기 때문에, omnibus는
/config/projects/gitlab.rb에 있는 존재 순서대로 빌드합니다. -
B의 소프트웨어 정의에 다음과 유사한 줄을 추가하세요.
dependency '<name of software A>' unless project.dependencies.include?('<name of software A>')위의 코드는 프로젝트가
/config/projects/gitlab.rb에서 빌드되지 않았을 때 A를 B의 의존성으로 표시하고, B 이전에 빌드하도록 보장합니다. 그러나/config/projects/gitlab.rb에서 빌드할 때는 효과가 없습니다.
단일 소프트웨어 의존성의 변경 확인
모든 패키지를 다시 빌드하는 대신 특정 소프트웨어만 빌드하면 유용할 수 있습니다. 예를 들어, 새 소프트웨어 정의를 추가할 때. 이 방법을 사용하면 해당 소프트웨어와 의존성만 포함하는 Omnibus 패키지를 빠르게 다시 빌드할 수 있습니다. 해당 소프트웨어가 독립적으로 빌드되었음을 확인한 후 Omnibus GitLab 빌드에 추가하여 확인할 수 있습니다. 이를 사용하려면:
도움말