Create an Automated Test Run
2 min read
An automated test run is created the same way as a manual one, with one extra decision: which pipeline runs it.
Create the run
Section titled “Create the run”-
Open Test Runs in your project and select Create Test Run.
-
Set Type to Automated (CI/CD). The field explains the difference: “A manual run is worked through by testers; an automated run is driven by a CI/CD pipeline.”
-
Fill in the title, description, and any other run details as usual.
-
In the CI/CD Config panel — “Which pipeline runs this test run, and what happens on create.” — choose the pipeline.
-
Choose what happens on create, then save.
If nothing is connected yet, the panel says so instead: “No CI/CD provider is connected to this workspace yet. Connect Jenkins, GitHub Actions or GitLab CI under Integrations, then come back.” See Connect a CI Provider.
Choosing the pipeline
Section titled “Choosing the pipeline”Start with CI/CD provider, then work down. The fields below it are named by the provider you picked — Hawzu takes the labels from the provider itself rather than assuming everyone calls things the same thing.
| Provider | First field | Second field | Branch field |
|---|---|---|---|
| Jenkins | (none — Jenkins is flat) | Job | — |
| GitHub Actions | Repository | Workflow | Branch |
| GitLab CI | Project | Branch | — |
The branch field is pre-filled with the repository’s default branch, so nobody has to know it — and so Hawzu never guesses main on a repository that uses something else.
Build parameters
Section titled “Build parameters”Build parameters takes one KEY=value per line, for example:
These are passed to the build each time the run triggers it.
Entering an identifier by hand
Section titled “Entering an identifier by hand”If the provider cannot be browsed — restricted credentials, a very large organisation, or a job Hawzu’s discovery does not surface — use Pipeline identifier, described in the form as “Entered by hand, when the provider cannot be browsed”.
| Provider | Format | Example |
|---|---|---|
| Jenkins | The job name; for a job inside folders, folder/job | nightly-regression |
| GitHub Actions | owner/repo/workflow-file | acme/web-app/.github/workflows/e2e.yml |
| GitLab CI | The GitLab project id, or a URL-encoded path | 1234567 |
When this run is created
Section titled “When this run is created”Three choices, and they are not equivalent:
- Start a new build — “The build starts immediately, and results import themselves when it finishes.”
- Use a finished build — “Pull the report from a build that already ran.” A Build picker appears so you can choose which one.
- Just bind the pipeline — “Nothing runs now. Start a build later from the run itself.”
Whichever you choose, the pipeline stays attached to the run, so you can trigger it again later from the run itself.