Nhược điểm của nhân bản nông trên Travis và các dịch vụ CI khác?

Question

Hầu hết các dịch vụ CI cung cấp một cách để nông nhân bản một kho lưu trữ. Ví dụ, trên Travis:

git: 
    depth: 1 

hoặc trên AppVeyor:

clone_depth: 1 
or 
shallow_clone: true 

này có lợi ích rõ ràng về tốc độ, kể từ khi bạn không cần phải sao chép toàn bộ kho lưu trữ.

Có bất kỳ khó khăn nào trong việc nhân bản nông trên các dịch vụ CI không? Có bất kỳ tình huống nào mà một bản sao nông sẽ tạo ra một CI build không? Nếu không, tại sao không nông nhân bản thiết lập mặc định cho các dịch vụ CI?

Answer 1

Có hai lý do khiến việc này thường không xảy ra.

Thứ nhất, mã băm của bản sao nông sẽ khác với bất kỳ phiên bản nào bạn có thể có trong kho lưu trữ. Kết quả là, sẽ không thể theo dõi một bản dựng mà bạn đã thực hiện cho bất kỳ kết quả cụ thể nào.

Thứ hai, hầu hết các máy chủ Git đều có khả năng gửi gói 'everything.pack' được tối ưu hóa nếu bạn không có chi tiết. Nếu không, máy chủ sẽ phải cung cấp gói cam kết tùy chỉnh chỉ chứa bản sao nông của bạn để gửi cho bạn. Vì vậy, mặc dù có thể có nhiều dữ liệu được truyền qua dây, nó thực sự có thể dẫn đến nhiều công việc hơn trên máy chủ.

Cuối cùng, rất nhiều bản dựng CI sẽ thực hiện một số thao tác thẻ và tải nó lên kho lưu trữ, và bạn không thể gắn thẻ một bản sao nông (xem điểm 1).

Answer 2

Thêm vào AlBlue của câu trả lời:

vấn đề khác là các thiết lập độ sâu clone cũng được sử dụng cho git submodule.

Trong các dự án sử dụng mô-đun con git, Travis, v.v. sẽ sao chép repo submodule bắt đầu từ chính, rồi kiểm tra bản sửa đổi cụ thể.

Nếu cam kết mà chúng tôi trỏ đến trong mô-đun con không nằm trong n cam kết của bản gốc hiện tại (trong đó n là cài đặt độ sâu), thì sẽ không thể thanh toán.