Nỗi khổ do GitHub Actions gây ra

 (feldera.com)
2 điểm bởi GN⁺ 2025-03-21 | 1 bình luận | Chia sẻ qua WhatsApp

  • Các vấn đề của GitHub Actions

    • Gần đây đã tốn rất nhiều thời gian để viết lại script CI bằng GitHub Actions. Trước đó từng dùng Earthly nhưng nó đã bị ngừng, nên lại quay về GitHub Actions.
    • CI rất phức tạp, bao gồm hàng đợi hợp nhất, nhiều runner, build Rust, image Docker, kiểm thử tích hợp, v.v. Mỗi lần hợp nhất PR đều tiêu tốn rất nhiều thời gian CI.
    • Theo thực hành phần mềm tốt, mọi bài kiểm thử phải vượt qua, những lỗi nhỏ phải được tự động sửa, và artifact đã kiểm thử phải giống hệt bản phát hành. GitHub Actions có thể làm được điều này nhưng cấu hình lại phức tạp và thiếu nhất quán.

  • Kiểm tra trạng thái và hàng đợi hợp nhất

    • Hàng đợi hợp nhất của GitHub sẽ rebase PR lên nhánh chính rồi chạy CI. Tuy nhiên, CI phải chạy cả trước và sau khi đưa vào hàng đợi, và việc cấu hình điều này rất khó.
    • Cách giải quyết là đặt cùng một tên job ở cả hai giai đoạn. Nhờ đó, cả hai giai đoạn đều phải vượt qua.

  • Vấn đề bảo mật

    • Gần đây có một GitHub Action phổ biến đã bị xâm phạm. Biện pháp đối phó được khuyến nghị là cố định dependency bằng hash, nhưng hầu hết người dùng không làm vậy.
    • Mô hình bảo mật của GitHub rất phức tạp và khó hiểu. Có thể thiết lập quyền mặc định cho GITHUB_TOKEN, nhưng việc loại bỏ quyền không hề rõ ràng.
    • Quyền của workflow không phụ thuộc vào chính action đó, và việc nâng quyền trong mã là điều khá kỳ lạ.

  • Sự kết hợp giữa Docker và GitHub Actions

    • Có thể chạy công việc bên trong container trong GitHub Actions, nhưng phát sinh các vấn đề như quyền truy cập tệp và việc thay đổi vị trí thư mục $HOME.
    • Trường container có nhiều hạn chế, nên không thể ghi đè entrypoint hoặc chỉ chạy một số bước nhất định bên trong container.

  • Phát triển workflow bằng YAML

    • Viết logic bằng YAML có thể trở nên phức tạp và dễ mắc lỗi. Đã dùng IDE RustRover để thực hiện một số kiểm tra, nhưng cần khả năng kiểm tra tĩnh tốt hơn.
    • Rất khó kiểm thử cục bộ, nên phải tạo một repo tương tự rồi commit và push lặp đi lặp lại cho đến khi CI hoạt động.
    • Giữ workflow nhỏ gọn và đẩy artifact để có thể tái sử dụng trong workflow khác. Tuy nhiên, khi tải artifact xuống thì cần token.

  • Kết luận

    • Thời gian hợp nhất đã giảm đáng kể với script CI mới, nhưng quá trình cấu hình rất phức tạp và khó debug. Cần có sự đổi mới.

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-03-21
Ý kiến trên Hacker News

  • Có ý kiến cho rằng GitLab tốt hơn, nhưng GitLab cũng có vấn đề theo cách khác

    • Sau khi dùng nhiều công cụ CI, người ta nhận ra điều quan trọng là viết càng nhiều logic CI càng tốt vào chính mã nguồn của mình
    • Cần đầu tư để có thể chạy pipeline cục bộ trên máy của lập trình viên
    • Nên tránh dùng YAML जित mức có thể
    • Không nên phụ thuộc vào các công cụ mới được tài trợ bởi vốn VC
    • Nên dùng runner tự quản càng nhiều càng tốt và vận hành on-premise

  • Thật thú vị khi GitHub Actions và DevOps bị chỉ trích rộng rãi

    • Việc cấu hình và kiểm thử có thể phiền phức, nhưng khi đã chạy ổn thì gần như không phải đụng vào nữa
    • Ngoài việc cập nhật phiên bản Node, trong 4 năm hầu như không sửa workflow
    • Cá nhân thấy khá hài lòng

  • Đã dùng GitLab rồi chuyển sang GitHub nhưng cảm thấy thất vọng

    • Cảm giác GitHub Actions thua kém GitLab rất nhiều
    • Nếu vận hành công ty thì sẽ chọn GitLab

  • Vòng phản hồi 30-60 giây là điều tệ nhất

    • Đã cố tái tạo môi trường GHA ở local nhưng không thể
    • Một lỗi nhỏ cũng khiến tốn rất nhiều thời gian

  • Không muốn CI tự động sửa mã

    • Các kiểm tra nhỏ nên được chạy bằng pre-commit hook

  • Thất vọng vì có vẻ GitHub Actions đã ngừng phát triển

    • Rất tiếc khi Earthly và Dagger ngừng phát triển
    • Sau khi đánh giá Depot.dev, thấy đây là một đội ngũ rất thông minh và đã giải quyết vấn đề rất tốt

  • GitHub Actions khiến container bị lạm dụng như script cài đặt

    • Trong workflow, rất nhiều thời gian bị tiêu tốn vào việc chạy trình cài đặt

  • Việc chọn đúng công cụ là rất quan trọng

    • GitHub Actions phù hợp với tác vụ đơn giản nhưng không phù hợp với tác vụ phức tạp

  • Vì các vấn đề bảo mật của GitHub Action, cần cố định dependency bằng hash

    • Dùng hash sẽ an toàn hơn nhiều

  • GitHub Actions có rất nhiều vấn đề

    • Giới hạn cache 10GB, giới hạn đồng thời tùy theo loại runner, chi phí cao, v.v.
    • Depot.dev đang cố gắng làm GitHub Actions nhanh hơn và giải quyết các vấn đề đó
    • Tăng tốc build Docker image và tối ưu runner để công việc chạy rất nhanh
    • GitHub Actions rất phổ biến nhưng vẫn còn nhiều chỗ cần cải thiện