Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
You can run Azure Load Testing from a GitHub Actions workflow by checking your test plan into the repository, authorizing the workflow to use an Azure Load Testing resource, and calling the azure/load-testing action with your test configuration file, resource name, and resource group. Pass/fail gating works through client-side failure criteria defined in the test YAML. Server-side metric criteria cannot be enforced from GitHub Actions, and that limit shapes how you should design the pipeline.
What the pipeline needs before the first run
Microsoft’s CI/CD guide for Azure Load Testing assumes a few prerequisites are in place. Set these up first, because most first-run failures trace back to one of them.
- An Azure Load Testing resource in an Azure subscription, and at least one existing load test in that resource.
- A repository containing the test plan (a JMeter
.jmxfile or a Locust.pyfile), the test configuration YAML, and any supporting CSV or properties files the plan reads. - A workflow file under
.github/workflowsin that repository. - An identity that the workflow can use to sign in to Azure, with permission on the load testing resource (see the authentication section below).
The workflow, step by step
The sequence in Microsoft’s guide is short. Each step maps to one entry in the workflow file.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems- Trigger the run. Use the trigger your team needs, such as
push,pull_request, a schedule, orworkflow_dispatchfor manual runs. - Check out the repository. Use
actions/checkoutso the test plan and YAML are present in the runner’s workspace. - Authenticate to Azure. Use
azure/loginwith the identity you configured. - Run the load test. Call
azure/load-testingwith theloadTestConfigFile,loadTestResource, andresourceGroupinputs. - Upload the results. Publish the generated
loadTestfolder withactions/upload-artifact. Microsoft’s example places this step after the load-testing action.
A working file looks like this. Replace the placeholder names with your own values, and confirm the current major versions of the actions in their repositories, since Microsoft’s manual guide still shows an older azure/login@v1 example.
#1 Best Overall
name: Load test
on:
workflow_dispatch:
push:
branches: [ main ]
permissions:
contents: read
id-token: write
jobs:
load-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: azure/login@v2
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/load-testing@v1
with:
loadTestConfigFile: 'tests/checkout-config.yaml'
loadTestResource: 'lt-shop-prod'
resourceGroup: 'rg-loadtest'
- uses: actions/upload-artifact@v4
if: always()
with:
name: loadTest
path: loadTest
The if: always() condition on the upload step matters. When the load test fails its failure criteria, the run is marked failed and later steps are skipped by default. Without that condition, the results you most need for diagnosis are never uploaded.
Authenticating the workflow to Azure
The workflow needs permission to start a load test on your resource. Microsoft’s guide uses a Microsoft Entra service principal that holds the Azure RBAC Load Test Contributor role, scoped to the Azure Load Testing resource rather than the whole subscription. The credentials are stored as a GitHub Actions secret. Microsoft’s Azure Login guidance also covers OpenID Connect, which avoids storing a long-lived client secret, and managed identities for self-hosted runners.
| Option | How the workflow signs in | Where the identity values live | Best fit |
|---|---|---|---|
| Service principal with a client secret | Azure Login uses the service principal’s credentials | GitHub secrets, referenced as ${{ secrets.NAME }} |
Teams with an existing service principal pattern; requires secret rotation |
| OpenID Connect (federated credential) | GitHub issues a short-lived token that Azure exchanges for access | Client ID, tenant ID, and subscription ID as GitHub secrets; no stored client secret | Hosted runners where you want to avoid long-lived credentials |
| Managed identity | The runner itself is an Azure resource with an assigned identity | Not stated in the GitHub secrets model; the identity is attached to the runner | Self-hosted runners running inside Azure |
Whichever option you choose, keep identity values in GitHub secrets rather than in the workflow file. Microsoft’s Azure Login guidance recommends this, even though client IDs and tenant IDs are not themselves passwords.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Rank #2
Writing the test configuration
The test YAML describes the test identity, the test plan, engine count, and other settings. The schema reference covers test identity and plan, engine instance count, configuration files, environment variables, secrets, client certificates, app components, private-network settings, regional configuration, and managed identities.
Three fields matter most for a pipeline:
versionmust bev0.1in the schema documented by Microsoft.testIdis required and must be 2 to 50 characters long, using only lowercase letters, digits, underscores, or hyphens.failureCriteriaholds your client-side pass/fail rules, covered in the next section.
A minimal configuration might look like this:
version: v0.1
testId: checkout-smoke
testPlan: checkout.jmx
engineInstances: 1
failureCriteria:
- avg(response_time_ms) > 300
- percentage(error) > 1
- GetCart: avg(response_time_ms) > 500
The request-level line (GetCart) must match the name of the JMeter sampler or the Locust request exactly. Rename a request in the script without updating the YAML, and the criterion no longer points at the request you intended.
Pass/fail criteria in CI
Pass/fail gating in a pipeline comes from the failureCriteria block. Microsoft’s examples include average response time, error percentage, and criteria tied to a named request. The workflow log reports the outcome, and the job is marked as failed when a criterion is breached, which is what blocks a merge or deployment.
Rank #3
What CI can enforce
Client-side metrics computed from the load generator’s results, such as response time and error rate, can be enforced from the YAML. This is the supported path for a build gate.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →What CI cannot enforce
Microsoft states that Azure Load Testing does not support configuring failure criteria on server-side metrics from Azure Pipelines or GitHub Actions. Server-side criteria, such as thresholds on the resources under test, are configured through the Azure portal. A GitHub Actions workflow cannot fail on those thresholds through the documented YAML. If your gate depends on server metrics, you need a separate check that reads those metrics after the run, or you accept that the portal is the place where those thresholds apply.
Waiting for the result
Microsoft’s guide notes that setting waitForCompletion: false lets the workflow continue without waiting for the test to finish. That is useful for long soak tests started in parallel with other jobs. It also means the workflow cannot report the pass or fail outcome, so use it only when a later step or a separate job checks the result.
Rank #4
- Penetration Testing Azure for Ethical Hackers: Develop practical skills to perform pentesting and risk assessment of Microsoft Azure environments
- Packt Publishing
- ABIS BOOK
Passing secrets and reaching secured endpoints
Load tests often need credentials or certificates. There are three distinct cases, and each uses a different mechanism.
Secrets used by the test script
For values the script reads at runtime, such as a test user password, Microsoft’s example passes a secrets parameter to the azure/load-testing action. Each entry maps a GitHub Actions secret to a named secret that the test references. Keep the secret in GitHub, never in the JMeter file or the YAML.
Secrets and certificates in Azure Key Vault
If the test reads secrets or certificates from Azure Key Vault, the Azure Load Testing resource needs access, not the GitHub workflow. Enable a system-assigned or user-assigned managed identity on the resource, then grant that identity the vault permissions the test needs.
Best Value
Endpoints that require Microsoft Entra authentication
For an API that requires a token, assign a managed identity to the Azure Load Testing resource and select that identity in the test configuration. The test script must then acquire an access token for the target endpoint and send it with requests. The managed identity also needs permission on the target resource. A failed run with 401 or 403 responses usually means one of these two grants is missing.
Finding and keeping results
Azure Load Testing writes its output to a loadTest folder in the GitHub Actions workspace. The folder has two parts:
- Results folder: one CSV file per test engine, with per-request details.
- Report folder: an HTML summary and performance graphs.
The upload step publishes this folder as a workflow artifact. Open the workflow run in GitHub, scroll to the Artifacts section at the bottom of the summary page, and download the artifact. Artifacts have a retention period set by the repository or organization, so copy results you need long term to other storage.
Troubleshooting common failures
- The login step fails. Check that the client ID, tenant ID, and subscription ID secrets exist and that the federated credential or service principal matches the repository and branch in use.
- The load-testing step cannot find the test. Confirm
loadTestResourceandresourceGroupname the resource exactly, and that the workflow identity has the Load Test Contributor role scoped to that resource. - The configuration is rejected. Check that
testIdmeets the 2 to 50 character rule and thatversionisv0.1. - A request-level criterion never applies. The name in the YAML does not match the sampler or request name in the script.
- No results appear after a failed run. The upload step was skipped. Add
if: always()to it. - A Key Vault secret or endpoint returns an access error. The Azure Load Testing resource’s managed identity is missing a grant on the vault or the target service.
When you need a server-side threshold to fail a build, treat that as a design decision rather than a configuration fix. The documented GitHub Actions path does not enforce it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
