Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion automate-k6-cicd-lj/content.json
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
"blocks": [
{
"type": "markdown",
"content": "Welcome to the Grafana learning path that shows you how to automate k6 performance tests in your CI/CD pipelines. Running k6 manually gives you performance data when you think to ask for it. Automating k6 in your pipeline gives you performance data on every deploy, with the ability to block releases that don't meet your standards.\n\nThis path guides you from a manually run k6 script to a CI/CD performance gate. You'll verify that thresholds produce the right exit codes, parameterize your script for multiple environments, add k6 to GitHub Actions or GitLab CI, and stream results to Grafana Cloud k6. By the end, performance testing is part of the daily workflow \u2014 not a laptop-only habit.\n\n## Here's what to expect\n\nWhen you complete this path, you'll be able to:\n\n- Explain what a CI/CD performance gate is and why exit codes matter\n- Verify that k6 thresholds pass and fail with the correct exit codes\n- Parameterize a script with `__ENV` so one script runs across environments\n- Add k6 to GitHub Actions or GitLab CI\n- Treat threshold breaches as pipeline failures that block merges or deploys\n- Stream automated test results to Grafana Cloud k6\n\n## Before you begin\n\nBefore you automate k6 in your CI/CD pipeline, ensure that you have:\n\n- A Grafana Cloud account. To create an account, refer to [Grafana Cloud](https://grafana.com/signup/cloud/connect-account).\n- k6 installed on your machine. To install k6, refer to [k6 installation](https://grafana.com/docs/k6/latest/get-started/installation/).\n- A k6 test script with thresholds. If you don't have one yet, complete [Run your first k6 performance test](https://grafana.com/docs/learning-paths/run-first-k6-test/) and [Establish a performance baseline with k6](https://grafana.com/docs/learning-paths/establish-k6-baseline/) first.\n- A code editor such as [Visual Studio Code](https://code.visualstudio.com/) or [Cursor](https://www.cursor.com/).\n- Access to a terminal or command line interface.\n- Access to a CI/CD platform such as GitHub Actions or GitLab CI.\n- Basic familiarity with your CI/CD platform's YAML configuration.\n\n## Troubleshooting\n\nIf you get stuck, we've got your back! Where appropriate, troubleshooting information is just a click away.\n\n## More to explore\n\nWe understand you might want to explore other capabilities not strictly on this path. We'll provide you opportunities where it makes sense."
"content": "Welcome to the Grafana learning path that shows you how to automate k6 performance tests in your CI/CD pipelines. Running k6 manually gives you performance data when you think to ask for it. Automating k6 in your pipeline gives you performance data on every deploy, with the ability to block releases that don't meet your standards.\n\nThis path guides you from a manually run k6 script to a CI/CD performance gate. You'll verify that thresholds produce the right exit codes, parameterize your script for multiple environments, add k6 to GitHub Actions or GitLab CI, and stream results to Grafana Cloud k6. By the end, performance testing is part of the daily workflow, not a laptop-only habit.\n\n## Here's what to expect\n\nWhen you complete this path, you'll be able to:\n\n- Explain what a CI/CD performance gate is and why exit codes matter\n- Verify that k6 thresholds pass and fail with the correct exit codes\n- Parameterize a script with `__ENV` so one script runs across environments\n- Add k6 to GitHub Actions or GitLab CI\n- Treat threshold breaches as pipeline failures that block merges or deploys\n- Stream automated test results to Grafana Cloud k6\n\n## Before you begin\n\nBefore you automate k6 in your CI/CD pipeline, ensure that you have:\n\n- A Grafana Cloud account. To create an account, refer to [Grafana Cloud](https://grafana.com/signup/cloud/connect-account).\n- k6 installed on your machine. To install k6, refer to [k6 installation](https://grafana.com/docs/k6/latest/get-started/installation/).\n- A k6 test script with thresholds. If you don't have one yet, complete [Run your first k6 performance test](https://grafana.com/docs/learning-paths/run-first-k6-test/) and [Establish a performance baseline with k6](https://grafana.com/docs/learning-paths/establish-k6-baseline/) first.\n- A code editor such as [Visual Studio Code](https://code.visualstudio.com/) or [Cursor](https://www.cursor.com/).\n- Access to a terminal or command line interface.\n- Access to a CI/CD platform such as GitHub Actions or GitLab CI.\n- Basic familiarity with your CI/CD platform's YAML configuration.\n\n## Troubleshooting\n\nIf you get stuck, we've got your back! Where appropriate, troubleshooting information is just a click away.\n\n## More to explore\n\nWe understand you might want to explore other capabilities not strictly on this path. We'll provide you opportunities where it makes sense."
}
]
}
2 changes: 1 addition & 1 deletion automate-k6-cicd-lj/end-journey/content.json
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
"blocks": [
{
"type": "markdown",
"content": "Congratulations on completing this learning path! Job well done!\n\nYou've accomplished the following:\n\n- Learned what CI/CD performance gates are and how exit codes turn k6 thresholds into automated deploy decisions\n- Verified that your k6 thresholds produce the correct exit codes for pipeline integration\n- Parameterized your script with `__ENV` variables so a single script runs against multiple environments\n- Added k6 as an automated step in GitHub Actions or GitLab CI\n- Configured your pipeline to treat k6 threshold breaches as build failures that block merges and deployments\n- Streamed automated test results to Grafana Cloud k6 for persistent storage and team visibility\n\n### What's next\n\nk6 is now in the daily workflow. Next you can operationalize the gate further \u2014 environment-specific thresholds, regression tracking, and failure notifications \u2014 and expand coverage to browser tests and Core Web Vitals for full-stack teams."
"content": "Congratulations on completing this learning path! Job well done!\n\nYou've accomplished the following:\n\n- Learned what CI/CD performance gates are and how exit codes turn k6 thresholds into automated deploy decisions\n- Verified that your k6 thresholds produce the correct exit codes for pipeline integration\n- Parameterized your script with `__ENV` variables so a single script runs against multiple environments\n- Added k6 as an automated step in GitHub Actions or GitLab CI\n- Configured your pipeline to treat k6 threshold breaches as build failures that block merges and deployments\n- Streamed automated test results to Grafana Cloud k6 for persistent storage and team visibility\n\n### What's next\n\nk6 is now in the daily workflow. Next, you can extend the gate with environment-specific thresholds, regression tracking, and failure notifications. You can also expand coverage to browser tests and Core Web Vitals."
}
]
}
2 changes: 1 addition & 1 deletion automate-k6-cicd-lj/handle-exit-code/content.json
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
"blocks": [
{
"type": "markdown",
"content": "k6 uses exit codes to communicate test results to the pipeline. Exit code `0` means all thresholds passed. A non-zero exit code means the test failed \u2014 for threshold breaches, k6 commonly returns `99`. Most CI/CD platforms treat any non-zero exit code as a job failure by default, but you still need to confirm that nothing in your job swallows that signal.\n\nTo ensure your pipeline correctly handles the k6 exit code, complete the following steps:\n\n1. Verify that your CI platform fails the job on a non-zero exit code. In GitHub Actions, each step fails the job by default when the command returns a non-zero exit code. `grafana/run-k6-action` preserves this behavior, so no additional configuration is needed if you used the setup from the previous milestone.\n\n1. If you run k6 using a shell script or Docker command in your pipeline, ensure the exit code propagates. A common mistake is wrapping k6 in a script that doesn't forward the exit code:\n\n ```bash\n # Wrong \u2014 the echo succeeds and masks a k6 failure\n docker run --rm grafana/k6:latest run /tests/test.js\n echo \"Test complete\"\n ```\n\n The `echo` command returns exit code `0` regardless of the k6 result. Instead, ensure k6 is the last command, or capture the exit code explicitly:\n\n ```bash\n docker run --rm grafana/k6:latest run /tests/test.js\n K6_EXIT=$?\n echo \"Test complete with exit code $K6_EXIT\"\n exit $K6_EXIT\n ```\n\n1. Test the gate by temporarily setting a threshold that will fail, as you did in the verify-thresholds milestone. Push the change and confirm the pipeline marks the job as failed.\n\n In GitHub Actions, a failed job shows a red X next to the step. In GitLab CI, the job status changes to `failed`. The pipeline log shows which k6 thresholds were breached.\n\n1. Revert the threshold to its passing value and push again. Confirm the pipeline passes.\n\n> **Tip:** For pull request workflows, configure your repository to require the k6 job to pass before merging. In GitHub, go to **Settings** > **Branches** > **Branch protection rules** and add your performance test job to the required status checks. In GitLab, keep the job in a stage that blocks the pipeline by default.\n\n1. Confirm the full cycle: a passing test allows the pipeline to continue, and a failing test blocks the merge or deploy. This is your performance gate.\n\nIn the next milestone, you trigger a full pipeline run and verify the automated results end to end."
"content": "k6 uses exit codes to communicate test results to the pipeline. Exit code `0` means all thresholds passed. A non-zero exit code means the test failed. For threshold breaches, k6 commonly returns `99`. Most CI/CD platforms treat any non-zero exit code as a job failure by default, but you still need to confirm that nothing in your job swallows that signal.\n\nTo ensure your pipeline correctly handles the k6 exit code, complete the following steps:\n\n1. Verify that your CI platform fails the job on a non-zero exit code. In GitHub Actions, each step fails the job by default when the command returns a non-zero exit code. `grafana/run-k6-action` preserves this behavior, so no additional configuration is needed if you used the setup from the previous milestone.\n\n1. If you run k6 using a shell script or Docker command in your pipeline, ensure the exit code propagates. A common mistake is wrapping k6 in a script that doesn't forward the exit code:\n\n ```bash\n # Wrong: the echo succeeds and masks a k6 failure\n docker run --rm grafana/k6:latest run /tests/test.js\n echo \"Test complete\"\n ```\n\n The `echo` command returns exit code `0` regardless of the k6 result. Instead, ensure k6 is the last command, or capture the exit code explicitly:\n\n ```bash\n docker run --rm grafana/k6:latest run /tests/test.js\n K6_EXIT=$?\n echo \"Test complete with exit code $K6_EXIT\"\n exit $K6_EXIT\n ```\n\n1. Test the gate by temporarily setting a threshold that will fail, as you did in the verify-thresholds milestone. Push the change and confirm the pipeline marks the job as failed.\n\n In GitHub Actions, a failed job shows a red X next to the step. In GitLab CI, the job status changes to `failed`. The pipeline log shows which k6 thresholds were breached.\n\n1. Revert the threshold to its passing value and push again. Confirm the pipeline passes.\n\n> **Tip:** For pull request workflows, configure your repository to require the k6 job to pass before merging. In GitHub, go to **Settings** > **Branches** > **Branch protection rules** and add your performance test job to the required status checks. In GitLab, keep the job in a stage that blocks the pipeline by default.\n\n1. Confirm the full cycle: a passing test allows the pipeline to continue, and a failing test blocks the merge or deploy. This is your performance gate.\n\nIn the next milestone, you trigger a full pipeline run and verify the automated results end to end."
}
]
}
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
"blocks": [
{
"type": "markdown",
"content": "You've configured k6 as a pipeline step with exit code handling. Now trigger a clean automated run and confirm the gate behaves as expected end to end. At this stage, results live in your CI logs. In the next milestone, you'll stream those results to Grafana Cloud k6 for history and team visibility.\n\nTo run your first automated test, complete the following steps:\n\n1. Confirm your workflow file is committed and your test script path matches the workflow `path` (or GitLab `script`) value.\n\n1. Trigger a pipeline run. The simplest way is to push an empty commit or open a pull request:\n\n ```bash\n git commit --allow-empty -m \"Trigger k6 performance pipeline\"\n git push\n ```\n\n1. Open the workflow run in your CI platform and watch the k6 job. Confirm that:\n\n - The job checks out your repository\n - k6 starts and prints the test summary\n - The job finishes green when thresholds pass\n\n1. Optionally force a controlled failure one more time (tighten a threshold, push, confirm red, then revert). This is the moment the team can trust the gate: green means within budget, red means stop and investigate.\n\n1. Save a link to a successful run in your team's runbook or Definition of Done notes. From here, performance is no longer \"run it when you remember\" \u2014 it's a pipeline dependency.\n\nIn the next milestone, you stream results to Grafana Cloud k6 so automated runs persist beyond CI log retention."
"content": "You've configured k6 as a pipeline step with exit code handling. Now trigger a clean automated run and confirm the gate behaves as expected end to end. At this stage, results live in your CI logs. In the next milestone, you'll stream those results to Grafana Cloud k6 for history and team visibility.\n\nTo run your first automated test, complete the following steps:\n\n1. Confirm your workflow file is committed and your test script path matches the workflow `path` (or GitLab `script`) value.\n\n1. Trigger a pipeline run. The simplest way is to push an empty commit or open a pull request:\n\n ```bash\n git commit --allow-empty -m \"Trigger k6 performance pipeline\"\n git push\n ```\n\n1. Open the workflow run in your CI platform and watch the k6 job. Confirm that:\n\n - The job checks out your repository\n - k6 starts and prints the test summary\n - The job finishes green when thresholds pass\n\n1. Optionally force a controlled failure one more time (tighten a threshold, push, confirm red, then revert). This is the moment the team can trust the gate: green means within budget, red means stop and investigate.\n\n1. Save a link to a successful run in your team's runbook or Definition of Done notes. From here, performance is no longer \"run it when you remember.\" It's a pipeline dependency.\n\nIn the next milestone, you stream results to Grafana Cloud k6 so automated runs persist beyond CI log retention."
}
]
}
Loading
Loading