Tạo wheel Python bên ngoài mạng và phát hành vào bên trong

Bạn đã có một job build tạo ra wheel và một kho riêng tư lẽ ra phải nhận nó. Sai lầm là để một job thứ hai build lại từ một nhánh rồi gọi kết quả đó là cùng một bản phát hành. Hãy chuyển tệp đã được kiểm thử, đặt tên theo digest và giữ thông tin đăng nhập tải lên ở bên trong. Phần trình bày dưới đây theo một artifact từ runner CI công cộng đến nhà phát hành nội bộ.

Tạo ở nơi mã nguồn đã có

Chạy build trong job đã có mã nguồn, bộ công cụ và bộ kiểm thử. Không có gì ở một kho riêng tư đòi hỏi job đó phải truy cập tới nó. Cài build frontend trong môi trường dự án đang dùng, rồi tạo cả hai định dạng phân phối nếu dự án phát hành cả hai.

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

Giữ thư mục đầu ra nhỏ và dùng một lần. Thứ duy nhất đáng mang theo là các tệp mà job tiếp theo sẽ phát hành, cùng mã băm của chúng. Mọi thứ khác, kể cả môi trường ảo và bộ nhớ đệm, đều có thể dựng lại từ bản sửa đổi mã nguồn đã ghi. Một artifact gọn cũng dễ xem xét hơn, vì mỗi tệp trong đó là tệp mà ai đó có thể kiểm tra.

Ghi lại thứ đã tạo ra chúng: tên gói và phiên bản từ tên tệp, bản sửa đổi mã nguồn, và lần chạy workflow đã tạo ra chúng. Chỉ một chuỗi phiên bản không nhận diện được tệp, vì cùng một phiên bản có thể được build hai lần từ các commit khác nhau. Viết bản sửa đổi bên cạnh tên tệp trong phần mô tả artifact và coi bản ghi đó là một phần của việc bàn giao.

Chuyển byte, không phải chỉ dẫn build lại

Lần build thứ hai là sản phẩm thứ hai. Dấu thời gian, phụ thuộc đi kèm và phiên bản công cụ đều có thể thay đổi byte, nên việc build lại cần bằng chứng kiểm thử và bản xem xét của riêng nó. Thay vào đó, hãy thăng cấp các tệp đã được xem xét.

Tải các tệp phân phối lên kho artifact mà nền tảng CI của bạn cung cấp và cho job nội bộ một tham chiếu tới đúng artifact đó thay vì tên nhánh.

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

Nếu nền tảng của bạn hỗ trợ nguồn gốc được ký, hãy yêu cầu nó chứng thực artifact và sau đó xác minh kho, workflow và bản sửa đổi mã nguồn mong đợi. Tài liệu về chứng thực của GitHub mô tả các tuyên bố theo dạng đó. Một chữ ký hợp lệ là bằng chứng nguồn gốc, không phải quét lỗ hổng và không phải quyết định cấp quyền.

Xác minh bên trong trước khi tải lên

Job nội bộ bắt đầu bằng việc kiểm tra rằng tệp nhận được chính là tệp đã được phê duyệt. So sánh digest với bản ghi từ job build, không so với giá trị tính lại từ thứ đã đến.

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

Sau đó đọc siêu dữ liệu. Tên gói, phiên bản và các phụ thuộc được khai báo phải khớp với bản xem xét bạn đã phê duyệt. Một wheel có tên trông đúng nhưng các ghim phụ thuộc đã thay đổi là một gói khác mang cùng nhãn. Nếu siêu dữ liệu đã dịch chuyển, hãy coi artifact là chưa được phê duyệt và tìm ra build nào đã tạo ra nó.

Nếu digest không khớp, hãy dừng. Đừng tải lên và đừng sửa tệp bằng cách build lại tại chỗ; việc đó xóa bằng chứng rằng có gì đó đã thay đổi trên đường đi. Sự không khớp nghĩa là kho artifact, bước tải xuống hoặc bản ghi bị sai, và mỗi thứ đó xứng đáng có lời giải thích trước khi phát hành một bản.

Xử lý câu trả lời về phiên bản trùng

Các kho riêng tư thường từ chối ghi đè một phiên bản đã có, và sự từ chối đó là một tính năng. Khi tải lên thất bại vì phiên bản đã tồn tại, hãy kiểm tra bản ghi của kho cho phiên bản đó và so sánh các tệp nó giữ với các digest bạn định phát hành.

Một phiên bản đã có thể nghĩa là lần tải lên trước đã thành công và phản hồi bị mất, hoặc ai đó đã phát hành nội dung khác dưới cùng con số.

Đừng xóa phiên bản và đừng bịa một con số mới để vượt qua lỗi. Quyết định cùng chủ bản phát hành xem nội dung đã lưu có chấp nhận được không, rồi ghi lại kết quả. Nếu nội dung khác, bạn có vấn đề về đánh phiên bản, không phải vấn đề pipeline.

Giữ thông tin đăng nhập tải lên ở một phía

Chỉ nhà phát hành nội bộ cần thông tin đăng nhập kho, và chỉ trong thời gian tải lên. Giới hạn token cho kho đích và cho các thao tác tải lên, giữ nó trong kho bí mật của hệ thống nội bộ và để nó hoàn toàn ngoài job build. Nếu job build có thể phát hành, thì ai có thể thay đổi build cũng có thể phát hành.

Cũng hãy giới hạn workflow nội bộ nào được khởi động nhà phát hành. Kích hoạt thủ công với phê duyệt bắt buộc là mặc định hợp lý cho các bản phát hành; push vào bất kỳ nhánh nào thì không.

Bản phát hành hoàn tất nên để lại ba thứ: các tệp phân phối, digest của chúng cùng bản sửa đổi mã nguồn, và một bản ghi kho cho thấy cùng phiên bản.