Automating JMeter and k6 in CI

Automating JMeter and k6 in CI makes performance testing repeatable and visible to the whole team. Both tools can run in non-GUI/CLI mode, produce machine-readable results and integrate with common CI platforms.

Running JMeter in CI #

For JMeter, you typically check JMX files into version control and run them using the jmeter command-line interface. CI jobs can generate JTL result files and HTML reports, which are then stored as artifacts for later review.

# Example: GitHub Actions step for JMeter
- name: Run JMeter checkout test
  run: |
    jmeter -n -t perf/checkout.jmx -l results.jtl -j jmeter.log
    jmeter -g results.jtl -o jmeter-report

Running k6 in CI #

k6 integrates naturally with CI via simple CLI commands and thresholds that control the exit code. You can pass environment-specific settings via variables or configuration files and upload summary output or exported metrics as artifacts.

# Example: GitLab CI job for k6
perf_test:
  stage: test
  image: grafana/k6
  script:
    - k6 run --vus 30 --duration 1m tests/login_smoke.js

With automation in place, teams can re-run performance jobs consistently and track changes over time.

Common Mistakes #

Mistake 1 — Running tools with default settings in CI #

This may be inefficient.

❌ Wrong: Using GUI-oriented configurations or missing environment parameters.

✅ Correct: Tune command-line options and configs for non-interactive runs.

Mistake 2 — Not publishing or preserving performance reports #

This loses evidence.

❌ Wrong: Letting reports disappear after each run.

✅ Correct: Store results in known locations and link them from pipeline views.