git clone - ล้มเหลวแทนการขอข้อมูลประจำตัว

14

เมื่อการโคลนที่เก็บข้อมูลคอมไพล์ในเครื่องมืออัตโนมัติ - ส่วนหน้าของเว็บระบบ CI บางครั้งการเรียก git clone จะเปิดขึ้นพร้อมท์ถามชื่อผู้ใช้และรหัสผ่าน (ตัวอย่างเช่นเมื่อทำการโคลน Github repo ที่ไม่มีอยู่หรือบนโหนดใหม่ )

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

git automation

— Tin Tvrtković
แหล่งที่มา

เรามีการตั้งค่าเซิร์ฟเวอร์เจนกินส์หลายตัวซึ่งน่ารำคาญที่รอให้พรอมต์จนกว่าจะถูกฆ่าถ้ามันทำงานบนเซิร์ฟเวอร์ใหม่ขาดคีย์ ssh - วิธีกำหนดค่าว่าจะล้มเหลวเพียงแค่มีข้อความและรหัสออกที่ไม่ใช่ศูนย์จะ จะมีประโยชน์.

— Danny Staple

หากโหมด catch "แบทช์" ทั้งหมดสามารถใช้เพื่อไม่อนุญาตให้ขอคีย์โฮสต์ด้วย - นี่จะเหมาะอย่างยิ่ง

— Danny Staple

เหล่านี้มีทั้งที่เกี่ยวข้อง - พยายามที่จะปะติดปะต่อเข้าด้วยกัน - serverfault.com/questions/61915/... , stackoverflow.com/questions/7772190/...

— Danny Staple

15

ใน git เวอร์ชัน 2.3 มีตัวแปรสภาพแวดล้อมGIT_TERMINAL_PROMPTซึ่งเมื่อตั้งค่าเป็น0จะปิดใช้งานการพร้อมท์ขอข้อมูลรับรอง

คุณจะได้รับข้อมูลเพิ่มเติมเกี่ยวกับมันในman git(หลังจากการปรับปรุงรุ่นคอมไพล์2.3) หรือในการโพสต์บล็อกนี้บน GitHub

ตัวอย่าง:

git clone https://github.com/some/non-existing-repo จะแจ้งชื่อผู้ใช้และรหัสผ่าน
GIT_TERMINAL_PROMPT=0 git clone https://github.com/some/non-existing-repo จะล้มเหลวโดยไม่แจ้งชื่อผู้ใช้และรหัสผ่าน

น่าผิดหวังที่ได้กลับมาที่นี่พร้อมกับ https git clone บนเซิร์ฟเวอร์ el7 ที่มี git 1.8 ไปตรวจสอบว่าการอัปเดตเป็น 2.0 จาก repo อื่นเป็นตัวเลือกหรือไม่

— Danny Staple

0

หากคุณใช้การพิสูจน์ตัวตน ssh และบน linux คุณสามารถสร้างคำสั่ง ssh เพื่อปิดใช้งานได้

สร้างไฟล์ชื่อ "sshnoprompt.sh" ด้วย:

ssh -oBatchMode=yes $@

ทำให้ไฟล์นี้ปฏิบัติการได้ด้วย chmod +x sshnoprompt.sh

จากนั้นเมื่อเริ่มคอมไพล์:

GIT_SSH="sshnoprompt.sh" git clone foo@dummyserver:not_a_repo

และจะไม่อนุญาตให้มีคำสั่งหรือคำถามคอมไพล์โต้ตอบ - ไม่ควรถามผู้ใช้สำหรับสิ่งใด

— Danny Staple
แหล่งที่มา

0

ทำงานจาก git เวอร์ชั่น 1.8.3.1;

git clone -c core.askPass $echo url/or/path/to/git/repo

การกำหนดค่าcore.askPassทำงานโดยผ่านการควบคุมการจัดการข้อมูลประจำตัวไปยังโปรแกรมดังกล่าว อย่างไรก็ตามเนื่องจาก$echoไม่สามารถทำอะไรได้นอกจากเอาท์พุทความพยายามในการโคลนจึงล้มเหลวทันทีและมีการเปลี่ยนเส้นทาง bash ตามลำดับ รหัสนี้ถูกเรียกใช้ในกรณีที่ที่เก็บ git เกิดขึ้นเป็นส่วนตัวเท่านั้นและจะส่งออกข้อผิดพลาดไปป์ระบุว่าการตรวจสอบสิทธิ์ล้มเหลวสำหรับที่เก็บเฉพาะ คุณสามารถทดสอบสิ่งนี้กับที่https://github.com/git/gitเก็บสาธารณะกับที่เก็บส่วนตัวที่คุณรู้จัก

เพื่อทำให้ข้อเสนอหวานคุณไม่จำเป็นต้องอ้างอิงโปรแกรมเหมือนechoในตอนแรก เพียงแค่ผ่านการกำหนดค่า git -c core.askPassโดยที่ไม่มีอินพุตต่อไปนี้จะทำให้เกิดความล้มเหลวในกรณีที่ที่เก็บเป็นส่วนตัวเนื่องจากรหัสจะไม่ทราบว่าโปรแกรมใดที่จะถ่ายข้อมูลการจัดการข้อมูลรับรองให้ แม้ว่านี่จะเป็นวิธีที่เก่ากว่าและเรียบง่ายกว่าวิธีอื่น ๆ ที่กล่าวถึงที่นี่ แต่ฉันไม่รู้ว่ามันจะมีผลเช่นเดียวกันกับ git รุ่นเก่าหรือไม่

— Jouster500
แหล่งที่มา

คุณค่อนข้างถูกต้องในขณะที่ผิดมาก ก่อนอื่นในกรณีของคุณ$echoคือการอ้างอิงตัวแปรที่ (ไม่ได้ตั้งค่า) ขยายเป็นสตริงว่างดังนั้นจึงไม่มีความหมายทั้งหมด หากคุณใส่ที่echoนั่น (โดยไม่มีเครื่องหมายดอลลาร์) ก็จะไม่ถูกต้องเพราะมันจะถูกตีความว่าเป็นสถานที่เก็บข้อมูล -c core.askPass=echoมันจะต้องเป็น

— MichałGórny

-1

ขึ้นอยู่กับว่าคุณใช้ git อย่างไรการเปลี่ยนเส้นทาง stdin หรือ stdout เพื่อไม่ให้เชื่อมต่อกับเทอร์มินัลจะหยุด git ไม่ให้แจ้งรายละเอียดและเพียงแค่ทำให้เกิดข้อผิดพลาด

ซึ่งจะช่วยให้คุณสามารถระบุข้อผิดพลาด (หรืออย่างน้อยบันทึก) ไปยังเว็บเซอร์

— Matthew Steeples
แหล่งที่มา

ฉันจะทำสิ่งนี้อย่างไร พยายามทำให้สำเร็จใน Bash ก่อนทั้งคู่</dev/nullและnohup .. &ดูเหมือนจะไม่ทำงาน

— Tin Tvrtković

คำตอบนี้ไม่เป็นประโยชน์หากไม่มีตัวอย่างเฉพาะว่าจะทำอย่างไร โดยเฉพาะอย่างยิ่งวิธีการ 'ชัดเจน' ไม่ทำงานดังกล่าวข้างต้น

— MichałGórny

@ MichałGórnyฉันไม่เห็นคำถาม OPs เมื่อสองสามปีก่อน แต่มีข้อมูลไม่เพียงพอในคำถาม (OS, ชุดเครื่องมือ) เพื่อให้สามารถตอบได้ การเปลี่ยนเส้นทาง stdin และ stdout Git มีการเปลี่ยนแปลงมากมายตั้งแต่คำถามถูกถาม (บน Windows มันจะแสดงกล่องโต้ตอบภายนอกสำหรับข้อมูลประจำตัวถ้าคุณกำลังเชื่อมต่อกับ Azure DevOps) เพื่อให้คุณดีขึ้นโดยใช้ตัวแปรสภาพแวดล้อมที่แสดงอยู่ในคำตอบยอดนิยม

— Matthew Steeples