Bouw een Python-wheel buiten het netwerk en publiceer het binnen

Je hebt al een buildtaak die een wheel maakt, en een privérepository die het hoort te ontvangen. De fout is een tweede taak vanaf een branch opnieuw te laten bouwen en het resultaat dezelfde release te noemen. Verplaats het bestand dat is getest, noem het naar de digest en houd de uploadreferentie binnen. De uitleg hieronder volgt één artefact van een openbare CI-runner tot een interne uitgever.

Bouw waar de broncode al staat

Voer de build uit in de taak die al de broncode, de toolchain en de testsuite heeft. Niets aan een privérepository vereist dat die taak hem bereikt. Installeer de build-frontend in de omgeving die het project al gebruikt en produceer daarna beide distributieformaten als het project ze allebei levert.

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

Houd de uitvoermap klein en wegwerpbaar. Alleen de bestanden die de volgende taak publiceert, plus hun hashes, zijn het waard om mee te nemen. Al het andere, inclusief virtuele omgevingen en caches, kan opnieuw worden gebouwd uit de vastgelegde bronrevisie. Een slank artefact is ook makkelijker te beoordelen, omdat elk bestand erin een bestand is dat iemand kan inspecteren.

Leg vast wat ze heeft geproduceerd: de pakketnaam en versie uit de bestandsnamen, de bronrevisie en de workflow-run die ze heeft gemaakt. Een versiestring alleen identificeert geen bestand, want dezelfde versie kan twee keer uit verschillende commits worden gebouwd. Schrijf de revisie naast de bestandsnamen in de artefactbeschrijving en behandel die registratie als onderdeel van de overdracht.

Verplaats bytes, geen instructies om opnieuw te bouwen

Een tweede build is een tweede product. Tijdstempels, meegebundelde afhankelijkheden en toolversies kunnen allemaal de bytes veranderen, dus een herbouw heeft eigen testbewijs en een eigen beoordeling nodig. Promoveer in plaats daarvan de beoordeelde bestanden.

Upload de distributiebestanden naar de artefactopslag die je CI-platform biedt, en geef de interne taak een verwijzing naar dat specifieke artefact in plaats van naar een branchnaam.

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

Als je platform ondertekende herkomst ondersteunt, vraag het dan het artefact te attesteren en later de verwachte repository, workflow en bronrevisie te verifiëren. GitHubs documentatie over attestaties beschrijft beweringen van die vorm. Een geldige handtekening is herkomstbewijs, geen kwetsbaarheidsscan en geen autorisatiebeslissing.

Verifieer binnen voordat je uploadt

De interne taak begint met te controleren of het ontvangen bestand het bestand is dat is goedgekeurd. Vergelijk digests met de registratie van de buildtaak, niet met een waarde die opnieuw is berekend uit wat er is aangekomen.

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

Lees daarna de metadata. De pakketnaam, de versie en de gedeclareerde afhankelijkheden horen te kloppen met de beoordeling die je hebt goedgekeurd. Een wheel waarvan de naam juist lijkt maar waarvan de afhankelijkheidspins zijn veranderd, is een ander pakket met hetzelfde label. Als de metadata is verschoven, behandel het artefact dan als niet goedgekeurd en zoek uit welke build het heeft geproduceerd.

Komen de digests niet overeen, stop dan. Upload niet en repareer het bestand niet door het ter plaatse opnieuw te bouwen; dat wist het bewijs dat er onderweg iets is veranderd. Een afwijking betekent dat de artefactopslag, de downloadstap of de registratie fout is, en elk daarvan verdient uitleg voordat een release wordt gepubliceerd.

Ga om met het antwoord over dubbele versies

Privérepositories weigeren meestal een bestaande versie te overschrijven, en die weigering is een functie. Als een upload mislukt omdat de versie bestaat, bekijk dan de registratie van de repository voor die versie en vergelijk de bestanden die hij bevat met de digests die je wilde publiceren.

Een bestaande versie kan betekenen dat een eerdere upload slaagde en het antwoord verloren ging, of dat iemand andere inhoud onder hetzelfde nummer heeft gepubliceerd.

Verwijder de versie niet en verzin geen nieuw nummer om de fout te omzeilen. Beslis met de release-eigenaar of de opgeslagen inhoud acceptabel is en leg de uitkomst vast. Als de inhoud afwijkt, heb je een versieprobleem, geen pipelineprobleem.

Houd de uploadreferentie aan één kant

Alleen de interne uitgever heeft repositoryreferenties nodig, en alleen zolang de upload duurt. Beperk het token tot de doelrepository en tot uploadbewerkingen, bewaar het in de geheime opslag van het interne systeem en houd het volledig buiten de buildtaak. Als de buildtaak kan publiceren, dan kan iedereen die de build kan wijzigen publiceren.

Beperk ook welke interne workflows de uitgever mogen starten. Een handmatige trigger met verplichte goedkeuring is een redelijke standaard voor releases; een push naar welke branch dan ook is dat niet.

De voltooide release zou drie dingen achter moeten laten: de distributiebestanden, hun digests met de bronrevisie, en een repositoryregistratie die dezelfde versie toont.