Cách chạy Test API từ Apidog CLI

Các bài kiểm tra API của bạn chạy thành công trên máy tính xách tay của bạn. Sau đó, ai đó hợp nhất một thay đổi vào lúc 2 giờ sáng, điểm cuối dàn dựng bắt đầu trả về một tải trọng bị lỗi, và không ai nhận ra cho đến khi một khách hàng gửi yêu cầu hỗ trợ vào sáng hôm sau. Các bài kiểm tra vẫn tồn tại. Chúng chỉ không bao giờ chạy ở nơi cần thiết: bên trong pipeline, trên mỗi lần đẩy, mà không có con người phải nhấp chuột.

Khoảng cách giữa "các bài kiểm tra tồn tại" và "các bài kiểm tra chạy tự động" chính xác là những gì một công cụ chạy dòng lệnh giải quyết. Apidog CLI lấy các kịch bản kiểm thử mà bạn đã xây dựng trong ứng dụng Apidog trên máy tính để bàn hoặc web và chạy chúng mà không cần giao diện người dùng từ một terminal. Không có GUI, không cần nhấp chuột thủ công. Bạn cài đặt nó bằng một lệnh npm, chỉ định nó vào một kịch bản kiểm thử, và nó sẽ thoát với một mã trạng thái sạch và một báo cáo mà bạn có thể xuất bản trong bất kỳ hệ thống CI nào. Điều đó làm cho nó trở thành cầu nối giữa công cụ xây dựng kiểm thử trực quan và nền tảng CI/CD của bạn.

nút

Tóm tắt

• Apidog CLI là một gói npm có tên apidog-cli. Cài đặt toàn cục bằng lệnh npm install -g apidog-cli, sau đó chạy các kịch bản bằng lệnh apidog run.
• Nó chạy các kịch bản kiểm thử mà bạn thiết kế trong Apidog. Bạn không cần viết lại các bài kiểm thử dưới dạng mã; CLI thực thi cùng một kịch bản theo ID, sử dụng mã truy cập để xác thực.
• Chạy cơ bản: apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenarioId> -e <environmentId> -n 1 -r html,cli.
• Các trình báo cáo bao gồm cli, html, json và junit. JUnit XML là định dạng tích hợp trực tiếp vào bảng điều khiển kiểm thử của CI.
• Mã thoát khác 0 khi kiểm thử thất bại là điều biến CLI thành một cổng chất lượng thực sự. Các kiểm thử thất bại sẽ làm cho bản dựng thất bại theo mặc định.
• Nó hoạt động trong bất kỳ trình chạy CI nào có Node.js: GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure Pipelines, và nhiều hơn nữa.

Apidog CLI thực sự là gì

Apidog là một nền tảng API tất cả trong một: bạn thiết kế lược đồ, gỡ lỗi các yêu cầu, xây dựng các kịch bản kiểm thử tự động, mô phỏng các điểm cuối và xuất bản tài liệu trong một không gian làm việc. Hầu hết công việc đó diễn ra trong một giao diện trực quan. Bạn nối chuỗi các yêu cầu thành một kịch bản kiểm thử, thêm các xác nhận, kéo các giá trị từ một phản hồi sang phản hồi tiếp theo và lặp lại trên một tệp dữ liệu.

CLI là công cụ thực thi không giao diện (headless executor) cho các kịch bản đó. Nó không có định dạng kiểm thử riêng. Nó truy cập vào dự án Apidog của bạn, tìm kịch bản mà bạn đặt tên theo ID và chạy nó chính xác như ứng dụng sẽ làm, sau đó báo cáo kết quả. Hãy coi đó là mối quan hệ giữa một công cụ xây dựng và mã nguồn của bạn: nguồn sự thật nằm trong dự án, và CLI là thứ chạy nó mà không cần sự hiện diện của con người.

Điều này quan trọng vì nó loại bỏ lý do phổ biến nhất khiến các bài kiểm thử API trở nên lỗi thời. Khi các bài kiểm thử chỉ tồn tại dưới dạng các bước có thể nhấp trong một ứng dụng máy tính để bàn, chúng sẽ được chạy khi ai đó nhớ. Khi chúng chạy từ một lệnh duy nhất, bạn có thể tích hợp chúng vào một pipeline và chúng sẽ chạy trên mỗi lần commit, mỗi lần hợp nhất, mỗi lịch trình hàng đêm. Công cụ xây dựng trực quan giúp bạn tạo tác nhanh chóng; CLI mang lại cho bạn khả năng tự động hóa. Bạn có được cả hai mà không cần phải lựa chọn.

Nếu bạn đến từ thế giới Postman, mô hình tư duy này sẽ dễ hiểu. Apidog CLI đóng vai trò tương tự như Postman CLI hoặc Newman đối với các bộ sưu tập Postman, ngoại trừ việc nó chạy các kịch bản kiểm thử của Apidog và được đóng gói dưới dạng một gói duy nhất. Chúng tôi đã đề cập sâu về sự so sánh đó trong bài viết Postman CLI vs Newman, và câu hỏi rộng hơn về việc chạy các bộ sưu tập trong CI mà không cần Newman nếu bạn đang di chuyển.

Điều kiện tiên quyết

Trước khi bạn chạy bất kỳ lệnh nào, bạn cần ba thứ:

1. Node.js v16 trở lên. CLI được phân phối dưới dạng gói npm, vì vậy môi trường chạy Node là phụ thuộc hệ thống duy nhất. Kiểm tra phiên bản của bạn bằng node -v. Bất kỳ image CI nào có Node 16+ đều đủ điều kiện.
2. Một kịch bản kiểm thử Apidog. CLI chạy các kịch bản, không phải các yêu cầu rời rạc. Hãy xây dựng một kịch bản trong ứng dụng Apidog trước: nối chuỗi các yêu cầu của bạn, thêm các xác nhận, thiết lập bất kỳ lần lặp dựa trên dữ liệu nào bạn cần. Nếu bạn mới làm quen với việc viết các xác nhận, Xác nhận API: hướng dẫn thực hành sẽ hướng dẫn bạn cách xác thực các phản hồi.
3. Một mã truy cập (access token). Mã này xác thực CLI với tài khoản Apidog của bạn để nó có thể tìm nạp và chạy kịch bản. Bạn tạo nó trong tab CI/CD của kịch bản kiểm thử; chi tiết hơn ở dưới.

Chỉ vậy thôi. Không cần cài đặt Apidog riêng trên máy chủ CI, không cần GUI, không cần tệp giấy phép. Gói và một mã truy cập là đủ.

Cài đặt Apidog CLI

Cài đặt toàn cục bằng npm:

npm install -g apidog-cli

Sau đó xác nhận mọi thứ đã được giải quyết chính xác:

node -v && apidog -v && which node && which npm && which apidog

Nếu nó in ra số phiên bản và đường dẫn, bạn đã hoàn tất. File thực thi là apidog, vì vậy mỗi lệnh bắt đầu bằng apidog run.

Trên máy của nhà phát triển, cài đặt toàn cục là ổn. Trong CI, bạn có hai mô hình hợp lý. Cách thứ nhất là cài đặt lại trong mỗi lần chạy pipeline, đảm bảo bạn đang sử dụng phiên bản mới nhất:

npm install -g apidog-cli
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli

Cách thứ hai là chạy nó mà không cần cài đặt toàn cục vĩnh viễn thông qua npx, điều này tránh làm thay đổi các gói toàn cục của trình chạy:

npx apidog-cli run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli

Cả hai cách đều hoạt động. Cách tiếp cận npx sạch hơn cho các trình chạy CI tạm thời; cài đặt toàn cục nhanh hơn một chút khi bạn lưu trữ nó giữa các lần chạy.

Lấy mã truy cập và ID kịch bản của bạn

CLI cần biết hai điều: kịch bản nào cần chạy và liệu nó có được phép chạy kịch bản đó hay không. Apidog tạo cả hai cho bạn để bạn không phải tìm kiếm trong giao diện người dùng.

Mở kịch bản kiểm thử bạn muốn tự động hóa. Chuyển sang tab CI/CD của nó. Chọn tùy chọn dòng lệnh, sau đó nhấp vào Thêm mã truy cập và Tạo mã. Apidog sẽ tạo lệnh apidog run hoàn chỉnh cho bạn, với mã truy cập, ID kịch bản và ID môi trường đã được điền sẵn. Nhấp vào lệnh để sao chép.

Lệnh được tạo đó là điểm khởi đầu chính thức. Nó trông như thế này:

apidog run --access-token YOUR_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,cli

Các con số là ID thực từ dự án của bạn. 605067 là ID kịch bản kiểm thử. 1629989 là ID môi trường. Bạn hầu như sẽ không bao giờ gõ những số này bằng tay; bạn sao chép chúng từ tab CI/CD một lần và sau đó tham số hóa mã truy cập.

Một quy tắc đáng nói sớm: hãy coi mã truy cập như một mật khẩu. Đừng dán nó vào một tệp cấu hình đã commit hoặc một định nghĩa pipeline công khai. Lưu trữ nó như một bí mật trong hệ thống CI của bạn và tham chiếu nó dưới dạng biến môi trường. Mỗi ví dụ dưới đây đều sử dụng $APIDOG_ACCESS_TOKEN chính vì lý do này.

Lệnh apidog run, từng cờ một

Toàn bộ CLI xoay quanh một lệnh. Đây là toàn bộ các tùy chọn, được nhóm theo chức năng kiểm soát của từng nhóm.

Chọn những gì để chạy

Bạn chọn một trong -t, -f, hoặc --test-suite tùy thuộc vào phạm vi. Một kịch bản duy nhất cho một bài kiểm tra smoke test tập trung, một thư mục cho một khu vực tính năng, một bộ kiểm thử khi bạn muốn một tập hợp các kịch bản được tuyển chọn chạy cùng nhau như một công việc logic duy nhất.

Xác thực

Đây là cờ duy nhất mà mọi lệnh CI đều cần. Truyền nó từ một bí mật, không bao giờ viết trực tiếp vào lệnh.

Môi trường và lặp lại

Cờ môi trường là cách bạn chỉ định cùng một kịch bản tới staging trong kiểm tra pull request và tới production trong smoke test sau triển khai, mà không cần nhân đôi kịch bản. Dữ liệu lặp lại là cách bạn chạy một kịch bản trên năm mươi hàng dữ liệu đầu vào và coi mỗi hàng là một lần chạy riêng biệt. Chúng tôi đề cập đầy đủ hơn về mẫu dựa trên dữ liệu trong hướng dẫn về mở rộng quy mô kiểm thử API tự động với các bộ kiểm thử.

Báo cáo

Đây là nơi CLI khẳng định vị trí của nó trong một pipeline. Truyền nhiều định dạng cùng một lúc, phân tách bằng dấu phẩy:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -r html,junit --out-dir ./test-reports

cli cung cấp đầu ra terminal dễ đọc cho con người khi đọc nhật ký bản dựng. html tạo ra một báo cáo độc lập mà bạn có thể lưu trữ dưới dạng artifact bản dựng và mở trong trình duyệt. junit xuất XML theo định dạng JUnit tiêu chuẩn, mà hầu hết mọi bảng điều khiển CI đều biết cách phân tích thành cây pass/fail. json cung cấp cho bạn kết quả cấu trúc thô nếu bạn muốn xử lý sau.

Xử lý lỗi và hành vi thoát

--on-error kiểm soát những gì xảy ra giữa kịch bản. end dừng chạy ở lỗi đầu tiên, điều này thường được mong muốn đối với một smoke test thất bại nhanh chóng. continue chạy mọi bước để bạn thấy tất cả các lỗi trong một báo cáo. ignore dành cho trường hợp hiếm khi một bước được biết là không ổn định và bạn không muốn nó làm chệch hướng quá trình chạy.

TLS và chứng chỉ

Sử dụng các cờ này khi bạn kiểm tra các điểm cuối phía sau TLS lẫn nhau hoặc với chuỗi CA nội bộ. Chỉ sử dụng -k đối với các máy chủ nội bộ đáng tin cậy nơi chứng chỉ tự ký; không bao giờ sử dụng cho bất kỳ thứ gì công khai.

Đầu ra và chẩn đoán

--verbose là bước đầu tiên bạn nên thực hiện khi một kiểm thử vượt qua cục bộ nhưng thất bại trong CI; nó cho bạn thấy yêu cầu chính xác mà trình chạy đã gửi và phản hồi chính xác mà nó nhận được. --silent dành cho các công việc hàng đêm ồn ào mà bạn chỉ quan tâm đến mã thoát và báo cáo đã lưu.

Mã thoát: phần làm cho CI hoạt động

Một trình chạy kiểm thử chỉ hữu ích trong một pipeline nếu nó thông báo cho pipeline liệu các kiểm thử có vượt qua hay không. Apidog CLI thực hiện điều này theo cách mà mọi công cụ dòng lệnh hoạt động tốt đều làm: nó thoát với mã 0 khi mọi xác nhận vượt qua và một mã khác 0 khi có điều gì đó thất bại.

Hành vi duy nhất đó là điều biến apidog run thành một cổng chất lượng. Các hệ thống CI đọc mã thoát của mỗi bước. Một mã thoát khác 0 đánh dấu bước đó là thất bại, điều này làm cho công việc thất bại, từ đó chặn việc hợp nhất hoặc triển khai. Bạn không cần cấu hình thêm bất cứ điều gì. Miễn là bước apidog run nằm trong pipeline của bạn, một kiểm thử thất bại sẽ dừng quy trình.

Bạn có thể điều chỉnh điều này bằng --on-error. Hành vi mặc định là thất bại ở xác nhận lỗi đầu tiên, giúp phản hồi nhanh chóng. Chuyển sang --on-error continue khi bạn muốn xem tất cả các lỗi trong một báo cáo trước khi bản dựng chuyển sang trạng thái đỏ. Dù bằng cách nào, quá trình chạy vẫn kết thúc với mã thoát khác 0 nếu có bất kỳ lỗi nào, vì vậy cổng chất lượng vẫn được duy trì.

Chạy trong GitHub Actions

quy trình làm việc hoàn chỉnh chạy một kịch bản Apidog trên mỗi pull request và xuất bản báo cáo dưới dạng một artifact.

name: API tests

on:
 pull_request:
 branches: [main]

jobs:
 api-tests:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout
 uses: actions/checkout@v4

 - name: Set up Node.js
 uses: actions/setup-node@v4
 with:
 node-version: '20'

 - name: Install Apidog CLI
 run: npm install -g apidog-cli

 - name: Run API test scenario
 run: |
 apidog run \
 --access-token "$APIDOG_ACCESS_TOKEN" \
 -t 605067 \
 -e 1629989 \
 -n 1 \
 -r html,junit \
 --out-dir ./apidog-reports
 env:
 APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

 - name: Upload report
 if: always()
 uses: actions/upload-artifact@v4
 with:
 name: apidog-report
 path: ./apidog-reports

Mã truy cập nằm trong các bí mật của kho lưu trữ và được truyền đến bước dưới dạng biến môi trường. Điều kiện if: always() trên bước tải lên có nghĩa là bạn vẫn nhận được báo cáo ngay cả khi các kiểm thử thất bại, đây chính là lúc bạn muốn đọc nó. Nếu một kiểm thử bị lỗi, bước apidog run thoát với mã khác 0, công việc chuyển sang màu đỏ và PR hiển thị một kiểm tra thất bại.

Chạy trong GitLab CI

Mô hình tương tự trong .gitlab-ci.yml:

stages:
 - test

api-tests:
 stage: test
 image: node:20
 script:
 - npm install -g apidog-cli
 - >
 apidog run
 --access-token "$APIDOG_ACCESS_TOKEN"
 -t 605067
 -e 1629989
 -r junit,cli
 --out-dir ./apidog-reports
 artifacts:
 when: always
 paths:
 - apidog-reports/
 reports:
 junit: apidog-reports/*.xml

Hai điều cần lưu ý. Lưu trữ APIDOG_ACCESS_TOKEN dưới dạng biến CI/CD được che giấu, bảo vệ trong Cài đặt, không phải trong tệp. Và khối reports: junit: yêu cầu GitLab phân tích cú pháp JUnit XML và hiển thị kết quả trong widget của merge request, để người đánh giá thấy những xác nhận nào đã thất bại mà không cần tải xuống bất cứ điều gì.

Chạy trong Jenkins

Trong một declarative pipeline, lưu trữ mã truy cập dưới dạng thông tin xác thực Jenkins hoặc biến môi trường toàn cục, sau đó gọi CLI trong một giai đoạn:

pipeline {
 agent any
 environment {
 APIDOG_ACCESS_TOKEN = credentials('apidog-access-token')
 }
 stages {
 stage('API tests') {
 steps {
 sh 'npm install -g apidog-cli'
 sh 'apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit --out-dir apidog-reports'
 }
 }
 }
 post {
 always {
 junit 'apidog-reports/*.xml'
 archiveArtifacts artifacts: 'apidog-reports/', allowEmptyArchive: true
 }
 }
}

Nếu các tác nhân xây dựng của bạn đã cài đặt và lưu trữ CLI, hãy bỏ dòng npm install và gọi apidog run trực tiếp. Bước junit trong khối post cung cấp XML vào biểu đồ xu hướng kiểm thử của Jenkins; archiveArtifacts giữ báo cáo HTML đính kèm vào bản dựng. Nếu bạn đang cân nhắc Jenkins so với các trình chạy khác, sự so sánh trong bài viết Thiết lập ReadyAPI Jenkins CI và một lựa chọn thay thế đơn giản hơn sẽ bao gồm các đánh đổi.

Các mẫu và công thức phổ biến

Kiểm tra smoke test sau triển khai. Chạy một kịch bản nhanh chóng đối với môi trường production ngay sau khi phát hành, nhắm mục tiêu vào môi trường prod:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e <prodEnvId> -r cli --on-error end

Kiểm tra hồi quy đầy đủ hàng đêm. Chạy toàn bộ thư mục các kịch bản theo lịch trình, với tất cả các lỗi được thu thập vào một báo cáo:

apidog run --access-token $APIDOG_ACCESS_TOKEN -f <folderId> -r html,junit --on-error continue --out-dir ./nightly-reports

Chạy dựa trên dữ liệu. Lặp một kịch bản trên một tệp CSV chứa các trường hợp kiểm thử:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -d ./test-data.csv -r junit

Kiểm tra theo nhánh cụ thể. Chạy các kịch bản như chúng tồn tại trên một nhánh tính năng, không phải main:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 --branch feature-payments -e 1629989 -r cli

Gỡ lỗi một lỗi chỉ có trong CI. Khi một kịch bản vượt qua cục bộ nhưng thất bại trong pipeline, hãy thêm --verbose để xem yêu cầu cấp dây chính xác và phản hồi mà trình chạy đã tạo.

Khắc phục sự cố

Lỗi xác thực. Nếu lần chạy thất bại với lỗi xác thực, mã truy cập có thể sai, đã hết hạn hoặc không đến được lệnh. In ra một kiểm tra ẩn (không bao giờ là mã đầy đủ) và xác nhận bí mật CI của bạn thực sự đã được điền. Tạo lại mã truy cập từ tab CI/CD của kịch bản nếu cần.

"Không tìm thấy kịch bản." ID kịch bản, ID dự án hoặc nhánh không khớp. Sao chép lại lệnh từ tab CI/CD để đảm bảo các ID là hiện tại, và xác nhận --branch chỉ đến nơi bạn mong muốn.

Các kiểm thử vượt qua cục bộ nhưng thất bại trong CI. Hầu như luôn là sự khác biệt về môi trường. Trình chạy CI có thể nhắm mục tiêu một môi trường -e khác, truy cập một máy chủ mà nó không thể tiếp cận, hoặc thiếu một biến mà kịch bản của bạn phụ thuộc vào. Chạy với --verbose và so sánh yêu cầu mà trình chạy CI đã gửi với những gì bạn gửi cục bộ.

Lỗi mạng hoặc TLS đối với các máy chủ nội bộ. Nếu điểm cuối của bạn sử dụng CA nội bộ, hãy truyền --ssl-extra-ca-certs. Chỉ sử dụng -k như một biện pháp cuối cùng trên các máy chủ nội bộ đáng tin cậy nơi chứng chỉ tự ký.

Bản dựng vẫn xanh ngay cả khi một kiểm thử đáng lẽ phải thất bại. Xác nhận rằng mã thoát của bước apidog run thực sự đến được CI. Nếu bạn đã gói nó trong một shell pipeline hoặc thêm || true, mã thoát khác 0 sẽ bị nuốt chửng và cổng chất lượng ngừng hoạt động. Xóa bất cứ thứ gì che giấu mã thoát.

Apidog CLI phù hợp với quy trình làm việc thực tế như thế nào

CLI là một phần của một vòng lặp. Bạn thiết kế và gỡ lỗi các yêu cầu trong ứng dụng Apidog. Bạn nối chuỗi chúng thành một kịch bản với các xác nhận. Bạn commit công việc của mình và CLI chạy kịch bản đó trong CI trên mỗi thay đổi. Khi có lỗi, báo cáo cho bạn biết xác nhận nào đã thất bại và mã thoát dừng việc triển khai. Bạn khắc phục lỗi, đẩy lại, và cùng một cổng chất lượng sẽ xác nhận bản sửa lỗi.

Ưu điểm của việc xây dựng kiểm thử trực quan và chạy chúng không giao diện là không ai phải duy trì hai phiên bản của cùng một kiểm thử. Kịch bản trong dự án chính là kiểm thử. CLI chỉ chạy nó ở nơi mà con người không thể có mặt. Đó là một mô hình khác so với các trình chạy ưu tiên script, nơi kiểm thử và việc thực thi của nó là cùng một tệp dễ hỏng, và đó là một phần lớn lý do tại sao các đội chuyển sang Apidog như một lựa chọn thay thế Postman cho kiểm thử API.

Nếu bạn chưa xây dựng các kiểm thử, hãy bắt đầu trong ứng dụng, làm cho một kịch bản vượt qua, sau đó kết nối lệnh CLI từ tab CI/CD của nó. Tải Apidog để thiết lập kịch bản tự động đầu tiên của bạn, và bạn sẽ có nó kiểm soát pipeline của mình ngay trong buổi chiều hôm đó.

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

Apidog CLI có miễn phí không? Bản thân CLI là một gói npm miễn phí. Bạn cài đặt nó bằng npm install -g apidog-cli. Nó chạy các kịch bản kiểm thử từ dự án Apidog của bạn, vì vậy những gì bạn có thể chạy phụ thuộc vào gói Apidog của bạn, nhưng trình chạy dòng lệnh không phải là một sản phẩm trả phí riêng biệt.

Tôi có phải viết lại các bài kiểm thử của mình dưới dạng mã để sử dụng CLI không? Không. Đó là điểm khác biệt chính so với các trình chạy ưu tiên script. Bạn xây dựng các kịch bản trực quan trong Apidog, và CLI chạy chúng theo ID. Kịch bản là bài kiểm thử; CLI chỉ là công cụ thực thi.

Sự khác biệt giữa Apidog CLI và Newman là gì? Newman chạy các bộ sưu tập Postman từ dòng lệnh. Apidog CLI chạy các kịch bản kiểm thử của Apidog. Các vai trò song song, nhưng trình chạy Apidog thực thi các kịch bản bạn đã tạo trong ứng dụng Apidog và được đóng gói dưới dạng một gói apidog-cli duy nhất. Xem Postman CLI vs Newman để biết phần so sánh về Postman.

Tôi nên sử dụng định dạng báo cáo nào trong CI? Sử dụng junit cho kết quả có thể đọc được bằng máy mà bảng điều khiển CI của bạn phân tích cú pháp thành cây pass/fail, và thêm html nếu bạn muốn một báo cáo có thể duyệt được lưu dưới dạng artifact bản dựng. Một lựa chọn phổ biến là -r html,junit. Giữ cli nếu bạn muốn đầu ra dễ đọc trong nhật ký bản dựng.

Làm thế nào CLI làm cho một bản dựng thất bại? Thông qua mã thoát của nó. Khi bất kỳ xác nhận nào thất bại, apidog run thoát với mã khác 0. Các hệ thống CI đọc mã thoát đó, đánh dấu bước đó là thất bại và chặn việc hợp nhất hoặc triển khai. Bạn không cần cấu hình thêm bất cứ điều gì để điều này hoạt động.

Tôi có thể chạy CLI mà không cần cài đặt toàn cục không? Có. Sử dụng npx apidog-cli run ... để thực thi nó mà không cần cài đặt toàn cục vĩnh viễn, điều này tiện lợi trên các trình chạy CI tạm thời.

Tôi cần phiên bản Node.js nào? Node.js v16 trở lên. Bất kỳ image CI hiện đại nào có Node 16+ đều đáp ứng yêu cầu.

Tôi lấy mã truy cập và ID kịch bản ở đâu?** Cả hai đều đến từ tab CI/CD của kịch bản kiểm thử trong Apidog. Chọn tùy chọn dòng lệnh, tạo mã truy cập và sao chép toàn bộ lệnh apidog run mà Apidog tạo cho bạn với các ID đã được điền sẵn. Sau đó di chuyển mã truy cập vào một bí mật CI.

nút