Issue Providers

A project's Issues provider determines where Testspace creates and references issues. This applies to both automated test result annotations and Manual test-case failures — both features resolve through the exact same provider; there's no separate setting for Manual.

• Connected projects default to whichever service (GitHub, GitLab, or Bitbucket) the repo itself is connected to — no configuration needed for that default. GitHub can also be explicitly pointed at a different org/repo, and Jira or Generic configured instead, via .testspace.yml's issues.provider — see Configuration. GitLab and Bitbucket don't have an explicit override prefix; only the auto-derived default is available for those.
• Standalone projects configure this via the project's Issues provider dropdown, which offers Generic, GitHub, and Jira — see Standalone Projects. GitLab and Bitbucket aren't available for Standalone, since there's no connected repo to derive them from.

Supported Providers

Provider	Create issue	Post follow-up comments	Status auto-synced	Labels
GitHub	Yes	Yes	Yes	Yes
Jira	Yes	Yes	Yes	Yes
GitLab	Yes	Yes	Yes	Yes
Bitbucket	Yes	Yes	Yes	No
Generic	No — reference only	No	No	No

"Post follow-up comments" is one-way (Testspace → provider) — on a repeat failure of a case already linked to an issue, Testspace adds a comment there; comments added directly on the provider side don't come back into Testspace.

tip

Status auto-sync. Close an issue directly in Jira, GitHub, GitLab, or Bitbucket, and Testspace reflects it as Closed automatically — in real time via webhooks where connected, backed by a daily sync as a fallback. This only applies to issues resolved against an actually-connected provider; a Generic reference's status is set once, when first added, and never updates after that.

GitHub

The default provider for a Connected project whose repo is on GitHub, using the current org/repo — or explicitly pointed at a different org/repo via .testspace.yml's issues.provider: github:org/repo. Fully supported: creating issues, posting follow-up comments, status sync, and labels. A label must already exist in the target repo — one that doesn't exist yet is silently skipped, not created.

Jira

Requires a Jira service connection. New issues are automatically typed as Bug (or the project's first non-subtask issue type, if Bug isn't available), and content is converted to Jira's own wiki markup, not left as plain Markdown — formatting that looks right in a GitHub issue may render slightly differently in Jira. Unlike GitHub, a configured label doesn't need to already exist — Jira adds a new label value automatically.

GitLab

Used automatically for a Connected project whose repo is on GitLab — same as GitHub, there's nothing to explicitly select. Same level of support as GitHub: issue creation, follow-up comments, status sync, and labels are all supported. Not available for Standalone projects.

Bitbucket

Used automatically for a Connected project whose repo is on Bitbucket — same as GitHub, there's nothing to explicitly select. Issue creation, follow-up comments, and status sync are supported, but labels are not — a configured label is silently ignored for Bitbucket issues. Not available for Standalone projects.

Generic

For teams using a bug tracker Testspace doesn't integrate with directly (Bugzilla, an internal tracker, etc.), or for referencing a GitHub/Jira/GitLab/Bitbucket issue without a service connection set up. Generic is reference-only — Testspace never creates issues through it, only stores a reference to one you already have.

Paste an issue's URL into the ISSUES form to reference it. What Testspace does with that URL depends on whether it recognizes the shape of a known provider:

Example reference	Recognized as	Display label	Status tracked?
https://github.com/org/repo/issues/42	GitHub	#42	Yes — if org/repo is a connected GitHub org/repo
https://yourcompany.atlassian.net/browse/PROJ-99	Jira	PROJ-99	Yes — if yourcompany/PROJ is a connected Jira org/project
https://ourtracker.example.com/jira/browse/ABC-5	Jira-shaped (path contains /jira/)	ABC-5	Only if ourtracker/ABC happens to match a connected Jira org/project
https://bugzilla.example.com/show_bug.cgi?id=12	Not a recognized provider	#12	No
https://example.com/tickets/14	Not a recognized provider	#14	No

info

Recognition is based on URL shape — a hostname containing github/jira/atlassian/bitbucket/gitlab, or a path starting with /jira — not on whether that specific tool is actually connected. A URL that looks like Jira but points at an org Testspace doesn't have connected still gets stored and displayed with a Jira-style key, it just never gets live status tracking.

For anything that doesn't match one of those shapes, Testspace falls back to extracting the trailing number in the URL as the display label — .../cr/13 becomes #13, .../show_bug.cgi?id=12 becomes #12. There's no Bugzilla-specific (or other tool-specific) parsing beyond that — and a project-key-style reference like .../browse/ABC-11 on a non-Jira-shaped URL loses its ABC- prefix and becomes just #11, since only the trailing digits are captured.