Git submodules ไม่อัปเดตใน Jenkins build


86

ฉันมีโมดูลย่อยในโครงการในเจนกินส์ ฉันได้เปิดใช้งานการตั้งค่าขั้นสูงเพื่ออัปเดตโมดูลย่อยแบบวนซ้ำ

เมื่อฉันรันบิลด์ฉันเห็นว่าพื้นที่ทำงานมีไฟล์จากโมดูลย่อย ปัญหาคือดูเหมือนว่าจะเป็นการแก้ไขครั้งแรกของโมดูลย่อย เมื่อฉันพุชการเปลี่ยนแปลง (ที่เก็บที่โฮสต์บน GitHub) ดูเหมือนว่าเจนกินส์จะไม่อัปเดตโมดูลย่อยเพื่อรับการเปลี่ยนแปลงที่ถูกต้อง มีใครเคยเห็นแบบนี้บ้าง?

คำตอบ:


98

โปรดทราบว่าปลั๊กอิน Jenkins Git 2.0จะมี "พฤติกรรมโมดูลย่อยขั้นสูง" ซึ่งควรตรวจสอบการอัปเดตโมดูลย่อยอย่างเหมาะสม:

คอมไพล์ 2.0

ตามความคิดเห็นโดยvikramvi:

Advanced sub-modules behavior> " Path of the reference repo to use during submodule update" ในช่องนี้ให้เพิ่ม URL git ของโมดูลย่อย

เส้นทาง


Owen Bกล่าวถึงในความคิดเห็น :

สำหรับปัญหาการตรวจสอบสิทธิ์ขณะนี้มีตัวเลือก "ใช้ข้อมูลรับรองจากรีโมตเริ่มต้นของที่เก็บพาเรนต์"

เห็นที่นี่ในJENKINS-20941 :

https://issues.jenkins-ci.org/secure/attachment/33245/Screen%20Shot%202016-07-08%20at%2010.09.17.png


6
แต่อย่างไร? คุณสามารถระบุขั้นตอนโดยละเอียดได้หรือไม่ว่าจะเลือกตัวเลือกใด ขอบคุณ.
zavié

8
@ zaviéฉันคิดว่าคุณควรเลือก "การทำงานของโมดูลย่อยขั้นสูง" จากนั้นเลือกช่องทำเครื่องหมาย "อัปเดตโมดูลย่อยซ้ำ" ที่จะปรากฏขึ้นแล้วคลิกบันทึก
KajMagnus

9
วิธีนี้ใช้ไม่ได้ผลหากคุณใช้ที่เก็บส่วนตัว
Erik

1
ทำงานได้อย่างสมบูรณ์แบบสำหรับฉันด้วย repo ส่วนตัว
davegallant

3
สิ่งนี้ใช้ได้เฉพาะเมื่อ repo ของคุณไม่ต้องการการตรวจสอบสิทธิ์เพื่ออ่านโมดูลย่อย git ของคุณ ข้อผิดพลาดของ Jenkins
Ernst Kuschke

33

นี้จะกล่าวถึงในเอกสาร Git ปลั๊กอินบนเว็บไซต์เจนกินส์ภายใต้หัวข้อ: submodules ซ้ำ

ข้อความที่ตัดตอนมา

ปลั๊กอิน GIT รองรับที่เก็บที่มีโมดูลย่อยซึ่งจะมีโมดูลย่อยด้วยกันเอง นี้จะต้องเปิดแม้ว่า: ในการกำหนดค่าการทำงาน -> มาตราการจัดการรหัสที่มา , Git -> ปุ่มขั้นสูง (ภายใต้สาขาการสร้าง) -> ซ้ำ submodules

ตัวอย่าง

จากหน้าจอการกำหนดค่างานของคุณในส่วนการจัดการซอร์สโค้ดให้ดึงปุ่มเพิ่มลงมาเลือก "พฤติกรรมโมดูลย่อยขั้นสูง"

   s1

                                 s2

จากนั้นเลือก "อัปเดตโมดูลย่อยซ้ำ":

   s3


1
ขอบคุณ แต่สิ่งนี้ไม่ได้ผลในขณะที่ฉันพยายาม (เกือบ 2 ปีที่แล้ว)
เบ็น

@ เบ็น - โอเคฉันแค่ลองสิ่งนี้และมันก็ได้ผลสำหรับฉัน อาจเกี่ยวข้องกับเวอร์ชันของคุณ
slm

1
วิธีนี้ใช้ได้เฉพาะเมื่อ repo ของคุณไม่ต้องการการตรวจสอบสิทธิ์เพื่ออ่านโมดูลย่อย git
Ernst Kuschke

@ErnstKuschke - ฉันเชื่อว่าเจนกินส์สามารถได้รับคีย์ SSH เพื่อให้สามารถโต้ตอบกับ repos ที่ต้องการการตรวจสอบสิทธิ์ได้เช่นกัน
slm

30

คุณทราบหรือไม่ว่าที่เก็บ Git ของคุณอ้างถึงการแก้ไขโมดูลย่อยโดยเฉพาะเสมอ เจนกินส์จะไม่เปลี่ยนการแก้ไขโดยอัตโนมัติ

หากคุณต้องการนำโมดูลย่อยที่ปรับปรุงใหม่กว่ามาใช้คุณต้องดำเนินการนี้ในที่เก็บ 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 จะตรวจสอบการแก้ไขโมดูลย่อยที่เหมือนกันทุกประการในระหว่างการสร้าง เจนกินส์ไม่ได้ตัดสินใจด้วยตัวเองว่าจะใช้การแก้ไขโมดูลย่อยใด นี่คือความแตกต่างพื้นฐานระหว่าง Git submodules และ SVN externals

คุณอาจต้องการที่จะอ่านข้อมูลอ้างอิงที่ดีใน submodules เช่นhttp://progit.org/book/ch6-6.html


1
ลิงก์ ProGit @sti ที่ให้นั้นล้าสมัย ฉันคิดว่านี่เทียบเท่ากับปัจจุบันhttps://git-scm.com/book/en/v2/Git-Tools-Submodules
Stevel

การเชื่อมโยงเสีย (HTTPS เกี่ยวข้อง?) - "502 Bad เกตเวย์"
Peter Mortensen

17

ในที่สุดก็สะดุดกับวิธีการทำและมันง่าย

ปัญหา:

การโคลนเริ่มต้นด้วยหนังสือรับรองทำงานได้ดี แต่การsubmoduleโคลนในภายหลังล้มเหลวด้วยข้อมูลรับรองที่ไม่ถูกต้อง

  1. การโคลนโมดูลย่อยขั้นสูงอัตโนมัติSource Code Management >> Additional Behaviours >> Advanced sub-modules behaviours: ส่งผลให้เกิดข้อผิดพลาดข้อมูลรับรอง
  2. git submodule update --initในExecute Shellส่วนนี้ล้มเหลวด้วยข้อผิดพลาดข้อมูลรับรอง

การแก้ไขปัญหา:

ฉันกำลังใช้jenkins-1.574.

  1. ทำBuild Environment >> SSH Agentเครื่องหมายในช่อง
  2. เลือกข้อมูลรับรองที่ถูกต้อง (อาจเหมือนกับที่เลือกในSource Code Managementส่วน
  3. อัปเดตโมดูลย่อยในExecute Shellส่วน

    git submodule sync
    git submodule update --init --recursive
    

นี่คือภาพหน้าจอใส่คำอธิบายภาพที่นี่


3
ไม่มีช่องทำเครื่องหมายนี้อีกต่อไป
adi518

11

ดูเหมือนว่าฉันจะพบวิธีแก้ปัญหา:

ฉันเพิ่มขั้นตอนการสร้างเพื่อดำเนินการคำสั่งเชลล์ต่อไปนี้:

git submodule foreach git checkout master
git submodule foreach git pull

หลังจากคุณทำคำสั่งเหล่านั้นคุณอาจต้องยอมรับใน superproject แม้ว่า HEAD ในโมดูลย่อยของคุณจะได้รับการอัปเดต
slacy

สวัสดีเบ็นคุณช่วยแบ่งปันวิธีแก้ปัญหาของคุณพร้อมรายละเอียดเพิ่มเติมได้ไหม ฉันต้องการทำสิ่งเดียวกัน นอกจากนี้เพื่อยืนยันว่าโซลูชันของคุณจะ git submodule อัปเดตโมดูลย่อยของโครงการลงใน WORKSPACE ใช่หรือไม่?
Kim Stacks

ไม่มีรายละเอียดมากไปกว่านั้น ฉันเพิ่งเพิ่ม 2 บรรทัดนั้นในกระบวนการสร้างของฉันและมันจะดึงโมดูลย่อยเวอร์ชันล่าสุดเสมอ
เบ็

10
ดังที่ @sti กล่าวในคำตอบอื่นที่นี่ดูเหมือนว่าคุณกำลังพยายามใช้โมดูลย่อย Git เช่น SVN externals แทนที่จะเพิ่มคำสั่งเหล่านี้ใน Jenkins จะเป็นการดีกว่าที่จะส่งเวอร์ชันโมดูลย่อยที่เหมาะสมไปยัง Git repo หลักของคุณ จากนั้นเจนกินส์จะตรวจสอบโมดูลย่อยเวอร์ชันเดียวกันเสมอเมื่อสร้างโปรเจ็กต์เวอร์ชันใดเวอร์ชันหนึ่ง การสร้างที่ทำซ้ำได้เป็นสิ่งที่ดี
Cody Casterline

4
@ben ฉันเจอคำสั่งนี้ซึ่งคุณอาจพบว่ามีประโยชน์มากขึ้นหากคุณไม่ได้ใช้สาขาหลักในโมดูลย่อย git submodule update --init --recursive
Corey Scott

7

หากคุณใช้โมดูล Jenkins Git คุณสามารถตั้งค่าเป็น "ล้างพื้นที่ทำงานก่อนสร้าง" วิธีนี้จะได้รับโมดูลย่อยที่ถูกต้องเสมอ


2

ฉันใช้การไปป์ไลน์แบบสคริปต์กับปลั๊กอินเช็คเอาต์ หากคุณต้องการให้โมดูลย่อยเหมือนกับในที่เก็บของคุณเพียงแค่ปิดตัวเลือก 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']]])
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.