Automation Troubleshooting

3 min read

Each build records why it ended the way it did. Start with the failing build in Build history, expand it, and read the note — most of the cases below name themselves there.

Hawzu cannot start the workflow

GitHub Actions: the workflow has no workflow_dispatch trigger, or it is not on the default branch. GitHub only exposes a workflow for manual dispatch when the trigger exists on the repository’s default branch — having it on your feature branch is not enough. Hawzu warns about this when you pick the workflow. Merge the trigger to the default branch and try again.

GitLab: the account lacks the Developer role. Authorizing with GitLab grants the api scope, but GitLab still refuses a pipeline trigger from anyone below Developer on that project, whatever the authorization allows. Raise the role, or connect with a personal access token belonging to an account that has it.

The CI capability is switched off. GitHub needs Actions, GitLab needs Pipelines. With it off, runs report automation as unavailable. Turn it back on from the integration’s settings — see Connect a CI Provider.

The GitHub App lacks write access to Actions. Starting a workflow is a write, so Actions: Read and write is required. Read alone silently limits you to importing builds someone else started.

The build never finishes

Hawzu polls on a backoff up to 60 seconds, and gives up after 12 hours with “Gave up waiting for this build to finish.” A build that legitimately takes longer than that needs to notify Hawzu instead of being polled — see Pipelines That Run on Their Own.

If the run appears stuck much earlier than that, check the build on the provider directly. A build waiting on an unavailable agent looks identical to a slow one from Hawzu’s side.

The build produced no readable test report

Nearly always one of these:

The report was not uploaded because the tests failed. This is the single most common cause. In GitHub Actions the upload step needs if: always():

- uses: actions/upload-artifact@v4
  if: always()      # a failing suite is exactly the result QA needs
  with:
    name: junit
    path: results/junit.xml

The report is not in a format Hawzu parses. See Supported Report Formats. Most frameworks can emit JUnit XML.

The artifact was filtered out. Hawzu only downloads .xml, .json, .trx, .zip, and archives, up to 10 artifacts and 64 MB each. A report inside a .tar.gz of screenshots will not be picked up.

To see exactly what Hawzu read, expand the build and use Source report — the raw artifacts are archived against the build.

Results imported, but nothing changed

Every row came back as No matching test case. The report names tests Hawzu cannot resolve to a test case. Put the test case code in the test’s name, or state it explicitly — see How Results Map to Test Cases. The Automation Health report lists exactly which tests these are.

Rows came back as Not in this run. They matched a real test case that is not part of this run. On a manual run that is expected. On an automated run, adoption happens by code only — a row matched by title alone will not pull a case into the run.

Test cases stayed Not Executed. The report never mentioned them. That is intentional and is the coverage signal — it tells you what you meant to automate but did not run.

Results are marked superseded

A build that finishes after a newer build has already reported does not overwrite it. Its rows are kept for reference with the note: “A build started after this one had already reported, so this build’s results were kept for reference and not applied to the run.”

This happens when two builds overlap — usually a re-run started before the first one finished.

The run refuses to import

The run is completed. “This test run is completed. Resume it before importing results.” Completing a run locks it deliberately. Resume it, import, then complete it again.

The release is locked or archived. Executions in a signed-off release stop accepting results by design.

You lack permission. “You don’t have permission to start or import builds on this project.”

The integration says Needs attention

Access to one or more configured repositories was withdrawn on the provider. Runs pointed at them will fail until access is restored, or until the missing repositories are dropped from the integration’s list. Use Re-check connection after fixing it on the provider side. See Repositories and Projects in Use.