Zbuduj wheel Pythona poza siecią i opublikuj go w środku

Masz już zadanie budowania, które tworzy wheel, oraz prywatne repozytorium, które powinno go otrzymać. Błędem jest pozwolić drugiemu zadaniu przebudować wszystko z gałęzi i nazwać wynik tym samym wydaniem. Przenieś plik, który został przetestowany, nazwij go skrótem i trzymaj poświadczenie wysyłki po wewnętrznej stronie. Poniższy opis prowadzi jeden artefakt od publicznego runnera CI do wewnętrznego wydawcy.

Buduj tam, gdzie już leży kod źródłowy

Uruchom budowanie w zadaniu, które ma już kod źródłowy, łańcuch narzędzi i zestaw testów. Prywatne repozytorium w niczym nie wymaga, aby to zadanie miało do niego dostęp. Zainstaluj frontend budowania w środowisku, którego projekt już używa, a następnie wytwórz oba formaty dystrybucji, jeśli projekt dostarcza oba.

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

Utrzymuj katalog wyjściowy mały i jednorazowy. Jedyne, co warto przenieść dalej, to pliki, które opublikuje następne zadanie, oraz ich skróty. Wszystko inne, łącznie ze środowiskami wirtualnymi i pamięciami podręcznymi, można odtworzyć z zapisanej rewizji źródła. Lekki artefakt łatwiej też przejrzeć, bo każdy plik w nim jest plikiem, który ktoś może sprawdzić.

Zapisz, co je wytworzyło: nazwę pakietu i wersję z nazw plików, rewizję źródła oraz uruchomienie workflow, które je utworzyło. Sam ciąg wersji nie identyfikuje pliku, bo tę samą wersję można zbudować dwa razy z różnych commitów. Zapisz rewizję obok nazw plików w opisie artefaktu i traktuj ten zapis jako część przekazania.

Przenoś bajty, a nie instrukcje przebudowy

Drugie budowanie to drugi produkt. Znaczniki czasu, dołączone zależności i wersje narzędzi mogą zmienić bajty, więc przebudowa potrzebuje własnych dowodów z testów i własnego przeglądu. Zamiast tego promuj przejrzane pliki.

Wyślij pliki dystrybucji do magazynu artefaktów udostępnianego przez twoją platformę CI i daj wewnętrznemu zadaniu referencję do tego konkretnego artefaktu, a nie nazwę gałęzi.

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

Jeśli twoja platforma wspiera podpisane pochodzenie, poproś ją o poświadczenie artefaktu, a później zweryfikuj oczekiwane repozytorium, workflow i rewizję źródła. Dokumentacja poświadczeń GitHuba opisuje twierdzenia w takim kształcie. Ważny podpis jest dowodem pochodzenia, a nie skanem podatności i nie decyzją o autoryzacji.

Zweryfikuj po wewnętrznej stronie przed wysłaniem

Zadanie wewnętrzne zaczyna od sprawdzenia, czy plik, który otrzymało, jest plikiem, który zatwierdzono. Porównaj skróty z zapisem z zadania budowania, a nie z wartością przeliczoną z tego, co przyszło.

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

Potem przeczytaj metadane. Nazwa pakietu, wersja i zadeklarowane zależności powinny zgadzać się z przeglądem, który zatwierdziłeś. Wheel, którego nazwa wygląda dobrze, ale którego przypięcia zależności się zmieniły, to inny pakiet w tej samej etykiecie. Jeśli metadane się przesunęły, uznaj artefakt za niezatwierdzony i ustal, które budowanie go wytworzyło.

Jeśli skróty się nie zgadzają, zatrzymaj się. Nie wysyłaj i nie naprawiaj pliku przez przebudowanie go w miejscu; to wymazuje dowód, że coś zmieniło się w drodze. Niezgodność oznacza, że magazyn artefaktów, krok pobierania albo zapis jest błędny, a każde z tych miejsc zasługuje na wyjaśnienie, zanim wydanie zostanie opublikowane.

Jak potraktować odpowiedź o istniejącej wersji

Prywatne repozytoria zwykle odmawiają nadpisania istniejącej wersji i ta odmowa jest cechą, nie błędem. Gdy wysyłka kończy się niepowodzeniem, bo wersja istnieje, sprawdź zapis repozytorium dla tej wersji i porównaj przechowywane pliki ze skrótami, które zamierzałeś opublikować.

Istniejąca wersja może znaczyć, że wcześniejsza wysyłka się udała, a odpowiedź zginęła, albo że ktoś opublikował inną treść pod tym samym numerem.

Nie usuwaj wersji i nie wymyślaj nowego numeru, żeby obejść błąd. Zdecyduj z właścicielem wydania, czy przechowywana treść jest do przyjęcia, a potem zapisz wynik. Jeśli treść się różni, masz problem z wersjonowaniem, a nie problem z potokiem.

Trzymaj poświadczenie wysyłki po jednej stronie

Tylko wewnętrzny wydawca potrzebuje poświadczeń repozytorium i tylko na czas wysyłki. Ogranicz token do docelowego repozytorium i do operacji wysyłki, trzymaj go w magazynie sekretów systemu wewnętrznego i zostaw go całkowicie poza zadaniem budowania. Jeśli zadanie budowania może publikować, to każdy, kto może zmienić budowanie, może publikować.

Ogranicz też, które wewnętrzne workflow mogą uruchamiać wydawcę. Ręczne wyzwolenie z wymaganym zatwierdzeniem to rozsądna domyślna opcja dla wydań; push do dowolnej gałęzi nią nie jest.

Gotowe wydanie powinno zostawić trzy rzeczy: pliki dystrybucji, ich skróty wraz z rewizją źródła oraz zapis repozytorium pokazujący tę samą wersję.