The CLI is designed to slot into any CI/CD pipeline that can run a shell command. These examples show common patterns: a basic run gate, a data-driven run, and a scheduled automation. Adapt the journey names, environments, and paths to match your setup.
When to use it
- Adding a journey run as a deploy gate (fail the build if the journey fails).
- Running API workflow tests on every pull request or push.
- Scheduling recurring journey runs to catch silent regressions between deployments.
Key concepts
Exit codes. reqflo run exits with 0 on success and non-zero on any failure. CI systems use this to fail the job automatically — no extra scripting needed.
Authentication in CI. Use the REQFLO_TOKEN environment variable. Generate a token in your Reqflo account settings and store it as a CI secret — never hardcode it.
JUnit output. Most CI platforms can consume JUnit XML reports for test result annotations and dashboards. Use --reporter junit --output <path> and point the CI config at the file.
Examples
Basic journey run on push:# .github/workflows/api-checks.yml
name: API journey checks
on:
push:
branches: [main]
pull_request:
jobs:
journey:
runs-on: ubuntu-latest
steps:
- name: Install reqflo
run: curl -fsSL https://install.reqflo.io | sh
- name: Run journey
env:
REQFLO_TOKEN: ${{ secrets.REQFLO_TOKEN }}
run: |
reqflo run my-journey \
--env staging \
--case "Happy path" \
--cloud \
--reporter junit \
--output ./results/report.xml
- name: Upload test results
uses: actions/upload-artifact@v4
if: always()
with:
name: journey-results
path: ./results/report.xml
- name: Run data-driven journey
env:
REQFLO_TOKEN: ${{ secrets.REQFLO_TOKEN }}
run: |
reqflo run my-journey \
--env staging \
--data ./test-data/users.csv \
--cloud \
--reporter junit \
--output ./results/report.xml
- name: Publish test results
uses: mikepenz/action-junit-report@v4
if: always()
with:
report_paths: ./results/report.xml
Basic journey run:# .gitlab-ci.yml
api-journey:
stage: test
image: ubuntu:22.04
before_script:
- curl -fsSL https://install.reqflo.io | sh
script:
- reqflo run my-journey
--env staging
--case "Happy path"
--cloud
--reporter junit
--output report.xml
variables:
REQFLO_TOKEN: $REQFLO_TOKEN
artifacts:
when: always
reports:
junit: report.xml
journey-staging:
stage: test
script:
- reqflo run my-journey --env staging --case "Happy path" --cloud --reporter junit --output staging-report.xml
artifacts:
reports:
junit: staging-report.xml
journey-production:
stage: validate
script:
- reqflo run my-journey --env production --case "Happy path" --cloud --reporter junit --output prod-report.xml
artifacts:
reports:
junit: prod-report.xml
only:
- main
Scheduled run example
Run a journey on a schedule to catch silent regressions between deployments. This GitHub Actions example runs nightly:
# .github/workflows/scheduled-checks.yml
name: Nightly API checks
on:
schedule:
- cron: "0 2 * * *" # 2 AM UTC every day
workflow_dispatch: # also allow manual triggering
jobs:
nightly-journey:
runs-on: ubuntu-latest
steps:
- name: Install reqflo
run: curl -fsSL https://install.reqflo.io | sh
- name: Run journey suite
env:
REQFLO_TOKEN: ${{ secrets.REQFLO_TOKEN }}
run: |
reqflo run checkout-flow \
--env production \
--case "Happy path" \
--cloud \
--reporter json \
--output ./results/nightly.json
- name: Archive results
uses: actions/upload-artifact@v4
if: always()
with:
name: nightly-${{ github.run_id }}
path: ./results/nightly.json
retention-days: 30
For scheduled production runs, use a dedicated test account or sandbox-equivalent user rather than a real customer account. This keeps your production data clean and makes runs predictable.
Related pages
