4 Mô hình GitHub Actions cho Monorepo ETL
Việc vận hành ba trang web từ một monorepo duy nhất sẽ nảy sinh nhiều vấn đề. Bạn sẽ phải đối mặt với ba tác vụ ETL riêng biệt, ba lần xây dựng lại nội dung (content rebuilds) và ba quy trình triển khai (deployment pipelines). Nếu không điều phối chúng, chúng sẽ xung đột với nhau.
Tôi đã dành sáu tuần để thử nghiệm các lịch trình nhằm ổn định thiết lập này. Dưới đây là bốn mô hình mà tôi sử dụng.
- Sử dụng Độ lệch Thời gian (Time Offsets) cho các Cron Job
Chạy tất cả các tác vụ ETL cùng một lúc sẽ gây ra lỗi. Các tác vụ sẽ tranh giành giới hạn tốc độ API (API rate limits). Khi HuggingFace hoặc GitHub trả về lỗi 429, tiến trình sẽ thất bại.
Tôi sử dụng độ lệch 30 phút để ngăn chặn điều này.
- Tác vụ một bắt đầu lúc 02:00
- Tác vụ hai bắt đầu lúc 02:30
- Tác vụ ba bắt đầu lúc 03:00
Ba mươi phút là đủ thời gian để hoàn tất một lượt lấy dữ liệu (pull) nặng trước khi tác vụ tiếp theo bắt đầu. Điều này giúp nhật ký (logs) của bạn sạch sẽ và ngăn chặn sự xung đột API.
- Sử dụng Cờ Bỏ qua (Skip Flags) để Ngăn chặn việc Xây dựng lại Không cần thiết
Mỗi tác vụ ETL đều kết thúc bằng một lần triển khai lên Vercel. Vấn đề phát sinh khi các commit bài viết cũng kích hoạt việc xây dựng lại. Nếu không có kế hoạch, mỗi lần cập nhật bài viết sẽ buộc cả ba trang web phải xây dựng lại. Điều này gây lãng phí thời gian build.
Tôi sử dụng thẻ [skip publish-articles] trong các commit message của ETL.
Tôi đã thêm một bước vào workflow của mình để kiểm tra thẻ này. Nếu thẻ tồn tại, workflow sẽ bỏ qua bước build và deploy. Điều này giúp tách biệt các pipeline ETL khỏi các pipeline bài viết.
- Sử dụng Bộ lọc Đường dẫn (Path Filters) để Nhắm mục tiêu vào các Trang cụ thể
Bạn sẽ không muốn việc cập nhật một trang web lại kích hoạt cả ba lần triển khai. Tôi cấu hình workflow của mỗi trang web để chỉ theo dõi thư mục riêng của nó và thư mục các gói dùng chung (shared packages).
Logic ví dụ:
- Trang web công cụ AI chỉ theo dõi
apps/ai-tools/ - Trang web OSS chỉ theo dõi
apps/oss-alternatives/
Nếu bạn thay đổi mã nguồn trong thư mục dùng chung, tất cả các trang web sẽ được xây dựng lại. Tôi chấp nhận sự đánh đổi này vì các thay đổi trong mã nguồn dùng chung rất hiếm khi xảy ra.
- Thêm Kích hoạt Thủ công (Manual Dispatch) để Kiểm soát
Cron xử lý các công việc định kỳ hàng ngày. Manual dispatch xử lý mọi thứ còn lại. Tôi sử dụng workflow_dispatch để có thể:
- Chạy lại một tác vụ ETL bị lỗi
- Ép buộc làm mới sau khi thêm dữ liệu
- Chạy thử (dry run) để kiểm tra dữ liệu mà không ghi vào cơ sở dữ liệu
Giao diện GitHub UI sẽ hiển thị một menu thả xuống cho các lựa chọn này. Điều này giúp ngăn chặn lỗi đánh máy và giúp việc gỡ lỗi (debugging) trở nên dễ dàng.
Tóm tắt
Những mô hình này không phức tạp. Chúng mang tính tường minh. Tôi giữ một tệp markdown đơn giản trong kho lưu trữ của mình để ghi chép lại các quy tắc này. Điều này đảm bảo tôi không làm hỏng hệ thống khi thêm các workflow mới.