Lỗi trong hệ thống xây dựng do thay đổi tổng kiểm tra kho lưu trữ trên GitHub

GitHub đã thay đổi cách tạo các kho lưu trữ “.tar.gz” và “.tgz” được tạo tự động trên các trang phát hành, dẫn đến những thay đổi về tổng kiểm tra của chúng và lỗi lớn trong các hệ thống xây dựng tự động kiểm tra các kho lưu trữ được tải xuống từ GitHub so với các kho lưu trữ trước đó để xác nhận tính toàn vẹn .. tổng kiểm tra được lưu trữ, ví dụ: được đặt trong siêu dữ liệu gói hoặc trong tập lệnh xây dựng.

Bắt đầu từ bản phát hành 2.38, bộ công cụ Git bao gồm triển khai gzip tích hợp theo mặc định, giúp có thể thống nhất hỗ trợ cho phương pháp nén này trên các hệ điều hành và cải thiện hiệu suất tạo kho lưu trữ. GitHub đã nhận ra thay đổi này sau khi cập nhật phiên bản git trong cơ sở hạ tầng của mình. Vấn đề xảy ra là do các kho lưu trữ nén được tạo ra bởi quá trình triển khai gzip dựa trên zlib tích hợp có dạng nhị phân khác với các kho lưu trữ được tạo bởi tiện ích gzip, dẫn đến các tổng kiểm tra khác nhau cho các kho lưu trữ được tạo bởi các phiên bản git khác nhau khi thực thi lệnh này. Lệnh "lưu trữ git".

Theo đó, sau khi cập nhật git trong GitHub, các kho lưu trữ hơi khác nhau bắt đầu được hiển thị trên các trang phát hành, không vượt qua quá trình xác minh bằng cách sử dụng tổng kiểm tra cũ. Vấn đề thể hiện ở nhiều hệ thống xây dựng khác nhau, hệ thống tích hợp liên tục và các công cụ để xây dựng gói từ mã nguồn. Ví dụ: tập hợp khoảng 5800 cổng FreeBSD, mã nguồn được tải xuống từ GitHub, đã bị hỏng.

Để đáp lại những phàn nàn ban đầu về trục trặc, GitHub ban đầu trích dẫn thực tế là tổng kiểm tra vĩnh viễn cho các kho lưu trữ không bao giờ được đảm bảo. Sau khi nhận thấy rằng cần phải thực hiện một lượng lớn công việc để cập nhật siêu dữ liệu trong các hệ sinh thái khác nhau nhằm khôi phục chức năng của các hệ thống xây dựng bị ảnh hưởng, đại diện của GitHub đã thay đổi quyết định, hủy bỏ thay đổi và quay lại phương pháp tạo kho lưu trữ cũ.

Các nhà phát triển Git vẫn chưa đưa ra quyết định và chỉ đang thảo luận về các hành động có thể thực hiện được. Các tùy chọn được xem xét bao gồm việc hoàn nguyên về sử dụng tiện ích gzip mặc định; thêm cờ “--stable” để duy trì khả năng tương thích với các kho lưu trữ cũ; liên kết việc triển khai tích hợp với một định dạng lưu trữ riêng biệt; sử dụng tiện ích gzip cho các lần xác nhận cũ và triển khai nội tuyến cho các lần xác nhận bắt đầu từ một ngày nhất định; đảm bảo độ ổn định định dạng chỉ dành cho các kho lưu trữ không nén.

Khó khăn trong việc đưa ra quyết định được giải thích là do việc quay lại cuộc gọi đến một tiện ích bên ngoài không giải quyết được hoàn toàn vấn đề về tính bất biến của tổng kiểm tra, vì một thay đổi trong chương trình gzip bên ngoài cũng có thể dẫn đến thay đổi định dạng lưu trữ. Hiện tại, một bộ bản vá đã được đề xuất để xem xét trả về hành vi cũ theo mặc định (gọi tiện ích gzip bên ngoài) và sử dụng triển khai tích hợp trong trường hợp không có tiện ích gzip trong hệ thống. Các bản vá cũng bổ sung vào tài liệu một đề cập rằng tính ổn định của đầu ra "git archive" không được đảm bảo và định dạng có thể thay đổi trong tương lai.

Nguồn: opennet.ru

Thêm một lời nhận xét