ააწყვეთ Python wheel ქსელის გარეთ და გამოაქვეყნეთ შიგნით

თქვენ უკვე გაქვთ build-სამუშაო, რომელიც wheel-ს აწარმოებს, და კერძო რეპოზიტორი, რომელმაც ის უნდა მიიღოს. შეცდომაა, თუ მეორე სამუშაოს საშუალებას მისცემთ ტოტიდან ხელახლა ააწყოს და შედეგს იგივე გამოშვება უწოდოს. გადაიტანეთ ის ფაილი, რომელიც გამოიცადა, დაარქვით სახელი დაიჯესტის მიხედვით და ატვირთვის სერტიფიკატი შიგნით შეინახეთ. ქვემოთ მოცემული აღწერა ერთ არტეფაქტს მიჰყვება საჯარო CI runner-იდან შიდა გამომქვეყნებლამდე.

ააწყვეთ იქ, სადაც წყარო უკვე არის

გაუშვით build იმ სამუშაოში, რომელსაც უკვე აქვს წყარო, ხელსაწყოების ჯაჭვი და ტესტების ნაკრები. კერძო რეპოზიტორთან დაკავშირებით არაფერი მოითხოვს, რომ ეს სამუშაო მას მიაღწიოს. დააყენეთ build-ის frontend იმ გარემოში, რომელსაც პროექტი უკვე იყენებს, შემდეგ აწარმოეთ გავრცელების ორივე ფორმატი, თუ პროექტი ორივეს აწვდის.

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

შეინახეთ გამოსავლის საქაღალდე პატარა და ერთჯერადი. წინ გადასატანად ღირს მხოლოდ ის ფაილები, რომლებსაც შემდეგი სამუშაო გამოაქვეყნებს, მათ ჰეშებთან ერთად. დანარჩენი ყველაფერი, ვირტუალური გარემოებისა და ქეშების ჩათვლით, შეიძლება ხელახლა აშენდეს ჩაწერილი წყაროს რევიზიიდან. გამხდარი არტეფაქტის გადახედვაც უფრო ადვილია, რადგან მასში ყოველი ფაილი ის ფაილია, რომლის დათვალიერებაც ვინმეს შეუძლია.

ჩაწერეთ, რამ შექმნა ისინი: პაკეტის სახელი და ვერსია ფაილების სახელებიდან, წყაროს რევიზია და ის workflow-ის გაშვება, რომელმაც ისინი შექმნა. მხოლოდ ვერსიის სტრიქონი ფაილს არ იდენტიფიცირებს, რადგან იგივე ვერსია ორჯერ შეიძლება აშენდეს სხვადასხვა commit-იდან. დაწერეთ რევიზია ფაილების სახელების გვერდით არტეფაქტის აღწერაში და ეს ჩანაწერი გადაცემის ნაწილად ჩათვალეთ.

გადაიტანეთ ბაიტები და არა ხელახალი აწყობის ინსტრუქციები

მეორე build მეორე პროდუქტია. დროის ნიშნები, ჩაშენებული დამოკიდებულებები და ხელსაწყოების ვერსიები ყველა ბაიტებს ცვლის, ამიტომ ხელახალ აწყობას საკუთარი ტესტური მტკიცებულება და საკუთარი გადახედვა სჭირდება. სამაგიერთოდ წინ წაიწიეთ უკვე გადახედილი ფაილები.

ატვირთეთ გავრცელების ფაილები იმ არტეფაქტების საცავში, რომელსაც თქვენი CI პლატფორმა გთავაზობთ, და შიდა სამუშაოს მიეცით მითითება სწორედ ამ არტეფაქტზე და არა ტოტის სახელზე.

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

თუ თქვენი პლატფორმა ხელმოწერილ წარმომავლობას მხარს უჭერს, სთხოვეთ მას არტეფაქტის დამოწმება და მოგვიანებით მოსალოდნელი რეპოზიტორის, workflow-ისა და წყაროს რევიზიის შემოწმება. GitHub-ის დამოწმების დოკუმენტაცია აღწერს ასეთი ფორმის მტკიცებებს. ვალიდური ხელმოწერა წარმომავლობის მტკიცებულებაა და არა მოწყვლადობების სკანირება და არც ავტორიზაციის გადაწყვეტილება.

შიგნით შეამოწმეთ ატვირთვამდე

შიდა სამუშაო იწყება იმის შემოწმებით, რომ მიღებული ფაილი ის ფაილია, რომელიც დამტკიცდა. შეადარეთ დაიჯესტები build-სამუშაოს ჩანაწერს და არა მნიშვნელობას, რომელიც ხელახლა გამოითვალა მოსული მონაცემებიდან.

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

შემდეგ წაიკითხეთ მეტამონაცემები. პაკეტის სახელი, ვერსია და გამოცხადებული დამოკიდებულებები უნდა შეესაბამებოდეს თქვენ მიერ დამტკიცებულ გადახედვას. wheel, რომლის სახელი სწორი ჩანს, მაგრამ დამოკიდებულებების pin-ები შეიცვალა, სხვა პაკეტია იმავე ეტიკეტით. თუ მეტამონაცემები გადაადგილდა, არტეფაქტი დაუმტკიცებლად ჩათვალეთ და გაარკვიეთ, რომელმა build-მა შექმნა ის.

თუ დაიჯესტები არ ემთხვევა, გაჩერდით. არ ატვირთოთ და ნუ შეაკეთებთ ფაილს ადგილზე ხელახალი აწყობით; ეს შლის იმ მტკიცებულებას, რომ გზაში რაღაც შეიცვალა. შეუსაბამობა ნიშნავს, რომ არტეფაქტების საცავი, ჩამოტვირთვის საფეხური ან ჩანაწერი მცდარია და თითოეული მათგანი ახსნას იმსახურებს გამოშვების გამოქვეყნებამდე.

გაუმკლავდით დუბლირებული ვერსიის პასუხს

კერძო რეპოზიტორები ჩვეულებრივ უარს ამბობენ არსებული ვერსიის გადაწერაზე და ეს უარი თვისებაა. როცა ატვირთვა ვერ ხერხდება იმიტომ, რომ ვერსია არსებობს, დაათვალიერეთ რეპოზიტორის ჩანაწერი ამ ვერსიისთვის და შეადარეთ მის მიერ შენახული ფაილები იმ დაიჯესტებს, რომელთა გამოქვეყნებასაც აპირებდით.

არსებული ვერსია შეიძლება ნიშნავდეს, რომ წინა ატვირთვა წარმატებული იყო და პასუხი დაიკარგა, ან რომ ვინმემ იმავე ნომრის ქვეშ სხვა შიგთავსი გამოაქვეყნა.

ნუ წაშლით ვერსიას და ნუ გამოიგონებთ ახალ ნომერს შეცდომის გვერდის ასავლელად. გადაწყვიტეთ გამოშვების მფლობელთან ერთად, მისაღებია თუ არა შენახული შიგთავსი, შემდეგ ჩაწერეთ შედეგი. თუ შიგთავსი განსხვავებულია, თქვენ გაქვთ ვერსიონირების პრობლემა და არა pipeline-ის პრობლემა.

ატვირთვის სერტიფიკატი ერთ მხარეს შეინახეთ

რეპოზიტორის სერტიფიკატები მხოლოდ შიდა გამომქვეყნებელს სჭირდება და მხოლოდ ატვირთვის ხანგრძლივობით. შეზღუდეთ token სამიზნე რეპოზიტორითა და ატვირთვის ოპერაციებით, შეინახეთ ის შიდა სისტემის საიდუმლოებათა საცავში და მთლიანად გარეთ დატოვეთ build-სამუშაოდან. თუ build-სამუშაოს გამოქვეყნება შეუძლია, მაშინ ყველას, ვისაც build-ის შეცვლა შეუძლია, გამოქვეყნებაც შეუძლია.

შეზღუდეთ აგრეთვე, რომელ შიდა workflow-ებს შეუძლიათ გამომქვეყნებლის გაშვება. ხელით გამშვები სავალდებულო დამტკიცებით გამოშვებებისთვის გონივრული ნაგულისხმევია; ნებისმიერ ტოტში push — არა.

დასრულებულმა გამოშვებამ სამი რამ უნდა დატოვოს: გავრცელების ფაილები, მათი დაიჯესტები წყაროს რევიზიასთან ერთად და რეპოზიტორის ჩანაწერი, რომელიც იმავე ვერსიას აჩვენებს.