Konstrui Python-wheel ekster la reto, publikigi ĝin interne

Vi jam havas konstruan taskon, kiu produktas wheel-on, kaj privatan deponejon, kiu devus ricevi ĝin. La eraro estas lasi duan taskon rekonstrui el branĉo kaj nomi la rezulton la sama eldono. Translokigu la dosieron, kiu estis testita, nomu ĝin laŭ la resumo, kaj tenu la alŝutan legitimilon interne. La priskribo sube sekvas unu artefakton de publika CI-rulilo al interna publikiganto.

Konstruu tie, kie la fontkodo jam estas

Rulu la konstruon en la tasko, kiu jam havas la fontkodon, la ilaron kaj la testaron. Nenio pri privata deponejo postulas, ke tiu tasko atingas ĝin. Instalu la konstruan fronton en la medio, kiun la projekto jam uzas, poste produktu ambaŭ distribufortmatojn se la projekto liveras ambaŭ.

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

Tenu la eligan dosierujon malgranda kaj unufoja. La solaj aferoj indaj porti antaŭen estas la dosieroj, kiujn la sekva tasko publikigos, plus iliaj haketoj. Ĉio alia, inkluzive virtualajn mediojn kaj kaŝmemorojn, povas esti rekonstruita el la registrita fontkoda revizio. Maldika artefakto ankaŭ pli facile revideblas, ĉar ĉiu dosiero en ĝi estas dosiero, kiun iu povas inspekti.

Registru, kio produktis ilin: la pakaĵnomon kaj version el la dosiernomoj, la revizion de la fontkodo, kaj la laborfluon, kiu kreis ilin. Versia ĉeno sola ne identigas dosieron, ĉar la sama versio povas esti konstruita dufoje el malsamaj kommitoj. Skribu la revizion apud la dosiernomoj en la artefakta priskribo, kaj traktu tiun registron kiel parton de la transdono.

Translokigu bitokojn, ne instrukciojn por rekonstrui

Dua konstruo estas dua produkto. Tempomarkoj, enpakitaj dependecoj kaj ilaraj versioj povas ĉiuj ŝanĝi la bitokojn, do rekonstruo bezonas siajn proprajn testajn pruvojn kaj sian propran revizion. Antaŭenigu anstataŭe la reviziitajn dosierojn.

Alŝutu la distribudosiierojn al la artefakta konservejo, kiun via CI-platformo provizas, kaj donu al la interna tasko referencon al tiu specifa artefakto anstataŭ al branĉa nomo.

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

Se via platformo subtenas subskribitan devenon, petu ĝin atesti la artefakton kaj poste kontroli la atendantan deponejon, laborfluon kaj revizion de la fontkodo. La dokumentaro de GitHub pri atestoj priskribas asertojn de tiu formo. Valida subskribo estas pruvo pri deveno, ne skano pri vundeblecoj kaj ne decido pri rajtigo.

Kontrolu interne antaŭ ol alŝuti

La interna tasko komenciĝas per kontrolo, ke la dosiero, kiun ĝi ricevis, estas la dosiero, kiu estis aprobita. Komparu resumojn kun la registro el la konstrua tasko, ne kun valoro rekalkulita el tio, kio alvenis.

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

Poste legu la metadatenojn. La pakaĵnomo, la versio kaj la deklaritaj dependecoj devus kongrui kun la revizio, kiun vi aprobis. Wheel, kies nomo aspektas ĝusta sed kies dependeccpingloj ŝanĝiĝis, estas alia pakaĵo portanta la saman etikedon. Se la metadatenoj moviĝis, traktu la artefakton kiel neaprobita kaj trovui, kiu konstruo produktis ĝin.

Se la resumoj ne kongruas, haltu. Ne alŝutu, kaj ne riparu la dosieron rekonstruante ĝin surloke; tio forviŝas la pruvon, ke io ŝanĝiĝis dum la transporto. Malkongruo signifas, ke la artefakta konservejo, la elŝuta paŝo aŭ la registro malĝustas, kaj ĉiu el ili meritas klarigon antaŭ ol eldono estas publikigita.

Traktu la respondon pri duobla versio

Privataj deponejoj kutime rifuzas anstataŭigi ekzistantan version, kaj tiu rifuzo estas trajto. Kiam alŝuto malsukcesas ĉar la versio ekzistas, inspektu la registron de la deponejo por tiu versio kaj komparu la dosierojn, kiujn ĝi enhavas, kun la resumoj, kiujn vi intencis publikigi.

Ekzistanta versio povas signifi, ke pli frua alŝuto sukcesis kaj la respondo perdiĝis, aŭ ke iu publikigis alian enhavon sub la sama numero.

Ne forigu la version, kaj ne elpensu novan numeron por preteriri la eraron. Decidu kun la eldonposedanto, ĉu la konservita enhavo estas akceptebla, poste registru la rezulton. Se la enhavo diferencas, vi havas versionan problemon, ne pipelinan problemon.

Tenu la alŝutan legitimilon unuflanke

Nur la interna publikiganto bezonas deponejajn legitimilojn, kaj nur dum la alŝuto. Limigu la ĵetonon al la cella deponejo kaj al alŝutaj operacioj, tenu ĝin en la sekreta konservejo de la interna sistemo, kaj tenu ĝin tute ekster la konstrua tasko. Se la konstrua tasko povas publikigi, tiam ĉiu, kiu povas ŝanĝi la konstruon, povas publikigi.

Limigu ankaŭ, kiuj internaj laborfluoj rajtas lanĉi la publikiganton. Mana ellasilo kun postulata aprobo estas racia defaŭlto por eldonoj; puŝo al ajna branĉo ne estas.

La finita eldono devus postlasi tri aferojn: la distribudosiierojn, iliajn resumojn kun la revizio de la fontkodo, kaj deponejan registron montrantan la saman version.