Jenkins의 프로젝트에 하위 모듈이 있습니다. 고급 설정을 활성화하여 하위 모듈을 재귀 적으로 업데이트했습니다.
빌드를 실행하면 작업 공간에 하위 모듈의 파일이 있음을 알 수 있습니다. 문제는 서브 모듈의 첫 번째 개정판 인 것 같습니다. 변경 사항을 푸시 할 때 (GitHub에서 호스팅되는 저장소) Jenkins가 올바른 변경 사항을 가져 오기 위해 하위 모듈을 업데이트하지 않는 것 같습니다. 본 사람이 있습니까?
Jenkins 빌드에서 업데이트되지 않는 Git 하위 모듈
답변:
있습니다 2.0 플러그인 젠킨스 힘내 서브 모듈의 적절한 업데이트를 확인해야하는 "사전 서브 모듈의 행동을"해야합니다 :
Advanced sub-modules behavior> "Path of the reference repo to use during submodule update"이 필드에 대해 하위 모듈 git url을 추가하십시오.
인증 문제의 경우 "상위 저장소의 기본 원격에서 자격 증명 사용"옵션이 있습니다.
여기 JENKINS-20941 에서 본 :
6
하지만 어떻게? 세부 단계, 어떤 옵션을 선택할 수도 있습니까? 감사.
—
zavié 2014
@ zavié "고급 하위 모듈 동작"을 선택한 다음 나타나는 "하위 모듈을 재귀 적으로 업데이트"확인란을 선택하고 저장을 클릭해야한다고 생각합니다.
—
KajMagnus
개인 저장소를 사용하는 경우에는 제대로 작동하지 않습니다.
—
에릭
개인의 repo에 완벽하게 나를 위해 일했다
—
davegallant
이것은 저장소가 git 하위 모듈을 읽는 데 인증이 필요하지 않은 경우에만 작동합니다. 젠킨스 버그.
—
에른스트 Kuschke
이는 Jenkins 사이트의 Recursive submodules 섹션 아래에있는 Git Plugin 문서에서 다룹니다 .
발췌GIT 플러그인은 하위 모듈 자체가있는 하위 모듈이있는 저장소를 지원합니다. 그래도 켜야합니다 : 작업 구성 -> 섹션 소스 코드 관리 , Git- > 고급 버튼 (빌드 할 분기 아래)-> 하위 모듈을 재귀 적으로 업데이트 합니다.
예
작업 구성 화면의 소스 코드 관리 섹션에서 추가 버튼을 아래로 당겨 "고급 하위 모듈 동작"을 선택합니다.
그런 다음 "재귀 적으로 하위 모듈 업데이트"를 선택합니다.
감사합니다.하지만이 작업을 시도했을 때 작동하지 않았습니다 (거의 2 년 전)
—
Ben
@Ben-좋아, 나는 이것을 시도했고 그것은 나를 위해 일했습니다. 버전과 관련이있을 수 있습니다.
—
slm
이는 저장소가 git 하위 모듈을 읽는 데 인증이 필요하지 않은 경우에만 작동합니다.
—
에른스트 Kuschke
@ErnstKuschke-Jenkins가 SSH 키를받을 수 있으므로 인증이 필요한 저장소와 상호 작용할 수 있습니다.
—
slm
Git 저장소가 항상 특정 개정판을 참조한다는 것을 알고 있습니까? 하위 모듈 을 있습니까? Jenkins는 개정판을 자동으로 변경하지 않습니다.
하위 모듈의 최신 개정판을 사용하려면 로컬 Git 저장소에서 다음을 수행해야합니다.
cd submoduledir
git pull
cd ..
git add submoduledir
git commit -m 'Updated to latest revision of submoduledir'
git push # Go and watch Jenkins build with the new revision of the submodule
이렇게하면 Jenkins는 빌드하는 동안 정확히 동일한 하위 모듈 개정판을 확인합니다. Jenkins는 사용할 하위 모듈의 개정판을 자체적으로 결정하지 않습니다. 이것이 Git 서브 모듈과 SVN 외부의 근본적인 차이점입니다.
http://progit.org/book/ch6-6.html 과 같은 하위 모듈에 대한 좋은 참조를 읽을 수 있습니다 .
@sti가 제공 한 ProGit 링크가 오래되었습니다. 나는 생각 이 현재와 동일 https://git-scm.com/book/en/v2/Git-Tools-Submodules
—
Stevel
링크가 끊어졌습니다 (HTTPS 관련?)- "502 Bad Gateway" .
—
Peter Mortensen
마침내 이것을하는 방법을 우연히 발견했고 그것은 간단합니다.
문제:
자격 증명이있는 초기 복제는 제대로 작동하지만 submodule잘못된 자격 증명으로 후속 복제가 실패합니다.
- 자동 고급 하위 모듈 복제 :
Source Code Management >> Additional Behaviours >> Advanced sub-modules behaviours: 자격 증명 오류가 발생합니다. git submodule update --init에Execute Shell섹션 또한 인증 오류로 실패합니다.
해결책:
나는 jenkins-1.574.
- 을 체크하다
Build Environment >> SSH Agent. - 올바른 자격 증명을 선택하십시오 (
Source Code Management섹션 에서 선택한 것과 동일 할 수 있음). Execute Shell섹션의 하위 모듈 업데이트git submodule sync git submodule update --init --recursive
다음은 스크린 샷입니다.
더 이상 그러한 확인란이 없습니다.
—
adi518
해결책을 찾은 것 같습니다.
다음 셸 명령을 실행하는 빌드 단계를 추가했습니다.
git submodule foreach git checkout master
git submodule foreach git pull
이러한 명령을 수행 한 후에는 하위 모듈의 HEAD가 업데이트되었으므로 수퍼 프로젝트에서 커밋해야 할 수 있습니다.
—
slacy
안녕 벤, 솔루션을 좀 더 자세하게 공유해 주시겠습니까? 저도 똑같은 일을하고 싶습니다. 또한 확인하기 위해 솔루션은 git submodule이 프로젝트의 하위 모듈을 WORKSPACE로 업데이트합니다.
—
Kim Stacks
그보다 더 자세한 것은 없습니다. 방금 빌드 프로세스에이 두 줄을 추가했으며 항상 최신 버전의 하위 모듈을 가져옵니다.
—
Ben
@sti가 다른 응답에서 말했듯이 SVN 외부와 같은 Git 하위 모듈을 사용하려는 것 같습니다. 이러한 명령을 Jenkins에 추가하는 대신 기본 Git 저장소에 적절한 하위 모듈 버전을 커밋하는 것이 좋습니다. Jenkins는 프로젝트의 특정 버전을 빌드 할 때 항상 동일한 버전의 하위 모듈을 확인합니다. 재현 가능한 빌드는 좋은 것입니다.
—
Cody Casterline
난 당신이 서브 모듈의 마스터 분기를 사용하지 않는 esepcially 경우, 더 유용하다는 사실을 발견이 명령 건너 온 @ 벤
—
코리 스콧에게
git submodule update --init --recursive
체크 아웃 플러그인과 함께 스크립팅 된 파이프 라이닝을 사용하고 있습니다. 하위 모듈이 저장소에있는 것과 동일하게하려면 다음과 같이 trackingSubmodules 옵션을 끄면됩니다.
checkout([$class: 'GitSCM', branches: [[name: '*/develop']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'SubmoduleOption', disableSubmodules: false, parentCredentials: true, recursiveSubmodules: false, reference: '', trackingSubmodules: false]], submoduleCfg: [], userRemoteConfigs: [[credentialsId: '[myCredentials]', url: 'https://git.myRepo.git']]])