Κατασκευάστε ένα Python wheel έξω από το δίκτυο και δημοσιεύστε το μέσα

Έχετε ήδη μια εργασία build που παράγει ένα wheel και ένα ιδιωτικό αποθετήριο που πρέπει να το παραλάβει. Το λάθος είναι να αφήσετε μια δεύτερη εργασία να ξαναχτίσει από ένα branch και να ονομάσετε το αποτέλεσμα την ίδια κυκλοφορία. Μεταφέρετε το αρχείο που δοκιμάστηκε, ονομάστε το με βάση το digest και κρατήστε το διαπιστευτήριο ανεβάσματος στο εσωτερικό. Η περιήγηση παρακάτω ακολουθεί ένα artefact από έναν δημόσιο CI runner σε έναν εσωτερικό publisher.

Χτίστε εκεί που βρίσκεται ήδη ο πηγαίος κώδικας

Εκτελέστε το build στην εργασία που έχει ήδη τον πηγαίο κώδικα, την αλυσίδα εργαλείων και το σύνολο δοκιμών. Τίποτα στο ιδιωτικό αποθετήριο δεν απαιτεί να το προσεγγίσει αυτή η εργασία. Εγκαταστήστε το frontend του build στο περιβάλλον που χρησιμοποιεί ήδη το έργο και μετά παράγετε και τις δύο μορφές διανομής αν το έργο τις διανέμει και τις δύο.

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

Κρατήστε τον κατάλογο εξόδου μικρό και μιας χρήσης. Το μόνο που αξίζει να μεταφερθεί είναι τα αρχεία που θα δημοσιεύσει η επόμενη εργασία, μαζί με τα hashes τους. Όλα τα άλλα, μαζί με εικονικά περιβάλλοντα και caches, μπορούν να ξαναχτιστούν από την καταγεγραμμένη αναθεώρηση του πηγαίου κώδικα. Ένα λιτό artefact είναι επίσης ευκολότερο να ελεγχθεί, γιατί κάθε αρχείο του είναι ένα αρχείο που κάποιος μπορεί να επιθεωρήσει.

Καταγράψτε τι τα παρήγαγε: το όνομα του πακέτου και την έκδοση από τα ονόματα των αρχείων, την αναθεώρηση του πηγαίου κώδικα και την εκτέλεση του workflow που τα δημιούργησε. Ένα μόνο string έκδοσης δεν ταυτοποιεί ένα αρχείο, γιατί η ίδια έκδοση μπορεί να χτιστεί δύο φορές από διαφορετικά commits. Γράψτε την αναθεώρηση δίπλα στα ονόματα των αρχείων στην περιγραφή του artefact και θεωρήστε αυτή την καταγραφή μέρος της παράδοσης.

Μεταφέρετε bytes, όχι οδηγίες για ξαναχτίσιμο

Ένα δεύτερο build είναι ένα δεύτερο προϊόν. Χρονικές σημάνσεις, ενσωματωμένες εξαρτήσεις και εκδόσεις εργαλείων μπορούν όλα να αλλάξουν τα bytes, άρα ένα ξαναχτίσιμο χρειάζεται τα δικά του αποδεικτικά δοκιμών και τη δική του ανασκόπηση. Προωθήστε αντ' αυτού τα ελεγμένα αρχεία.

Ανεβάστε τα αρχεία διανομής στο χώρο αποθήκευσης artefact που παρέχει η πλατφόρμα CI σας και δώστε στην εσωτερική εργασία αναφορά σε αυτό ακριβώς το artefact και όχι σε όνομα branch.

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

Αν η πλατφόρμα σας υποστηρίζει υπογεγραμμένη προέλευση, ζητήστε της να βεβαιώσει το artefact και αργότερα να επαληθεύσει το αναμενόμενο αποθετήριο, το workflow και την αναθεώρηση του πηγαίου κώδικα. Η τεκμηρίωση του GitHub για τις βεβαιώσεις περιγράφει ισχυρισμούς αυτής της μορφής. Μια έγκυρη υπογραφή είναι απόδειξη προέλευσης, όχι σάρωση ευπαθειών και όχι απόφαση εξουσιοδότησης.

Επαληθεύστε στο εσωτερικό πριν το ανέβασμα

Η εσωτερική εργασία ξεκινά ελέγχοντας ότι το αρχείο που έλαβε είναι το αρχείο που εγκρίθηκε. Συγκρίνετε τα digests με την καταγραφή από την εργασία build, όχι με μια τιμή που υπολογίστηκε ξανά από ό,τι έφτασε.

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

Μετά διαβάστε τα μεταδεδομένα. Το όνομα του πακέτου, η έκδοση και οι δηλωμένες εξαρτήσεις πρέπει να ταιριάζουν με την ανασκόπηση που εγκρίνατε. Ένα wheel του οποίου το όνομα φαίνεται σωστό αλλά τα pins των εξαρτήσεων άλλαξαν είναι άλλο πακέτο με την ίδια ετικέτα. Αν τα μεταδεδομένα μετακινήθηκαν, θεωρήστε το artefact μη εγκεκριμένο και βρείτε ποιο build το παρήγαγε.

Αν τα digests δεν ταιριάζουν, σταματήστε. Μην ανεβάσετε και μην επισκευάσετε το αρχείο ξαναχτίζοντάς το επί τόπου· αυτό σβήνει την απόδειξη ότι κάτι άλλαξε κατά τη μεταφορά. Μια ασυμφωνία σημαίνει ότι ο χώρος artefact, το βήμα λήψης ή η καταγραφή είναι λάθος, και καθένα από αυτά αξίζει μια εξήγηση πριν δημοσιευτεί μια κυκλοφορία.

Χειριστείτε την απάντηση για διπλή έκδοση

Τα ιδιωτικά αποθετήρια συνήθως αρνούνται να αντικαταστήσουν μια υπάρχουσα έκδοση και αυτή η άρνηση είναι χαρακτηριστικό. Όταν ένα ανέβασμα αποτυγχάνει επειδή η έκδοση υπάρχει, επιθεωρήστε την καταγραφή του αποθετηρίου για αυτή την έκδοση και συγκρίνετε τα αρχεία που κρατά με τα digests που σκοπεύατε να δημοσιεύσετε.

Μια υπάρχουσα έκδοση μπορεί να σημαίνει ότι ένα προηγούμενο ανέβασμα πέτυχε και η απάντηση χάθηκε, ή ότι κάποιος δημοσίευσε διαφορετικό περιεχόμενο με τον ίδιο αριθμό.

Μη διαγράψετε την έκδοση και μην επινοήσετε νέο αριθμό για να ξεπεράσετε το σφάλμα. Αποφασίστε με τον ιδιοκτήτη της κυκλοφορίας αν το αποθηκευμένο περιεχόμενο είναι αποδεκτό και μετά καταγράψτε το αποτέλεσμα. Αν το περιεχόμενο διαφέρει, έχετε πρόβλημα εκδόσεων, όχι πρόβλημα pipeline.

Κρατήστε το διαπιστευτήριο ανεβάσματος στη μία πλευρά

Μόνο ο εσωτερικός publisher χρειάζεται διαπιστευτήρια αποθετηρίου και μόνο για όσο διαρκεί το ανέβασμα. Περιορίστε το token στο αποθετήριο-στόχο και στις λειτουργίες ανεβάσματος, κρατήστε το στο secret store του εσωτερικού συστήματος και αφήστε το εντελώς έξω από την εργασία build. Αν η εργασία build μπορεί να δημοσιεύσει, τότε μπορεί να δημοσιεύσει και όποιος μπορεί να αλλάξει το build.

Περιορίστε επίσης ποια εσωτερικά workflows επιτρέπεται να ξεκινήσουν τον publisher. Ένα χειροκίνητο trigger με απαιτούμενη έγκριση είναι λογική προεπιλογή για κυκλοφορίες· ένα push σε οποιοδήποτε branch δεν είναι.

Η ολοκληρωμένη κυκλοφορία πρέπει να αφήσει πίσω της τρία πράγματα: τα αρχεία διανομής, τα digests τους μαζί με την αναθεώρηση του πηγαίου κώδικα και μια καταγραφή αποθετηρίου που δείχνει την ίδια έκδοση.