Connect a CI Provider

Before a test run can drive a pipeline, the workspace needs an integration for that provider with its CI capability turned on.

GitHub and GitLab are each one integration with capabilities, not one integration per feature. The same GitHub connection can file defects as issues and run workflows — you choose which when you connect it.

---

Which capability each provider needs

Provider	Capability to turn on	Also offers
GitHub	Actions — run workflows from automated test runs and import their results	Issues
GitLab	Pipelines — run pipelines from automated test runs and import their results	Issues
Jenkins	(CI only — nothing to choose)	—

At least one capability must be selected. If you turn Actions or Pipelines off later, Hawzu warns you that test runs using it “will report automation as unavailable until it is turned back on” — existing runs are not deleted, they simply stop being able to trigger or import.

Note

GitHub Actions and GitLab CI used to be separate tiles on the Add Integration screen. They no longer are. Older automation configurations that reference them keep working, but new connections are made through the single GitHub or GitLab tile.

---

Connect the provider

1. Open the workspace Integrations page from Advanced in the workspace navigation.

2. Select Add Integration, then choose GitHub, GitLab, or Jenkins.

3. Under What should this integration do?, tick the CI capability — Actions for GitHub, Pipelines for GitLab.

4. Complete the connection. The steps differ by provider:

   • Configure GitHub — a GitHub App install, with no token to create or paste.
   • Configure GitLab — authorize with GitLab, or use a personal access token.
   • Configure Jenkins — Jenkins URL, username, and API token.

5. Choose the repositories or projects this workspace uses. See Repositories and Projects in Use.

---

Provider permissions for CI

GitHub. The Hawzu GitHub App needs Actions: Read and write on the repositories you want to run workflows in. Read alone is not enough — starting a workflow is a write.

GitLab. Authorizing requests the api scope and nothing else; GitLab has no per-feature scopes. Separately from the grant, whoever authorizes needs Developer or above on the projects you want to run pipelines in. GitLab refuses a trigger below that role whatever the authorization allows.

Jenkins. The user whose API token you supply needs permission to build the jobs you point runs at.

Caution

For Hawzu to start a GitHub Actions workflow, that workflow’s workflow_dispatch trigger must exist on the repository’s default branch — GitHub does not expose it otherwise. Hawzu warns about this when you pick the workflow, but does not block you from saving.

---

Choosing which repositories runs can use

Granting access and using a repository are two different things. GitHub decides what Hawzu may see; the Repositories in use step is where you say what it actually uses, so test runs offer a short list rather than every repository in the organisation.

A repository list that has never been configured behaves differently from one configured with nothing selected:

• Not configured — test runs offer every repository the installation can see.
• None selected — test runs will have no repository to choose.

If access to a configured repository is later withdrawn on the provider, the integration shows a Needs attention status and names the repositories that went missing. Runs pointed at them fail until access is restored or the repositories are dropped. See Repositories and Projects in Use.

---

Next Steps

• Create an Automated Test Run
• Repositories and Projects in Use
• Automation Troubleshooting