GitLab API theo dõi pipeline: báo cáo CI, phân trang và quyền

Chuyên viên Kỹ thuật ProxyVN 01-14-2026 Đang tính... phút đọc

GitLab API theo dõi pipeline là cách lấy lịch sử chạy CI của một project, gồm trạng thái, thời gian chạy, job và pipeline con, để dựng báo cáo mà không phải mở giao diện web từng lần. API này chỉ đọc khi anh em dùng đúng điểm cuối GET, không bấm chạy lại hay hủy job nào. ProxyVN đã gọi thật GitLab.com ngày 29/10/2026 trên một project công khai, không dùng token, để ghi lại mã trạng thái, header phân trang, header giới hạn request và chỗ quyền đọc dừng lại.

GitLab API theo dõi pipeline: mục tiêu dữ liệu, quyền và phạm vi truy cập

Trước khi viết code, anh em cần chốt project nào, nhánh nào và khoảng thời gian nào. Một project lớn có hàng nghìn pipeline, nên báo cáo không giới hạn phạm vi sẽ tốn request vô ích.

Báo cáo pipeline dùng để làm gì

Báo cáo pipeline trả lời các câu hỏi vận hành: tuần này nhánh main có bao nhiêu pipeline thất bại, pipeline trung bình chạy bao lâu, stage nào chậm nhất, job nào hay phải chạy lại. Những con số này giúp nhóm quyết định tối ưu chỗ nào trong file cấu hình CI.

Dữ liệu nằm sẵn trong GitLab. Giao diện web hiển thị từng pipeline, nhưng không xuất được bảng tổng hợp theo ý mình. API cho phép lấy dữ liệu thô rồi tự tính.

Project công khai và project riêng tư

Lab dùng project gitlab-org/gitlab-runner trên GitLab.com, id 250833, visibility public. Với project công khai cho phép xem CI, các điểm cuối đọc pipeline trả 200 mà không cần token. Lab gọi danh sách pipeline, chi tiết pipeline, danh sách job và báo cáo test đều không có header xác thực.

Project riêng tư thì khác. Không token, API trả 404 Project Not Found thay vì 403, để không lộ việc project có tồn tại hay không. Lab gọi project id 999999999999, nhận đúng thông báo 404 đó.

Với project của công ty, anh em cần token có quyền đọc. Bài này không dùng token thật. Phần có token được dựng bằng cấu trúc tài liệu và server giả lập cục bộ, ghi rõ ở từng chỗ.

Quyền đọc dừng ở đâu

Lab gặp một ca thú vị. Một pipeline của gitlab-runner có job loại bridge kích hoạt pipeline ở project khác, id 24519238. API trả thông tin bridge kèm id pipeline con, nhưng khi gọi pipeline con đó, GitLab trả 403 Forbidden.

Nghĩa là quyền đọc pipeline cha không kéo theo quyền đọc pipeline con ở project khác. Báo cáo phải ghi rõ những pipeline con không đọc được, thay vì coi như không tồn tại.

Thấy được id của một pipeline không có nghĩa là được quyền đọc pipeline đó.

Không kích hoạt job

Bài này chỉ dùng GET. Các điểm cuối POST như tạo pipeline, chạy lại hay hủy job có tác dụng thật lên hệ thống CI và tốn phút chạy. Lab thử POST tạo pipeline mà không token, GitLab trả 401 Unauthorized. Không thử với token.

Khi tạo token cho báo cáo, chọn phạm vi read_api thay vì api. Phạm vi read_api chỉ cho đọc, nên script lỗi cũng không thể chạy lại job hay xóa pipeline. Trang xác thực REST API của GitLab mô tả các loại token và phạm vi.

Khác bài crawl GitHub

Bài crawl GitHub bằng Python đọc metadata repository như sao, fork và ngôn ngữ. Bài này đọc lịch sử chạy CI, gồm pipeline và job, không đọc mã nguồn hay issue. Đối tượng dữ liệu, điểm cuối và cách phân trang đều khác.

Bài cũng không nói về cài GitLab Runner hay cấu hình proxy cho runner. Đó là phía chạy job. Bài này đứng ở phía đọc kết quả.

Đầu ra của bài này

Bài hướng tới một báo cáo pipeline theo project ID gồm id, trạng thái, nguồn kích hoạt, thời gian tạo, duration, queued_duration và số job theo trạng thái. Báo cáo có phân trang, có chuẩn hóa thời gian và không chứa trường user để tránh thu thông tin cá nhân không cần thiết.

GitLab API theo dõi pipeline: thu lịch sử CI, phân biệt pipeline/job và parent/child

Pipeline, job và bridge

Pipeline, job và bridge

Phần này giải thích ba tầng dữ liệu: pipeline, job và bridge. Nhầm giữa ba tầng là nguồn chính của báo cáo sai.

Danh sách pipeline trả gì

Lab gọi danh sách pipeline của nhánh main, mỗi trang 20 dòng. Kết quả là mã 200 trong 1,708 giây và 20 pipeline. Mỗi pipeline trong danh sách có 11 trường: id, iid, project_id, sha, ref, status, source, created_at, updated_at, web_url và name.

import requests
G = "https://gitlab.com/api/v4"; PID = 250833
r = requests.get(f"{G}/projects/{PID}/pipelines", params={"per_page": 20, "ref": "main"}, timeout=30)
print(r.status_code, len(r.json()), r.headers.get("x-total"))

Trong 20 pipeline đầu, 17 thành công, 2 thất bại, 1 đang chạy. Về nguồn kích hoạt, 19 pipeline đến từ push, 1 đến từ lịch chạy định kỳ.

Danh sách không có duration

Danh sách pipeline không có trường duration. Muốn biết pipeline chạy bao lâu, phải gọi chi tiết từng pipeline. Chi tiết có 23 trường, thêm before_sha, tag, yaml_errors, user, started_at, finished_at, committed_at, duration, queued_duration, coverage, detailed_status và archived.

Điều này ảnh hưởng số request. Báo cáo 100 pipeline cần 1 tới 5 request danh sách và 100 request chi tiết. Với giới hạn request của người dùng chưa xác thực, đây là chỗ cần tính trước.

id và iid khác nhau

Trường id là số duy nhất trên toàn GitLab.com, ví dụ 3004121506. Trường iid là số thứ tự trong project, ví dụ 54289. Đường dẫn API dùng id, còn giao diện web hay hiển thị số theo project.

Báo cáo nên lưu cả hai. Dùng id làm khóa để gọi API và ghép bảng. Dùng iid khi trình bày cho người trong nhóm, vì họ quen số đó hơn.

Job thuộc pipeline

Mỗi pipeline có nhiều job. Lab gọi job của pipeline đang chạy 3004121506, nhận 94 job thuộc 10 stage. Lúc gọi, 41 job thành công, 34 đang chạy, 16 mới tạo, 3 chờ bấm tay.

Job có các trường id, name, stage, status, duration, queued_duration, allow_failure và retried. Job có allow_failure là true khi thất bại sẽ không làm pipeline thất bại. Báo cáo tính tỷ lệ lỗi nên tách hai loại job này.

Bridge và pipeline con

Pipeline con trả 403

Pipeline con trả 403

Bridge là loại job đặc biệt, không chạy lệnh mà kích hoạt pipeline khác. Điểm cuối jobs không trả bridge, phải gọi riêng điểm cuối bridges. Pipeline 3004121506 có 3 bridge ở stage postrelease.

Một bridge đã chạy và trỏ tới pipeline con ở project 24519238. Hai bridge còn lại ở trạng thái created, chưa có pipeline con. Khi một pipeline cha thành công nhưng pipeline con thất bại, chỉ đọc pipeline cha sẽ cho bức tranh sai.

Nguồn parent_pipeline

Pipeline con trong cùng project có source là parent_pipeline. Lab lọc danh sách pipeline của gitlab-runner theo source=parent_pipeline, nhận 0 kết quả. Project này kích hoạt pipeline ở project khác chứ không tạo pipeline con trong cùng project.

Với project dùng pipeline con nội bộ, nên tách hai loại trong báo cáo. Đếm cả pipeline cha lẫn pipeline con vào cùng một con số sẽ làm số pipeline gấp đôi thực tế.

Đếm job theo stage

Khi đã có danh sách job, gom theo stage cho biết phần nào của CI tốn thời gian nhất. Pipeline 3004121506 có 10 stage, từ rebase, build, test tới release và postrelease. Mỗi stage có số job khác nhau và thời gian khác nhau.

Báo cáo stage nên tính tổng duration của job trong stage, không phải số job. Một stage có 2 job chạy 20 phút đáng tối ưu hơn một stage có 30 job chạy mỗi job 10 giây. Job có allow_failure là true nên tách thành cột riêng để không làm lệch tỷ lệ lỗi.

Lab chưa tính tổng thời gian theo stage cho pipeline này vì lúc gọi còn 34 job đang chạy. Con số chỉ có ý nghĩa sau khi pipeline kết thúc.

Chuẩn bị truy vấn, project ID, token và phiên bản cho GitLab API theo dõi pipeline

Phần này đi qua cách lấy project ID, các tham số lọc, cách gửi token và phiên bản API.

Lấy project ID từ đường dẫn

API chấp nhận id số hoặc đường dẫn đã mã hóa URL. Lab gọi /projects/gitlab-org%2Fgitlab-runner, dấu gạch chéo mã hóa thành %2F, và nhận id 250833. Sau đó mọi truy vấn dùng id số để URL gọn và không phụ thuộc tên project.

Tên project có thể đổi, id thì không. Lưu id trong cấu hình báo cáo giúp script chạy tiếp khi nhóm đổi tên hoặc chuyển project sang nhóm khác.

Tham số lọc

Trang Pipelines API của GitLab liệt kê các tham số lọc như ref, status, source, updated_after và updated_before. Lab lọc pipeline thất bại cập nhật sau ngày 1/10/2026, nhận 5 kết quả với per_page 5.

Lọc theo updated_after phù hợp cho báo cáo định kỳ. Mỗi lần chạy, chỉ lấy pipeline cập nhật sau lần chạy trước. Cách này giảm số request so với tải lại toàn bộ lịch sử.

Giá trị lọc sai trả 400

Lab gửi status=khong_hop_le. GitLab trả 400 với thân báo status không có giá trị hợp lệ. Khác một số API khác, GitLab báo lỗi tham số rõ ràng bằng mã HTTP.

Các giá trị status hợp lệ gồm created, waiting_for_resource, preparing, pending, running, success, failed, canceled, skipped, manual và scheduled. Báo cáo nên dùng danh sách này để kiểm tra dữ liệu đọc về.

Gửi token

Token gửi qua header PRIVATE-TOKEN hoặc Authorization: Bearer. Lab gửi một chuỗi giả có dạng token cá nhân, GitLab trả 401 Unauthorized. Điều đáng chú ý là header giới hạn request vẫn ghi tên throttle_unauthenticated_api, tức token sai bị coi như không có token.

import os
H = {"PRIVATE-TOKEN": os.environ["GITLAB_TOKEN"]}
r = requests.get(f"{G}/projects/{PID}/pipelines", headers=H, params={"per_page": 100}, timeout=30)

Không ghi token vào file mã. Đọc từ biến môi trường hoặc kho bí mật của hệ thống CI. Đoạn mã trên chưa chạy với token thật.

Header giới hạn request

Mọi phản hồi của GitLab.com trong lab có nhóm header RateLimit. Request không xác thực có ratelimit-limit là 500, ratelimit-name là throttle_unauthenticated_api, kèm ratelimit-observed, ratelimit-remaining và ratelimit-reset.

Request thứ 18 trong lab ghi ratelimit-observed 18 và ratelimit-remaining 482. Script nên đọc ratelimit-remaining và tự chậm lại khi gần về 0. Trang giới hạn của GitLab.com mô tả các mức giới hạn theo loại request.

Phiên bản API và GitLab tự quản

Đường dẫn dùng /api/v4. Với GitLab tự quản, thay gitlab.com bằng tên máy chủ của công ty. Phiên bản GitLab tự quản cũ có thể thiếu một số trường, ví dụ queued_duration hay name. Kiểm tra trường có tồn tại trước khi đọc.

Giới hạn request trên GitLab tự quản do quản trị viên cấu hình, có thể khác GitLab.com. Đọc header RateLimit của chính máy chủ đó thay vì giả định con số 500.

Thu dữ liệu GitLab API theo dõi pipeline có phân trang và trạng thái job

Phần này đưa vòng lặp phân trang đã chạy thật, ca lệch trang khi có pipeline mới, và cách retry khi bị giới hạn.

Header phân trang

Header phân trang

Danh sách pipeline trả các header x-page, x-per-page, x-next-page, x-prev-page, x-total, x-total-pages và Link. Với nhánh main, x-total là 3602 và x-total-pages là 181 khi mỗi trang 20 dòng.

Header Link chứa URL đầy đủ của trang sau, trang đầu và trang cuối. Đi theo rel="next" trong Link là cách an toàn, vì URL đã kèm đủ tham số lọc và sắp xếp.

Vòng lặp phân trang

Lab đi qua ba trang đầu, mỗi trang 20 dòng. Mỗi trang trả 20 pipeline, thời gian 0,516 giây, 0,536 giây và 0,483 giây. Trong 60 id thu được, không có id trùng.

url = f"{G}/projects/{PID}/pipelines"; params = {"per_page": 100, "ref": "main"}
while url:
    r = requests.get(url, params=params, timeout=30); r.raise_for_status()
    rows += r.json()
    url = r.links.get("next", {}).get("url"); params = None

Thư viện requests tự tách header Link thành r.links. Khi không còn trang sau, r.links không có khóa next và vòng lặp dừng.

per_page tối đa

Lab gửi per_page=500. GitLab không báo lỗi mà trả 100 dòng, tức giới hạn trên là 100. Script nên đặt per_page 100 để giảm số request, nhưng không được coi số dòng trả về bằng giá trị mình gửi.

Với 3602 pipeline và per_page 100, cần 37 request danh sách. Thêm 3602 request chi tiết nếu cần duration cho mọi pipeline. Con số này vượt xa 500 request mỗi phút của người dùng chưa xác thực.

Lệch trang khi có pipeline mới

Phân trang theo offset có một nhược điểm. Nếu có pipeline mới được tạo giữa lúc đọc trang 1 và trang 2, mọi pipeline bị đẩy xuống. Pipeline cuối trang 1 sẽ xuất hiện lại ở đầu trang 2.

Lab mô phỏng bằng danh sách 100 phần tử: đọc trang 1, chèn 2 phần tử mới lên đầu, rồi đọc trang 2. Hai id 91 và 92 xuất hiện ở cả hai trang. Cách xử lý là loại trùng theo id sau khi gộp.

Lab thử thêm pagination=keyset cho điểm cuối pipelines. GitLab vẫn trả 200 nhưng header Link vẫn dùng page=2, tức điểm cuối này không dùng keyset trong lần thử. Trang REST API của GitLab liệt kê những điểm cuối hỗ trợ keyset.

Retry khi bị giới hạn

Khi vượt giới hạn, GitLab trả 429. Lab không chạm giới hạn thật trên GitLab.com, nên dựng server giả lập ở cổng 9710 trả 429 kèm Retry-After 1 cho hai request đầu, request thứ ba trả 200.

def get_retry(url, tries=5):
    for i in range(tries):
        r = requests.get(url, timeout=10)
        if r.status_code != 429: return r
        time.sleep(float(r.headers.get("Retry-After", "5")))
    r.raise_for_status()

Kết quả: hàm thử lại 2 lần, server nhận 3 request, tổng thời gian 2,04 giây, request cuối trả 200. Đây là kiểm tra logic retry, không phải đo hành vi của GitLab.com.

Job chạy lại

Tham số include_retried quyết định có trả cả job đã bị chạy lại hay không. Lab gọi job của một pipeline thành công với và không có tham số này, cả hai đều trả 7 job. Pipeline đó không có job nào bị chạy lại.

Với pipeline có job chạy lại, mặc định chỉ trả lần chạy cuối. Báo cáo đếm số lần chạy lại cần bật include_retried=true rồi đếm job trùng tên trong cùng pipeline.

Đối soát ID, kiểu dữ liệu, giá trị thiếu và xuất xứ trong GitLab API theo dõi pipeline

Thu dữ liệu xong, phần này kiểm tra thời gian, trạng thái và các trường có thể rỗng.

duration so với khoảng thời gian thật

Lab lấy chi tiết 5 pipeline thành công gần nhất. Pipeline 3003754695 có duration 165 giây, queued_duration 3 giây, còn finished_at trừ started_at là 169 giây. Pipeline 3003289136 có duration 12.265 giây, tức hơn 3 giờ, khoảng thời gian thật là 12.274 giây.

Ở cả 5 pipeline, duration nhỏ hơn khoảng thời gian thật vài giây. Trường duration là thời gian chạy theo cách GitLab tính, không phải hiệu hai mốc thời gian. Báo cáo nên ghi rõ dùng trường nào và không trộn hai cách tính.

Giá trị null có ý nghĩa

Pipeline đang chạy có duration null và finished_at null. Job mới tạo có duration null và queued_duration null. Đây không phải lỗi dữ liệu mà là pipeline hay job chưa xong.

Báo cáo thời gian trung bình phải loại pipeline chưa xong. Nếu điền null thành 0, thời gian trung bình sẽ giảm sai. Lọc theo status thuộc nhóm đã kết thúc như success, failed hay canceled trước khi tính.

Chỉ tính thời gian trung bình trên pipeline đã kết thúc, giữ null cho pipeline còn chạy.

Thời gian theo UTC

Các trường thời gian có dạng 2026-10-29T13:41:43.152Z, chữ Z nghĩa là UTC. Khi nhóm ở Việt Nam xem báo cáo theo ngày, phải đổi sang múi giờ UTC+7 trước khi gom theo ngày. Một pipeline tạo lúc 22 giờ UTC thuộc ngày hôm sau theo giờ Việt Nam.

Lưu nguyên giá trị UTC trong file gốc, chỉ đổi múi giờ ở bước trình bày. Cách này giúp ghép với dữ liệu từ hệ thống khác mà không lệch ngày.

Không lưu trường user

Chi tiết pipeline và job có trường user chứa tên đăng nhập và tên hiển thị của người kích hoạt. Báo cáo vận hành thường không cần thông tin này. Lab xác nhận job có trường user và bỏ trường đó khỏi file kết quả.

Nếu cần thống kê theo người, hỏi ý kiến nhóm trước và chỉ lưu những gì cần. Thu thông tin người dùng không cần thiết làm file báo cáo trở thành dữ liệu cá nhân phải bảo vệ.

Báo cáo test đi kèm

Điểm cuối test_report_summary trả tổng hợp kết quả test của pipeline. Lab gọi cho pipeline 3004121506, nhận tổng 24.643 test, 24.414 thành công, 4 thất bại, 225 bỏ qua, tổng thời gian khoảng 2671 giây.

Dữ liệu test giúp báo cáo trả lời câu hỏi pipeline thất bại do test hay do bước build. Lab gọi lúc pipeline còn chạy, nên con số có thể khác khi pipeline kết thúc.

Xuất xứ từng dòng

Mỗi dòng báo cáo nên giữ project_id, id pipeline, web_url, thời điểm đọc và x-request-id của phản hồi. Header x-request-id do GitLab gán, hữu ích khi cần báo lỗi với quản trị viên.

Lưu JSON gốc của từng trang bên cạnh CSV tổng hợp. Khi số liệu trong báo cáo bị hỏi lại, mở JSON gốc nhanh hơn gọi lại API.

Lưu kết quả, giới hạn request và khi nào GitLab API theo dõi pipeline thực sự cần proxy

Phần cuối nói về lưu trữ, nhịp gọi và vai trò thật của proxy trong bài toán này.

Lưu theo lần chạy

Mỗi lần chạy báo cáo lưu một thư mục theo ngày, gồm JSON gốc từng trang, CSV pipeline, CSV job và file ghi chú các pipeline con bị 403. Lần chạy sau chỉ lấy pipeline có updated_at mới hơn lần trước.

Pipeline đang chạy sẽ đổi trạng thái. Lần chạy sau phải cập nhật lại những dòng có status chưa kết thúc, thay vì chỉ nối thêm dòng mới.

Tính số request trước khi chạy

Với giới hạn 500 request mỗi phút của request không xác thực, báo cáo 100 pipeline kèm chi tiết và job cần khoảng 200 request, chạy được trong một phút. Báo cáo cả nghìn pipeline cần chia nhiều phút hoặc dùng token.

Request có token thuộc một nhóm giới hạn khác. Lab chưa thử với token nên không đưa con số. Đọc header ratelimit-name và ratelimit-limit sau request đầu tiên để biết mình đang ở nhóm nào.

Thử qua proxy lab

Lab dựng proxy HTTP cục bộ có xác thực ở cổng 9702 rồi gọi danh sách pipeline qua proxy. Kết quả là mã 200, 5 pipeline, 0,969 giây. Header x-total vẫn là 3602, ratelimit-name vẫn là throttle_unauthenticated_api.

px = {"https": "http://user1:p%40ss%232026@127.0.0.1:9702"}
r = requests.get(f"{G}/projects/{PID}/pipelines", params={"per_page": 5}, proxies=px, timeout=30)

Ở lab, proxy chạy trên cùng máy nên IP đi ra Internet không đổi. Header ratelimit-observed tiếp tục tăng như các request trực tiếp trước đó. Lab chưa thử proxy có IP khác, nên không kết luận giới hạn tính theo IP hay theo tiêu chí khác.

Proxy không thay token

Proxy không cho quyền đọc project riêng tư, không biến 403 của pipeline con thành 200 và không tăng giới hạn của tài khoản. Muốn đọc nhiều hơn, cần token có quyền đúng, không phải nhiều IP hơn.

Bài GitHub API rate limit exceeded phân tích tình huống tương tự ở GitHub: cách xử lý bền là xác thực và giảm request, không phải xoay IP.

Khi nào proxy thực sự cần

Proxy cần khi máy chạy báo cáo nằm trong mạng chỉ cho ra Internet qua proxy, hoặc khi GitLab tự quản của công ty chỉ chấp nhận kết nối từ một dải IP cố định. Khi đó proxy là đường đi bắt buộc.

Với runner chạy trong mạng công ty, bài Jenkins proxy có cách cấu hình proxy cho công cụ CI tương tự. Mật khẩu proxy có ký tự đặc biệt phải mã hóa, bài định dạng proxy có cách chuyển.

Chọn loại proxy khi cần

Khi GitLab tự quản chỉ cho phép một IP cố định, proxy dân cư tĩnh hoặc proxy datacenter là lựa chọn phù hợp. ProxyVN có proxy dân cư tĩnh, proxy datacenter, proxy 4G và proxy xoay, hỗ trợ HTTP và SOCKS5. Anh em có thể mua proxy Việt Nam tại ProxyVN rồi khai IP đó vào danh sách cho phép của máy chủ GitLab.

Mẫu báo cáo tuần

Một báo cáo tuần gọn thường có bốn con số cho nhánh main: tổng pipeline, tỷ lệ thành công, thời gian chạy trung vị và năm job thất bại nhiều nhất. Dùng trung vị thay vì trung bình vì vài pipeline chạy hơn 3 giờ, như pipeline 3003289136 trong lab, sẽ kéo trung bình lên cao.

Mỗi con số nên kèm link web_url tới vài pipeline điển hình. Người đọc báo cáo bấm vào xem tận nơi thay vì phải tin con số. Phần pipeline con không đọc được ghi riêng một dòng, kèm số lượng.

Giới hạn suy luận của bài

Lab gọi GitLab.com thật ngày 29/10/2026 từ Windows 10 ở Việt Nam, Python 3.12.10 và requests 2.34.2, không token, trên project công khai gitlab-runner. Mọi phần có token chưa chạy. Ca 429 dùng server giả lập, không phải GitLab.com.

Số pipeline, số job và kết quả test là ảnh chụp tại thời điểm gọi, sẽ thay đổi. GitLab tự quản có thể khác GitLab.com về giới hạn và trường dữ liệu. Proxy trong lab là proxy cục bộ.

Checklist GitLab API theo dõi pipeline

Checklist báo cáo pipeline

Checklist báo cáo pipeline

Dùng token phạm vi read_api, không dùng phạm vi api.
Chỉ gọi GET, không gọi điểm cuối tạo, chạy lại hay hủy.
Đi theo header Link, per_page tối đa 100.
Loại trùng theo id sau khi gộp các trang.
Gọi chi tiết để có duration, gọi bridges để thấy pipeline con.
Ghi lại pipeline con trả 403 thay vì bỏ qua.
Giữ null cho pipeline chưa xong, đổi múi giờ khi trình bày.
Bỏ trường user khỏi báo cáo nếu không cần.

Câu hỏi thường gặp về GitLab API theo dõi pipeline

Không có token có đọc được pipeline không?

Được với project công khai cho phép xem CI. Lab đọc danh sách, chi tiết, job và báo cáo test của gitlab-runner mà không có token. Project riêng tư trả 404.

Vì sao danh sách pipeline không có thời gian chạy?

Danh sách chỉ có 11 trường cơ bản. Thời gian chạy nằm trong chi tiết pipeline, phải gọi thêm một request cho mỗi pipeline.

Bridge có nằm trong danh sách job không?

Không. Điểm cuối jobs không trả bridge. Phải gọi điểm cuối bridges của pipeline.

Vì sao pipeline con trả 403?

Pipeline con nằm ở project khác mà anh em không có quyền đọc. Quyền đọc pipeline cha không kéo theo quyền đọc project đích.

Dùng proxy có tăng giới hạn 500 request không?

Lab chưa thử proxy có IP khác nên không kết luận. Cách bền là dùng token và giảm số request bằng cách lọc theo updated_after.

Báo cáo có kích hoạt job nào không?

Không, nếu chỉ dùng GET và token phạm vi read_api. Bài proxy trong GitHub Actions có ví dụ chạy script đọc dữ liệu định kỳ trong CI.

GitLab API theo dõi pipeline và những điều cần nhớ

GitLab API theo dõi pipeline cho phép dựng báo cáo CI chỉ bằng request đọc, nhưng cần hiểu ba tầng pipeline, job và bridge. Lab ngày 29/10/2026 đọc 3602 pipeline của nhánh main qua header phân trang, thấy per_page bị chặn ở 100, pipeline con ở project khác trả 403, và request không token có giới hạn 500. Dùng token read_api, giữ null cho pipeline chưa xong và bỏ trường user. Cần IP cố định cho máy chủ GitLab khi làm GitLab API theo dõi pipeline, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.