สร้าง Python wheel นอกเครือข่ายแล้วเผยแพร่ภายใน

คุณมีงานบิลด์ที่สร้าง wheel อยู่แล้ว และมีที่เก็บส่วนตัวที่ควรได้รับมัน ความผิดพลาดคือปล่อยให้งานที่สองสร้างใหม่จากสาขาแล้วเรียกผลลัพธ์นั้นว่าการเผยแพร่เดียวกัน จงย้ายไฟล์ที่ผ่านการทดสอบ ตั้งชื่อตามไดเจสต์ และเก็บข้อมูลรับรองการอัปโหลดไว้ด้านใน คำอธิบายด้านล่างติดตาม artifact ชิ้นหนึ่งจาก CI runner สาธารณะไปยังผู้เผยแพร่ภายใน

สร้างตรงที่ซอร์สโค้ดอยู่แล้ว

รันบิลด์ในงานที่มีซอร์สโค้ด ชุดเครื่องมือ และชุดทดสอบอยู่แล้ว ไม่มีอะไรในที่เก็บส่วนตัวที่กำหนดให้งานนั้นต้องเข้าถึงมัน ติดตั้ง build frontend ในสภาพแวดล้อมที่โปรเจกต์ใช้อยู่แล้ว จากนั้นสร้างรูปแบบการแจกจ่ายทั้งสองแบบหากโปรเจกต์ส่งทั้งสองแบบ

python -m build --sdist --wheel --outdir dist
python -m twine check dist/*

เก็บไดเรกทอรีเอาต์พุตให้เล็กและใช้ครั้งเดียว สิ่งเดียวที่ควรพาต่อไปคือไฟล์ที่งานถัดไปจะเผยแพร่ พร้อมแฮชของไฟล์เหล่านั้น สิ่งอื่นทั้งหมดรวมถึงสภาพแวดล้อมเสมือนและแคชสามารถสร้างใหม่ได้จาก revision ของซอร์สที่บันทึกไว้ artifact ที่กระชับยังตรวจทานได้ง่ายกว่า เพราะทุกไฟล์ในนั้นเป็นไฟล์ที่ใครก็ตรวจสอบได้

บันทึกว่าอะไรสร้างไฟล์เหล่านั้น: ชื่อแพ็กเกจและเวอร์ชันจากชื่อไฟล์ revision ของซอร์ส และการรัน workflow ที่สร้างมันขึ้นมา สตริงเวอร์ชันอย่างเดียวไม่ระบุไฟล์ได้ เพราะเวอร์ชันเดียวกันอาจถูกสร้างสองครั้งจาก commit ที่ต่างกัน เขียน revision ไว้ข้างชื่อไฟล์ในคำอธิบาย artifact และถือว่าบันทึกนั้นเป็นส่วนหนึ่งของการส่งต่อ

ย้ายไบต์ ไม่ใช่คำสั่งให้สร้างใหม่

บิลด์ครั้งที่สองคือผลิตภัณฑ์ที่สอง เวลาที่บันทึกไว้ dependency ที่รวมมาด้วย และเวอร์ชันเครื่องมือ ล้วนเปลี่ยนไบต์ได้ การสร้างใหม่จึงต้องมีหลักฐานการทดสอบและบทตรวจทานของตัวเอง จงเลื่อนไฟล์ที่ตรวจทานแล้วขึ้นแทน

อัปโหลดไฟล์แจกจ่ายไปยังที่เก็บ artifact ที่แพลตฟอร์ม CI ของคุณมีให้ และให้งานภายในอ้างอิง artifact ชิ้นนั้นโดยเฉพาะ ไม่ใช่ชื่อสาขา

sha256sum dist/*.whl dist/*.tar.gz
# keep the digests beside the run id in the artifact description

หากแพลตฟอร์มของคุณรองรับแหล่งกำเนิดที่ลงนาม ขอให้รับรอง artifact แล้วตรวจสอบที่เก็บ workflow และ revision ของซอร์สที่คาดไว้ภายหลัง เอกสารการรับรอง ของ GitHub อธิบายข้อกล่าวอ้างในรูปแบบนั้น ลายเซ็นที่ใช้ได้คือหลักฐานแหล่งกำเนิด ไม่ใช่การสแกนช่องโหว่และไม่ใช่การตัดสินใจอนุญาต

ตรวจสอบภายในก่อนอัปโหลด

งานภายในเริ่มด้วยการตรวจว่าไฟล์ที่ได้รับคือไฟล์ที่ได้รับการอนุมัติ เปรียบเทียบไดเจสต์กับบันทึกจากงานบิลด์ ไม่ใช่กับค่าที่คำนวณใหม่จากสิ่งที่มาถึง

sha256sum -c digests.txt
python -m twine check dist/*

จากนั้นอ่าน metadata ชื่อแพ็กเกจ เวอร์ชัน และ dependency ที่ประกาศไว้ควรตรงกับบทตรวจทานที่คุณอนุมัติ wheel ที่ชื่อดูถูกต้องแต่ pin ของ dependency เปลี่ยนไปคือแพ็กเกจอื่นที่ติดป้ายเดียวกัน หาก metadata เคลื่อนไป ให้ถือว่า artifact ไม่ได้รับการอนุมัติและหาว่าบิลด์ใดสร้างมัน

หากไดเจสต์ไม่ตรงกัน ให้หยุด อย่าอัปโหลด และอย่าแก้ไฟล์ด้วยการสร้างใหม่ในที่เดิม เพราะจะลบหลักฐานว่ามีบางอย่างเปลี่ยนไประหว่างทาง ความไม่ตรงกันหมายความว่าที่เก็บ artifact ขั้นตอนดาวน์โหลด หรือบันทึกผิด และแต่ละอย่างสมควรได้รับการอธิบายก่อนเผยแพร่รีลีส

จัดการคำตอบเรื่องเวอร์ชันซ้ำ

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

เวอร์ชันที่มีอยู่หมายความได้ว่าการอัปโหลดก่อนหน้าสำเร็จแต่คำตอบหายไป หรือมีคนเผยแพร่เนื้อหาอื่นภายใต้หมายเลขเดียวกัน

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

เก็บข้อมูลรับรองการอัปโหลดไว้ฝั่งเดียว

มีเพียงผู้เผยแพร่ภายในที่ต้องการข้อมูลรับรองของที่เก็บ และเพียงช่วงเวลาอัปโหลด จำกัด token ให้อยู่ที่ที่เก็บเป้าหมายและปฏิบัติการอัปโหลด เก็บไว้ในที่เก็บความลับของระบบภายใน และกันออกจากงานบิลด์โดยสิ้นเชิง หากงานบิลด์เผยแพร่ได้ ใครก็ตามที่เปลี่ยนบิลด์ได้ก็เผยแพร่ได้

จำกัดด้วยว่า workflow ภายในใดเริ่มผู้เผยแพร่ได้ ตัวกระตุ้นแบบมือพร้อมการอนุมัติที่บังคับเป็นค่าเริ่มต้นที่สมเหตุสมผลสำหรับรีลีส ส่วน push ไปยังสาขาใดก็ได้ไม่ใช่

รีลีสที่เสร็จแล้วควรทิ้งสามอย่างไว้: ไฟล์แจกจ่าย ไดเจสต์ของไฟล์เหล่านั้นพร้อม revision ของซอร์ส และบันทึกของที่เก็บที่แสดงเวอร์ชันเดียวกัน