CI tối giản với Git hook và nq

 (mccd.space)
1 điểm bởi GN⁺ 7 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Đây là một cấu hình CI đơn giản tự động hóa kiểm thử, build và di chuyển tệp bằng cách thêm hook post-receive vào kho Git bare trên máy chủ cá nhân
  • So với CI hiện có với cấu hình YAML phức tạp, chạy chậm và khó tự host, trường hợp này không cần đến mức cô lập bản dựng hoàn toàn hay quản lý bí mật
  • Nếu chạy tác vụ trực tiếp trong hook thì khi thất bại, push có thể bị từ chối hoặc bị chậm hoàn tất, nên dùng hàng đợi tác vụ tối giản nq để xử lý nền
  • Hook chỉ gọi nq, còn log được kiểm tra bằng ssh server nqtail -a, giúp vận hành nhanh và đơn giản
  • Khi cần, có thể cô lập build bằng landdown·Podman, quản lý bí mật bằng sops, hoặc mở rộng cách phát triển bằng bản vá Git qua email, git-shell, git http-backend

Cấu hình post-receive hook và nq

  • Trên máy chủ cá nhân, tạo kho bằng ssh server git init --bare repo rồi sao chép bằng git clone server:repo
  • Đặt một post-receive hook dưới dạng script shell trong thư mục hooks của kho bare để khởi chạy CI mỗi khi push
  • Nếu chạy tác vụ trực tiếp trong hook, sẽ phát sinh hai vấn đề
    • Nếu script thất bại, push sẽ bị từ chối
    • Nếu script chạy chậm, việc hoàn tất push cũng sẽ bị trì hoãn theo
  • Trong hook, gọi hàng đợi tác vụ tối giản nq để thêm tác vụ vào hàng đợi nền
    • Có thể xem log bằng ssh server nqtail -a
    • Quy trình thiết lập có thể xem trong hướng dẫn ngắn

Cô lập và mở rộng phương thức phát triển

  • Nếu muốn chạy build trong sandbox, có thể dùng landdown
  • Có thể dùng Podman để cô lập build khỏi môi trường host hoặc dùng sops để quản lý bí mật
  • Với kiểu phát triển bazaar, cấu hình nhận bản vá Git qua email là phù hợp
  • Với kiểu phát triển cathedral, có thể cấu hình bằng git-shell hoặc git http-backend

Bài viết liên quan

1 bình luận

 
GN⁺ 7 giờ trước
Ý kiến trên Lobste.rs

  • CI có ít nhất hai vấn đề
    Vấn đề dễ là chạy make test khi mã thay đổi, còn vấn đề khó là chạy make test trên cả Linux, Windows và Mac

    • Linux thì dễ, Windows thì khó, nhưng macOS thì ở mức đau khổ
    • Phần khó của CI, theo tôi, là bộ máy thực thi tác vụ còn phải hỗ trợ gỡ lỗi khi thất bại
      Tôi luôn không hài lòng vì trải nghiệm lập trình viên và tính năng gỡ lỗi của các bộ máy hiện có thường bị xem nhẹ, nên đang tự xây một hệ thống CI tại https://ci.pico.sh . Tôi cũng ghét DSL, còn YAML nối tầng thì có cảm giác như từ từ hút cạn sinh lực
    • Cách này giải quyết được bài toán dễ, và có thể mở rộng để hỗ trợ họ BSD bằng QEMU, cũng như nhiều bản phân phối bằng Docker, nhưng vượt quá mức đó thì có vẻ cần một công cụ hoàn chỉnh hơn

  • Tôi từng xây thứ này trên gitolite và chuyển sang Temporal để điều khiển quy trình build mà không bị giới hạn
    Có thể từ chối push khi thực thi thất bại, nhưng thường thì tôi để hook cho qua rồi xử lý lỗi riêng; cấu hình cũng đơn giản và khá thú vị

    • Tôi đặc biệt thích công cụ kiểm soát truy cập của gitolite, và cách có thể push vào một kho chưa tồn tại để tạo kho mới cũng rất tuyệt

  • Một CI tối giản khác cũng xoay quanh việc chạy shell script là laminar CI, và nó còn có giao diện web

  • Từ lâu trong một môi trường doanh nghiệp chỉ dùng Windows, chúng tôi từng đặt một chiếc Mac mini làm máy chủ CI cục bộ cho cả nhóm để build ứng dụng iOS; đó cũng là một trong những cách dùng Git mà tôi thử từ sớm

  • Tôi tìm thấy nó tại https://mccd.space/git/ , có vẻ đang dùng một bản fork của stagit
    Cho tới vài tháng trước tôi còn vận hành Forgejo và Woodpecker, nhưng hầu hết tính năng đều không cần thiết nên đã gỡ hết và đang tìm một cấu hình nhẹ hơn tương tự như thế này. Việc tiếp theo của tôi cũng là CI, nên bài này đến rất đúng lúc; tôi cũng đang cân nhắc có nên mirror một thư viện nhỏ sắp công bố lên SourceHut hay không

    • Tôi đã fork stagit để thêm email liên hệ và thanh điều hướng, thêm ID để chỉnh CSS, đồng thời loại bỏ các thông tin không cần thiết
      Kho được công khai chỉ đọc trên web bằng git-daemon, và tôi đã ghi lại toàn bộ cách thiết lập tại đây

  • Đây là lần đầu tôi biết tới nq qua bài này, nhưng có lẽ tôi sẽ dùng systemd-run
    Tôi dùng Nix cho gần như mọi runner, nên nếu xuất kết quả nix flake check thành metric và log OTLP thì có lẽ có thể giải quyết yêu cầu CI bằng chính hệ thống giám sát

  • Tôi thích kiểu tự host một nền tảng phát triển đơn giản như thế này
    Có thể dễ dàng cấu hình bubblewrap, một hệ thống container nhẹ và đơn giản, để dùng cho CI. Tuy vậy, nếu dùng nq thì có vẻ không thể từ chối push khi CI thất bại; tôi tò mò không biết xử lý việc đó thế nào

    • Cũng có một công cụ phụ trợ dùng Landlock để hạn chế script, và theo tôi cách dùng còn đơn giản hơn một chút
      Nếu cần cô lập hơn nữa thì có thể thêm Podman, Docker hoặc bubblewrap. Tôi không từ chối push khi CI thất bại cũng vì cùng lý do tôi không đặt pre-commit hook chạy test: đôi khi bạn vẫn cần commit hoặc push những thứ đang hỏng, và việc push có thể trở nên rất chậm. Nếu cần từ chối, chỉ việc chạy CI đồng bộ không qua nq rồi chặn push khi mã thoát khác 0
      Hoặc có thể chạy bằng nq cho các nhánh không phải main, còn riêng nhánh main thì chạy đồng bộ

  • Có vẻ liên kết landdown đang bị lỗi