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