Skip to main content

Issue Providers

A Project's Issues provider is where Testspace creates issues and which issues it follows. The same provider serves automated Results (Triage) and Manual test sessions (Execution).

  • Connected Projects use the Project's own repository by default: its GitHub, GitLab or Bitbucket issues. .testspace.yml can name another provider with issues.provider (Configuration). The value starts with github:, gitlab:, bitbucket: or jira:, followed by an organization (or Jira site) and a repository (or Jira project key), or is generic. The organization or site must be connected in Integrations.
  • Standalone Projects choose it in the Project's Issues provider list (Standalone Projects). The list offers generic, each GitHub repository with issues enabled, and each Jira project, from the Organization's service connections; it doesn't list GitLab or Bitbucket repositories.

Sandbox Spaces never create issues (Sandbox). Neither does a provider whose organization has been disconnected.

Supported Providers​

ProviderCreate issueComment on issueStatus followedLabel
GitHub✔✔✔✔
Jira✔✔✔✔
GitLab✔✔✔✔
Bitbucket✔✔✔
Genericreference only

Comment on issue: from Triage or a Manual test session, Testspace can add a comment to an issue already linked, for example when the case fails again. Comments go one way: comments written in the provider aren't copied into Testspace.

Status followed: when an issue is closed or reopened in the provider, Testspace shows it, as soon as the provider's webhook arrives, with a daily sync as a fallback. A Generic reference's status never changes.

Label: the label Testspace applies to the issues it creates: issues.label in .testspace.yml for a Connected Project (default testspace), the Label field for a Standalone Project (blank: no label).

GitHub​

The default for a Connected Project on GitHub. A label must already exist in the repository; otherwise the issue is created without it.

Jira​

Requires a Jira service connection. New issues are created with the project's Bug issue type, or, if the project has no Bug type, its first type that isn't a subtask (e.g. Task). Content is converted to Jira's wiki markup, so formatting can look slightly different from a GitHub issue. A label that doesn't exist yet is created.

GitLab​

The default for a Connected Project on GitLab.

Bitbucket​

The default for a Connected Project on Bitbucket. Labels aren't applied.

Generic​

For a tracker Testspace doesn't integrate with (Bugzilla, an internal tracker), or for an issue in a service that isn't connected. Generic is reference only: Testspace never creates an issue through it, and stores the references you give it.

To reference an issue, paste its full URL into the issues field (in Triage, or Issues reference (absolute URL) list in a Manual test session). Testspace accepts a URL whose path ends in /issues/<n>, /issue/<n>, /tickets/<n>, /ticket/<n>, /cr/<n>, /browse/<KEY>-<n> or show_bug.cgi?id=<n>. With a GitHub, Jira, GitLab or Bitbucket provider, you can also type #42 or PROJ-42, and Testspace turns it into the provider's issue URL.

Testspace reads the URL's shape to label it and decide whether to follow its status:

Example referenceRead asLabelStatus followed
https://github.com/org/repo/issues/42GitHub#42if org is connected
https://yourcompany.atlassian.net/browse/PROJ-99JiraPROJ-99if yourcompany is connected
https://bugzilla.example.com/show_bug.cgi?id=12other#12no
https://example.com/tickets/14other#14no
info

The service is recognized from the URL: a host containing github, jira, atlassian, bitbucket or gitlab, or a path starting with /jira. If that service's organization isn't connected, the reference is stored like any other, without status; a Jira-style label such as PROJ-99 needs the Organization to have a Jira connection, and is #PROJ-99 otherwise. For other URLs, the label is the number at the end of the URL, so .../browse/ABC-11 on an unrecognized host becomes #11.