Tạo cấu hình CI/CD

Dựng workflow GitHub Actions, pipeline GitLab CI, dependabot.yml và CODEOWNERS bằng biểu mẫu, đồng thời kiểm tra các tệp workflow bạn đang có — YAML cập nhật tức thì để sao chép hoặc tải xuống.

Các bước sử dụng

1. Mở GitHub Actions, chọn một Mẫu rồi bấm Nạp, hoặc bắt đầu từ workflow Node.js mặc định.
2. Trong Trình kích hoạt, bật hoặc tắt push và pull_request, giới hạn theo nhánh và đường dẫn, thêm các dòng schedule (mỗi biểu thức cron được giải thích bằng lời, theo giờ UTC) và input cho workflow_dispatch.
3. Trong Quyền & concurrency, giữ contents: read trừ khi job cần thêm quyền. Khi publish lên ghcr.io, chỉ riêng job đó được thêm packages: write. cancel-in-progress dừng các lần chạy cũ trên cùng nhánh.
4. Trong Các job, đặt Job id, runs-on và needs. Bật Build matrix, chọn Hệ điều hành và Phiên bản, rồi thêm các tổ hợp include / exclude, mỗi dòng một tổ hợp — thẻ sẽ hiển thị matrix chạy bao nhiêu job.
5. Chọn loại bước rồi bấm Thêm bước: checkout, cài đặt ngôn ngữ có cache, cài dependency, lint, test, build, tải lên artifact, đăng nhập và build-push Docker, triển khai qua SSH, chạy script hoặc action bất kỳ. Sắp xếp lại bằng Lên trên và Xuống dưới.
6. Theo dõi Kiểm tra kết quả — khung này kiểm tra workflow được tạo ngay khi bạn chỉnh sửa.
7. Mở GitLab CI để đặt stages, Image mặc định và các job với rules như Pipeline merge request và Nhánh mặc định, cùng cache, artifacts, services và needs.
8. Mở Dependabot, bấm Thêm hệ sinh thái cho từng trình quản lý gói, đặt lịch và gộp nhóm các bản cập nhật liên quan.
9. Mở CODEOWNERS, liệt kê mẫu đường dẫn và người sở hữu, rồi gõ một đường dẫn vào Thử mẫu đường dẫn để xem quy tắc nào thắng.
10. Dán một workflow có sẵn vào Kiểm tra workflow để rà soát, sau đó Sao chép hoặc Tải xuống bất kỳ kết quả nào.

Mẹo

• Ghim action của bên thứ ba theo SHA commit đầy đủ, hoặc ít nhất là tag phát hành. Bộ kiểm tra cảnh báo các action ghim theo nhánh như @main.
• Đừng bao giờ in secret trong bước run. Bước triển khai SSH ghi khoá riêng vào tệp thay vì in ra.
• GitHub chạy workflow theo lịch bằng giờ UTC và có thể trễ khi hệ thống bận — đừng trông cậy vào đúng từng phút.
• Trong CODEOWNERS, mẫu khớp cuối cùng sẽ thắng, nên đặt quy tắc rộng như * ở trên cùng và các thư mục cụ thể ở dưới.
• Trên GitLab, hãy bật Tránh chạy trùng pipeline nhánh và merge request để một lần push vào merge request đang mở không khởi chạy hai pipeline.

pull_request_target chạy với secret của repository và token có quyền ghi. Checkout head của pull request trong workflow như vậy cho phép bất kỳ ai mở pull request chạy mã cùng các secret đó — bộ kiểm tra báo đây là lỗi.

Câu hỏi thường gặp

Kết quả có dùng ngay cho production được không?

Đây là điểm khởi đầu gọn gàng theo các khuyến nghị hiện hành — quyền tối thiểu, cache, concurrency và ghim phiên bản chính — nhưng công cụ không biết lệnh build, secret hay môi trường của bạn. Hãy rà soát từng bước, thêm lệnh thật và chạy thử trên một nhánh trước khi dùng chính thức.

Workflow hay tệp CODEOWNERS của tôi có bị gửi lên máy chủ không?

Không. Việc tạo tệp, thử mẫu đường dẫn và kiểm tra đều chạy trong trình duyệt. Không nội dung nào bạn gõ hoặc dán rời khỏi thiết bị.

Kiểm tra workflow có thay được actionlint không?

Không. Công cụ kiểm tra cú pháp YAML, khoá cấp cao nhất lạ, job thiếu runs-on, needs bị thiếu hoặc vòng tròn, action ghim theo nhánh, pull_request_target checkout mã của pull request và secret bị in trong bước run. actionlint kiểm tra biểu thức, shell script và mọi input của action sâu hơn nhiều.

Công cụ thử mẫu chọn người sở hữu như thế nào?

Theo đúng quy tắc của GitHub: các mẫu được xét từ trên xuống và mẫu khớp cuối cùng sẽ thắng. /docs/ chỉ khớp thư mục docs ở gốc, **/logs khớp thư mục logs ở mọi độ sâu, còn apps/*/src khớp đúng một cấp dưới apps.