Желіден тыс Python wheel құрастырып, оны ішінде жариялаңыз

Сізде wheel шығаратын build жұмысы және оны қабылдауы тиіс жеке репозиторий бар. Қате — екінші жұмысқа тармақтан қайта құрастыруға рұқсат беріп, нәтижені сол релиз деп атау. Сыналған файлды жылжытыңыз, оны дайджест бойынша атаңыз және жүктеу тіркелгісін іште ұстаңыз. Төмендегі сипаттама бір артефактіні ашық 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/*

Сосын метадеректерді оқыңыз. Пакет атауы, нұсқасы және жарияланған тәуелділіктер сіз бекіткен қарауға сәйкес болуы керек. Атауы дұрыс көрінетін, бірақ тәуелділік pin-дері өзгерген wheel — сол жапсырманы киген басқа пакет. Метадеректер жылжыса, артефактіні бекітілмеген деп санап, оны қай build жасағанын анықтаңыз.

Дайджесттер сәйкеспесе, тоқтаңыз. Жүктемеңіз және файлды орнында қайта құрастырып түзетпеңіз; бұл тасымалда бірдеңе өзгергенінің дәлелін жояды. Сәйкессіздік артефакт қоймасы, жүктеу қадамы немесе жазба қате дегенді білдіреді және олардың әрқайсысы релиз жарияланбай тұрып түсіндіруге лайық.

Қайталанған нұсқа жауабын шешіңіз

Жеке репозиторийлер әдетте бар нұсқаны қайта жазудан бас тартады және бұл бас тарту — ерекшелік. Нұсқа бар болғандықтан жүктеу сәтсіз болса, сол нұсқа бойынша репозиторий жазбасын қарап, ондағы файлдарды жарияламақ болған дайджесттермен салыстырыңыз.

Бар нұсқа бұрынғы жүктеу сәтті болып, жауап жоғалғанын білдіруі мүмкін, немесе біреу сол нөмірмен басқа мазмұн жариялағанын.

Нұсқаны жоймаңыз және қатені айналып өту үшін жаңа нөмір ойлап таппаңыз. Сақталған мазмұн қабылданады ма, соны релиз иесімен шешіп, нәтижесін жазыңыз. Мазмұн басқа болса, сізде нұсқалау мәселесі бар, pipeline мәселесі емес.

Жүктеу тіркелгісін бір жақта ұстаңыз

Репозиторий тіркелгілері тек ішкі жариялаушыға керек және тек жүктеу ұзақтығында. Токенді мақсатты репозиториймен және жүктеу операцияларымен шектеңіз, оны ішкі жүйенің құпиялар қоймасында ұстаңыз және build жұмысынан толық шығарыңыз. Егер build жұмысы жариялай алса, build-ті өзгерте алатын кез келген адам да жариялай алады.

Қай ішкі workflow-лер жариялаушыны іске қоса алатынын да шектеңіз. Міндетті бекітуі бар қолмен іске қосқыш релиздер үшін орынды әдепкі; кез келген тармаққа push — олай емес.

Аяқталған релиз үш нәрсені қалдыруы керек: тарату файлдарын, олардың дайджесттерін бастапқы код ревизиясымен бірге және сол нұсқаны көрсететін репозиторий жазбасын.