Proxy trong GitHub Actions cấu hình runner và secret CI

Proxy trong GitHub Actions có hai bài toán khác nhau: giúp runner kết nối tới GitHub và đưa một bước kiểm thử qua endpoint được cấp. Trộn hai lớp này dễ làm pipeline lỗi hoặc lộ thông tin trong log. ProxyVN hướng dẫn anh em tách phạm vi cấu hình, quản lý secret và xây phép kiểm tra vùng có đầu vào, đầu ra cùng giới hạn rõ ràng.

Proxy trong GitHub Actions với hai luồng kết nối

Runner cần liên lạc với dịch vụ GitHub để nhận công việc, tải action và gửi trạng thái. Trong khi đó, mã chạy ở một step có thể gọi website hoặc API thử nghiệm của đội mình. Proxy cho luồng thứ nhất phải được chuẩn bị trước khi runner hoạt động trong mạng yêu cầu trung gian. Proxy cho luồng thứ hai có thể chỉ đặt trong step cần kiểm tra. Hai cấu hình có thể dùng cùng endpoint nhưng vẫn là hai trách nhiệm riêng.

Tài liệu proxy của runner GitHub nêu biến môi trường được đọc khi runner khởi động. Vì vậy, thêm https_proxy trong một step không sửa được việc runner đang không kết nối tới GitHub để nhận chính step đó. Với self-hosted runner, người vận hành cần thiết lập môi trường cho tiến trình hoặc dịch vụ runner rồi khởi động lại theo quy trình. Không chờ workflow bắt đầu mới giải quyết đường liên lạc nền.

Tách đường tải công cụ khỏi đường kiểm thử

Một pipeline có thể tải dependency theo mạng thông thường rồi chỉ gửi phép thử vùng qua proxy. Cách tách này giảm phạm vi tiếp xúc của secret và giúp chẩn đoán lỗi. Nếu toàn job dùng proxy, bước cài thư viện và bước kiểm tra website đều chịu ảnh hưởng khi endpoint gặp sự cố. Khi job thất bại, cần biết nó chưa cài xong công cụ hay đã chạy tới phép thử nghiệp vụ, thay vì gắn mọi lỗi cho vị trí IP ngoài.

Proxy của runner cũng không mặc nhiên cấu hình Docker daemon hoặc mọi container. Một image pull có thể do daemon thực hiện ngoài tiến trình step; ứng dụng trong container lại có môi trường riêng. Anh em nên đối chiếu các lớp proxy Docker khi pipeline dùng container. Bài hiện tại tập trung vào ranh giới runner, job và step để tránh lặp hướng dẫn cấu hình daemon đã có.

Không coi biến môi trường là tiêu chuẩn mà mọi thư viện đều đọc giống nhau. cURL, trình quản lý package, JVM và browser automation có thể có lựa chọn riêng. Nếu một bước bỏ qua proxy, đọc tài liệu của đúng client rồi thực hiện phép thử đối chứng. Việc một lệnh cURL đã đổi đường không đủ để đánh dấu toàn bộ bộ kiểm thử browser hoặc Maven của cùng job là đã dùng cùng cấu hình.

Chuẩn bị môi trường của self-hosted runner

Với self-hosted runner chạy dạng service, shell anh em đang mở và tài khoản chạy service có thể không cùng tập biến. Nếu thử cURL trong terminal đạt nhưng runner vẫn offline, kiểm tra nguồn cấu hình mà tiến trình thực sự đọc. Trên namespace thử, có thể dùng tệp .env ở thư mục ứng dụng runner theo tài liệu GitHub. Dùng host giả trong bản mẫu, rồi đưa giá trị được quản trị vào máy theo quy trình của tổ chức.

https_proxy=http://proxy.example.com:8080
http_proxy=http://proxy.example.com:8080

Tệp này dành cho tiến trình runner tự lưu trữ, không phải tệp để commit vào repository hoặc dùng để cấu hình một GitHub-hosted runner chưa khởi động. Khi đổi giá trị, ghi nhận cấu hình trước và khởi động lại runner theo lịch đã được quản lý. Chỉ sửa biến trong workflow không thay được môi trường đã dùng để runner nhận công việc. Nếu service không đọc được tệp, xử lý quyền và vị trí tệp thay vì thêm nhiều bản sao secret ở các thư mục khác.

Danh sách bypass cũng cần được xác định theo client. Tài liệu runner lưu ý giới hạn đối với IP và CIDR trong no_proxy; đừng mang cú pháp bypass của cURL sang runner rồi mặc định tương thích. Với hệ thống nội bộ dùng tên DNS, kiểm tra đúng hostname theo chính sách mạng. Một kết quả đạt cho target công khai không thay cho phép thử liên lạc tới GitHub Enterprise hoặc một dịch vụ nội bộ cần đi đường riêng.

Xác thực nguồn mạng của máy CI

Nếu endpoint dùng whitelist, địa chỉ cần cấp quyền là nguồn kết nối từ máy runner tới proxy. Nó có thể khác IP của laptop đang quản trị repository. Tài liệu GitHub-hosted runners cung cấp thông tin về môi trường và mạng; cần đối chiếu loại runner đang dùng trước khi xây một danh sách cấp quyền. Không lấy một IP quan sát ở một lần chạy rồi coi nó là thuộc tính cố định của mọi job sau đó.

Một hồ sơ thử nên ghi loại runner, image, kiến trúc và phiên bản cURL tại thời điểm chạy. Các dữ liệu này không cần chứa bí mật nhưng giúp giải thích vì sao cùng YAML có hành vi khác giữa hai môi trường. Khi đổi image, chạy lại ca nhỏ để xác nhận khả năng đọc biến, xác minh TLS và xử lý phản hồi. Phần kiểm tra này nên kết thúc trước khi mở matrix lớn hoặc thêm nhiều target cho các đội khác dùng chung.

Nếu chính sách mạng bắt buộc CA nội bộ, cấu hình trust store theo hướng dẫn của công cụ và quyền quản trị được cấp. Không dùng tùy chọn bỏ xác minh chứng chỉ chỉ để job tiếp tục, vì khi đó bằng chứng về kết nối đã thay đổi. Đồng thời phân biệt lỗi không tới được proxy, lỗi mở đường CONNECT và lỗi chứng chỉ của target; mỗi giai đoạn cần người phụ trách cùng dữ liệu chẩn đoán khác nhau.

Proxy trong GitHub Actions và secret theo môi trường

GitHub hỗ trợ secret ở cấp repository, environment và organization theo quyền cùng điều kiện áp dụng. Anh em nên chọn phạm vi phù hợp với người được phép chạy phép thử. Trong ví dụ, mỗi môi trường QA có secret CI_PROXY_URL và biến cấu hình target. Việc dùng environment cần được kiểm tra theo gói và chính sách repository; không mặc định mọi tài khoản đều có cùng chức năng bảo vệ hoặc duyệt triển khai.

Tên secret nên phản ánh vai trò thay vì chứa mật khẩu hoặc IP. CI_PROXY_URL cho biết nó phục vụ phép thử mạng, còn tên environment xác định vùng và quyền sử dụng. Không đặt toàn bộ inventory dưới một secret JSON lớn chỉ để giảm số thao tác tạo biến. Nếu tệp được tách hoặc biến đổi trong quá trình chạy, các phần bí mật có thể không còn trùng giá trị được runner tự che trong log.

Tạo secret bằng giao diện có tài liệu

Các bước tạo repository secret dưới đây dựa trên tài liệu GitHub. Với environment secret, thao tác nằm trong phần environment tương ứng và cần quyền khác. Anh em phải xác nhận quyền trước khi chọn phạm vi. Bài viết không yêu cầu đưa thông tin thật vào ví dụ công khai; những chuỗi host, tài khoản và endpoint được nêu trong phần giải thích chỉ là dữ liệu minh họa để đối chiếu cấu trúc.

• Mở repository trên GitHub rồi chọn Settings ở thanh điều hướng của repository.
• Trong phần Security của sidebar, chọn Secrets and variables rồi chọn Actions.
• Mở thẻ Secrets và chọn New repository secret.
• Điền tên ở Name, giá trị ở Secret rồi chọn Add secret.
• Kiểm tra workflow được phép dùng phạm vi secret đã chọn và thử bằng thông tin truy cập có thể thu hồi trước.

Một người có quyền sửa workflow có thể thay cách secret được sử dụng. Vì vậy, secret không chỉ là vấn đề che log mà còn là vấn đề ai được sửa và chạy mã nhận nó. Hạn quyền ghi repository, duyệt thay đổi workflow và tách tác vụ nhận đầu vào không tin cậy khỏi tác vụ có thông tin truy cập. Không cấp secret cho một job chỉ vì nó chạy cùng repository với mã đã được tin cậy.

Cấp secret đúng phạm vi

Proxy trong GitHub Actions với workflow kiểm tra vùng

Ví dụ tự viết dưới đây chạy thủ công, không checkout mã từ pull request và không dùng action bên thứ ba. Nó gọi cURL từ một step để kiểm tra endpoint QA được quản lý. Phản hồi mong đợi là JSON có country_code gồm hai chữ hoa. Đây là hợp đồng do ứng dụng thử của đội tự cung cấp, không phải trường mặc định của mọi website hay API kiểm tra IP ngoài Internet.

Tạo hai environment qa-vn và qa-us nếu chính sách repository cho phép. Trong mỗi environment, đặt secret CI_PROXY_URL và các biến CI_TARGET_URL, CI_ALLOWED_HOST. Endpoint target phải được đội mình kiểm soát hoặc được phép dùng. Ví dụ không khẳng định ProxyVN có mọi endpoint quốc gia trong ma trận; anh em cần cấp endpoint thực tế phù hợp hoặc đổi ma trận theo phạm vi dịch vụ đã xác nhận.

Lưu cấu hình thành .github/workflows/proxy-region.yml trong repository được phép quản lý. Cú pháp workflow GitHub Actions là nguồn đối chiếu cho matrix, environment, env và giới hạn thời gian. Các giá trị timeout trong ví dụ là lựa chọn minh họa để tránh chờ quá lâu, không phải SLA của runner hay dịch vụ proxy.

name: Proxy region check
on:
  workflow_dispatch:
permissions: {}
concurrency:
  group: proxy-region-check
  cancel-in-progress: false
jobs:
  region:
    runs-on: ubuntu-latest
    timeout-minutes: 5
    strategy:
      fail-fast: false
      max-parallel: 2
      matrix:
        include:
          - environment: qa-vn
            country: VN
          - environment: qa-us
            country: US
    environment: ${{ matrix.environment }}
    steps:
      - name: Check approved QA endpoint
        shell: bash
        env:
          https_proxy: ${{ secrets.CI_PROXY_URL }}
          http_proxy: ${{ secrets.CI_PROXY_URL }}
          HTTPS_PROXY: ${{ secrets.CI_PROXY_URL }}
          HTTP_PROXY: ${{ secrets.CI_PROXY_URL }}
          ALL_PROXY: ''
          all_proxy: ''
          no_proxy: ''
          NO_PROXY: ''
          TARGET_URL: ${{ vars.CI_TARGET_URL }}
          ALLOWED_HOST: ${{ vars.CI_ALLOWED_HOST }}
          EXPECTED_COUNTRY: ${{ matrix.country }}
        run: |
          python3 - <<'PY'
          import json, os, re, subprocess, tempfile
          from pathlib import Path
          from urllib.parse import urlsplit
          target = os.environ.get('TARGET_URL', '')
          allowed = os.environ.get('ALLOWED_HOST', '').lower()
          expected = os.environ.get('EXPECTED_COUNTRY', '')
          proxy = os.environ.get('https_proxy', '')
          if not proxy:
              raise SystemExit('CI proxy secret missing')
          try:
              parsed, upstream = urlsplit(target), urlsplit(proxy)
              valid_target = (parsed.scheme == 'https' and allowed and
                  parsed.hostname == allowed and parsed.username is None and
                  parsed.password is None and not parsed.fragment and
                  parsed.port in (None, 443))
              valid_proxy = (upstream.scheme in ('http', 'https') and
                  upstream.hostname and upstream.port != 0 and
                  upstream.path in ('', '/') and not upstream.query and
                  not upstream.fragment and not any(c.isspace() for c in proxy))
          except ValueError:
              raise SystemExit('QA configuration invalid')
          if not valid_target or not valid_proxy:
              raise SystemExit('QA configuration invalid')
          if not re.fullmatch('[A-Z]{2}', expected):
              raise SystemExit('QA expected country invalid')
          with tempfile.TemporaryDirectory() as folder:
              body = Path(folder) / 'response.json'
              args = ['curl', '-q', '--silent', '--show-error', '--fail',
                      '--connect-timeout', '5', '--max-time', '20',
                      '--max-filesize', '65536', '--proto', '=https',
                      '--write-out', '%{http_code}', '--output', str(body), target]
              try:
                  result = subprocess.run(args, stdout=subprocess.PIPE,
                      stderr=subprocess.DEVNULL, text=True, timeout=25)
              except (OSError, subprocess.TimeoutExpired):
                  raise SystemExit('QA network probe failed')
              if result.returncode or result.stdout != '200':
                  raise SystemExit('QA network probe failed')
              try:
                  if body.stat().st_size > 65536:
                      raise ValueError('response too large')
                  payload = json.loads(body.read_text(encoding='utf-8'))
                  country = payload['country_code']
              except (OSError, ValueError, KeyError, TypeError):
                  raise SystemExit('QA response schema invalid')
              if (not isinstance(country, str) or
                  not re.fullmatch('[A-Z]{2}', country)):
                  raise SystemExit('QA country code invalid')
              if country != expected:
                  raise SystemExit('QA country assertion failed')
              print('QA country assertion passed:', country)
          PY

Script không in URL proxy, nội dung phản hồi hoặc exception chi tiết. Tệp phản hồi nằm trong thư mục tạm được dọn khi kết thúc khối. cURL dùng biến môi trường có secret trong phạm vi step; khi secret thiếu, script dừng trước khi tạo yêu cầu. Cách làm này giảm nguy cơ một cấu hình trống khiến phép thử chạy trực tiếp rồi bị hiểu nhầm là đã kiểm tra qua proxy.

Giữ kết quả ở mức đã quan sát

Một assertion country_code đạt chỉ chứng minh target trả về mã mong đợi trong hợp đồng của ứng dụng thử. Server phải xác định địa chỉ khách từ nguồn tin cậy, đặc biệt khi nằm sau CDN hoặc reverse proxy. Không lấy một header do client tự gửi làm bằng chứng vị trí. Cũng không dùng tên environment qa-vn làm kết quả đo; tên ma trận là kỳ vọng, còn phản hồi được kiểm tra là quan sát cần đối chiếu độc lập.

Phép thử chưa kiểm tra ngôn ngữ, múi giờ, geolocation API hoặc nội dung giá theo tài khoản. Các yếu tố đó có thể được quyết định từ cookie, cài đặt trình duyệt hoặc hồ sơ người dùng thay vì IP. Để kiểm tra sản phẩm thật, thêm assertion theo yêu cầu đã được đội sản phẩm xác định. Không mở rộng kết luận từ một mã quốc gia thành ứng dụng hiển thị đúng ở mọi tình huống người dùng tại vùng đó.

Proxy trong GitHub Actions với biến môi trường của client

Tài liệu cURL về biến proxy giải thích các tên biến theo scheme và NO_PROXY. Sự khác biệt chữ hoa chữ thường có thể ảnh hưởng cách client nhận cấu hình. Trong ví dụ, dùng http_proxy và https_proxy chữ thường, đồng thời đặt danh sách bypass rỗng cho phép thử đã được phê duyệt. Điều này không có nghĩa nên xóa no_proxy trên mọi máy hoặc mọi bước của pipeline, nhất là self-hosted runner trong mạng tổ chức.

Tiền tố https_proxy cho biết biến được dùng với URL HTTPS đích, không bắt buộc giá trị phải bắt đầu bằng https://. Một HTTP proxy hỗ trợ CONNECT có thể phục vụ yêu cầu tới website HTTPS. Nếu endpoint được cấp dùng HTTPS tới chính máy chủ proxy, cần client và bản dựng cURL hỗ trợ phù hợp. Chọn giá trị theo hợp đồng dịch vụ thực tế, tránh đổi scheme chỉ vì website đích có chứng chỉ TLS.

Kiểm tra URL có thông tin xác thực

Username hoặc password chứa ký tự dành riêng cần được biểu diễn đúng khi ghép vào URL. Không nối chuỗi bằng thao tác shell không có kiểm tra rồi ghi kết quả vào log để xem đã đúng chưa. Chuẩn bị giá trị secret theo định dạng client chấp nhận và thử bằng tài khoản có thể thu hồi. Khi cần hướng dẫn chuyển đổi, dùng định dạng proxy làm tài liệu tham chiếu thay vì đưa mật khẩu thật vào ảnh trao đổi.

Nếu một client không đọc biến môi trường, cấu hình trực tiếp bằng API của nó. Trình quản lý build Java có thể cần settings.xml hoặc gradle.properties; không suy ra cURL hoạt động nghĩa Maven cũng đi cùng đường. Anh em có thể đối chiếu cấu hình Maven và Gradle proxy cho lớp công cụ đó. Giữ mỗi phép kiểm tra gắn với đúng client giúp báo cáo CI phản ánh điều thực sự đã chạy.

Runner job và step

Proxy trong GitHub Actions và log không chứa bí mật

Tài liệu secure use của GitHub nhấn mạnh giá trị secret biến đổi có thể không được tự che như chuỗi gốc. Vì vậy, tránh bật shell tracing, in env, in command chứa credentials hoặc upload tệp cấu hình nguyên vẹn. Cơ chế masking là lớp hỗ trợ cho log, không phải lý do để cố tình xuất thông tin truy cập rồi tin rằng hệ thống sẽ nhận ra mọi cách biểu diễn.

Nếu tạo một giá trị nhạy cảm mới từ các secret thành phần, đăng ký giá trị mới theo cơ chế masking trước khi nó có thể xuất hiện. Tuy vậy, tốt hơn vẫn là không in nó. URL-encoding, Base64 hoặc chia nhỏ chuỗi có thể làm giá trị khác chuỗi được runner biết ban đầu. Khi kiểm tra, dùng dữ liệu giả chứa dấu hiệu dễ nhận biết rồi tìm cả các biến thể trong log và artifact của ca thử.

Trace browser cũng có thể chứa thông tin nhạy cảm

Trace, HAR, screenshot và báo cáo HTML có thể chứa URL, cookie, token hoặc nội dung phản hồi. Không coi artifact là an toàn hơn log chỉ vì nó nằm ở một tab khác trên GitHub. Quyết định thứ gì được lưu, thời gian giữ và ai được tải cần phù hợp dữ liệu QA. Với phép kiểm tra vùng đơn giản, chỉ lưu trạng thái cùng mã vùng đã chuẩn hóa có thể đủ, chưa cần giữ toàn bộ body và header.

Khi một lần thử thất bại, thông báo ngắn như network probe failed giúp tránh phát tán bí mật nhưng chưa đủ để tìm nguyên nhân sâu. Đội vận hành cần quy trình chẩn đoán riêng bằng tài khoản thử và môi trường hạn quyền. Không bật curl -v trên job đang dùng secret thật rồi chia sẻ log rộng chỉ để biết mã lỗi. Có thể ghi mã thoát, thời gian và giai đoạn lỗi mà không in URL truy cập.

Nếu thông tin bị lộ, cần thu hồi hoặc đổi thông tin truy cập và xử lý log theo chính sách repository. Xóa một dòng khỏi workflow không vô hiệu hóa mật khẩu đã bị sao chép. Sau đó xem lại phạm vi quyền và các nơi lưu artifact. Phép sửa cần giải quyết cả thông tin đã lộ lẫn nguyên nhân phát tán, thay vì chỉ chỉnh lệnh print để lần sau log trông sạch hơn.

Proxy trong GitHub Actions với mã không tin cậy

Một pull request có thể thay mã chạy trong pipeline. Nếu job có secret rồi checkout và thực thi mã chưa được duyệt, người sửa có thể thay cách sử dụng thông tin đó. Ví dụ bài viết dùng workflow_dispatch trên nội dung được quản lý để làm phạm vi dễ kiểm tra. Khi mở rộng sang sự kiện khác, đánh giá quyền, nguồn mã và context của sự kiện thay vì sao chép trigger vào workflow có secret rồi mặc định hành vi vẫn tương đương.

Tách kiểm tra đóng góp khỏi kiểm tra có endpoint riêng

Job kiểm tra cú pháp hoặc unit test cho đóng góp từ bên ngoài thường không cần thông tin proxy thương mại. Job kiểm thử vùng có thể chạy sau bước duyệt trên mã đã được xác nhận. Tách hai loại công việc giúp giảm phạm vi quyền và chi phí sử dụng endpoint. Nếu sử dụng self-hosted runner, còn cần xét khả năng mã không tin cậy để lại tiến trình, tệp hoặc thay đổi môi trường cho job tiếp theo.

Không dùng một sự kiện có quyền cao làm cách lấy secret cho mã chưa được tin cậy. Cũng không đặt điều kiện chỉ dựa vào tên nhánh do người ngoài có thể tạo rồi coi đó là phê duyệt. Quyền chạy, quyền sửa environment và nội dung mã cần được xét cùng nhau. Những quyết định này thuộc chính sách CI của đội, không thể được thay bằng một mẫu YAML hứa an toàn cho mọi cấu trúc repository.

Secret chỉ nên đi vào bước cần nó, trên mã được tin cậy và với kết quả đầu ra đã giới hạn trước.

Đối với action bên thứ ba được thêm sau này, xem nguồn, quyền và phiên bản theo quy trình quản lý dependency. Một action chạy trước step kiểm thử vẫn có thể ảnh hưởng workspace hoặc môi trường. Không cấp toàn bộ secrets cho reusable workflow nếu chỉ cần một giá trị cụ thể. Mẫu tối thiểu dễ kiểm toán hơn một job thừa kế nhiều quyền mà người duy trì không biết phần nào đang sử dụng.

Kiểm thử từ mã được tin cậy

Proxy trong GitHub Actions cho browser và kiểm thử vùng

Playwright mô tả cấu hình HTTP proxy ở browser hoặc context. Đây là lựa chọn phù hợp khi bộ kiểm thử thực sự cần hành vi trình duyệt. Cấu hình proxy và httpCredentials của website là hai khái niệm khác nhau; không nhập credentials endpoint vào mục xác thực HTTP của ứng dụng chỉ vì cả hai cùng có username/password. Đối chiếu API của phiên bản thư viện đã được dự án chốt trước khi chạy trong CI.

Một context sạch giúp tách cookie của hai ca vùng, nhưng không tự thiết lập locale, timezone hoặc geolocation theo IP. Các tham số đó cần được định nghĩa theo ma trận kiểm thử. Nếu vừa thay proxy vừa giữ storage state từ ca vùng khác, kết quả có thể phản ánh cookie cũ. Với sản phẩm có lựa chọn quốc gia lưu theo tài khoản, cần ca riêng để xác nhận thứ tự ưu tiên của từng tín hiệu.

Giới hạn song song theo khả năng endpoint

Matrix có thể tạo nhiều job chạy cùng lúc. Nếu mọi job dùng cùng tài khoản proxy với giới hạn kết nối, tăng max-parallel có thể làm phép thử tự gây lỗi tài nguyên. Đặt mức song song theo hạn mức đã được xác nhận và ngân sách thử nghiệm. Đừng coi một job thất bại ở tải cao là bằng chứng ứng dụng vùng đó lỗi khi chưa loại trừ giới hạn của endpoint hoặc máy runner đang thực thi.

Giới hạn max-parallel áp dụng cho matrix của một lần chạy, chưa phải hạn mức chung của mọi workflow hoặc repository đang dùng cùng endpoint. Mẫu có thêm nhóm concurrency cố định để tránh hai lần chạy của chính workflow này đồng thời nhận secret. Theo cơ chế concurrency của GitHub, cần xem cả hành vi job đang chờ; không coi nhóm này là hàng đợi giữ mọi yêu cầu chạy thủ công theo thứ tự.

Trong mã kiểm tra, chỉ HTTP 200 được chấp nhận, có giới hạn tệp phản hồi và thời gian chờ của subprocess ngoài timeout cURL. Kiểm tra port, scheme và hostname diễn ra trước khi gọi mạng. Các điều kiện này phục vụ target QA đã được quản trị, không biến endpoint tùy ý thành đầu vào được tin cậy. Một yêu cầu bị từ chối ở preflight phải được sửa dữ liệu cấu hình, chưa phải kết luận vùng của proxy bị sai.

Với tác vụ nhiều bước như đăng nhập rồi kiểm tra nội dung, giữ cùng đường kết nối trong suốt ca thử theo yêu cầu của ứng dụng. Endpoint xoay theo từng request có thể không phù hợp nếu hệ thống yêu cầu tính liên tục của phiên. Anh em cần chọn loại endpoint và cách giữ phiên theo tình huống, không chỉ chọn một vùng trong matrix. Tên vùng là một phần dữ liệu kiểm thử, chưa quyết định các thuộc tính vận hành khác.

Nếu chuẩn bị mua proxy, anh em nên mô tả runner, client, vùng cần kiểm tra và mức song song, rồi xác minh endpoint thực tế trước khi thêm secret vào môi trường CI được quản lý.

Vận hành proxy trong GitHub Actions với kết quả có thể tái lập

Kiểm thử cục bộ cho mẫu workflow có thể xác nhận YAML đọc được và script xử lý đúng secret thiếu, target sai, phản hồi sai schema hoặc mã vùng không khớp. Những kiểm tra này không chứng minh GitHub environment đã được tạo hoặc endpoint thương mại truy cập được từ hosted runner. Báo cáo cần tách cú pháp, logic và tích hợp thật. Không gọi một file YAML đã parse là pipeline đã chạy thành công trên GitHub.

Chẩn đoán theo giai đoạn thất bại

Runner không nhận job cần xem kết nối nền, trạng thái dịch vụ và quyền nhận công việc. Step dừng ở preflight cần xem secret hoặc biến cấu hình có được cấp cho environment không. cURL thất bại cần xem đường proxy, DNS, TLS và điều kiện xác thực. Assertion vùng sai cần đối chiếu cách target xác định khách truy cập. Mỗi giai đoạn có dữ liệu cần xem riêng, nên đừng đổi endpoint ngay trước khi biết job đã chạy tới đâu.

Khi bàn giao, lưu tên environment, tên secret, hợp đồng phản hồi, giới hạn thời gian và người chịu trách nhiệm đổi thông tin truy cập. Chỉ ghi tên tham chiếu, không chép giá trị thật vào tài liệu. Chạy lại một ca được phép sau khi đổi runner image hoặc thư viện client, vì môi trường CI có thể thay đổi độc lập với ứng dụng. Một kết quả có điều kiện rõ sẽ hữu ích hơn lời khẳng định proxy luôn hoạt động trong mọi workflow.

Kết quả CI có giới hạn rõ

Proxy trong GitHub Actions nên được cấu hình đúng lớp, cấp secret hẹp và kiểm tra bằng endpoint QA có hợp đồng rõ. Anh em có thể trao đổi yêu cầu kết nối tại Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam, rồi thử tích hợp trước khi mở rộng proxy trong GitHub Actions.