Connected Projects

A Connected project is "connected" to a single Git repository through an integrated Service: GitHub, Bitbucket, or GitLab.

To create a new project click the New Project button at the top right of your organization's view.

Select one of the available repositories and click OK. All currently connected repositories will be grayed out and unselectable. A public repo is represented by an open lock vs a closed lock for private.

Each project is connected to a single Git repository, where spaces map to branches in the repository. Spaces are automatically created with each new branch and are hidden when the branch is deleted.

info

Creating a new project or editing the properties of an existing project requires Administrator or Owner privileges.

Options

To edit the settings of an existing project, in the organization's Projects tab, hover your mouse over a row in the listing, on the very left a "hamburger" icon will be shown. If you left-click on the icon, a menu is displayed with options:

Menu item	Description
Edit	Dialog for updating the default project name (<org-name>:<repo-name>) and accessing the Push token.
Access	Dialog for a selection of users that have access to the project with their current email notification settings.
Sync	Reactivate stale project.
Delete	A selection of users that have access to the project with their current email notification settings.

Push Token

Testspace supports a unique project token to use with the Testspace client when publishing test results to this project.

The Push token can be copied from the Project's options Edit menu dialog.

Spaces

Spaces under the project represent the repository's branches that have associated test results. Only the default branch (i.e. main) will be listed without having results.

When a new branch in the repository is created a new corresponding space is automatically created:

• It will be named after the branch name
• Is pre-populated with exemptions and metrics from the most recent result in the space corresponding to the base branch (if such data exists). The prepopulated "base" content is given an auto-generated result name: [<number>]<base-space-name>#<base-result-set-name>

There are also spaces automatically created:

• For each Fork Pull Request to the repository, named after the PR ID (e.g. PR-123) and pre-populated with exemptions and metrics from the most recent result in the space corresponding to the PR target branch.
• Single, named :TAGS: for results representing all Tags in the repository.

Options

To access a space's options select the hamburger menu on the left side of the name (i.e. main):

Edit dialog	Description
Name	Read-only. Derived from the branch name.
Description	Textual description of the space. The description text supports a subset of Markdown.
Sandbox	Read-only. Branches that are "non" default branches are automatically set as a sandbox.
Health Indicators	Allows you to specify a Publication deadline for results in days. Exceeding the deadline fails the space's health. A value of 0 disables the deadline (default).

The Reset option allows removing all test content associated with the space.

Sandbox

Sandbox spaces are used primarily for staging new tests and have the following attributes:

• Issue generation disabled
• Results email notifications disabled
• Not shown in the Organization view
• Excluded from project Insights

Unless explicitly changed via configuration, all branches are set to the sandbox state except for:

• Default branch
• Open Pull Request with the corresponding branch (or fork) set as a base. Note that draft Pull Requests stay in the sandbox state.

Configuration

Testspace behavior can be customized regarding

• Manual testing
• Issue provider
• Release branches
• Commit Status

using a configuration file called .testspace.yml that is placed at the root of your repo branch, for example:

root
├── README.md
└── .testspace.yml
..

The full .testspace.yml configuration format is:

manual:
  path: "/path/to/thespecs" # optional path to specs root, defaults to "specs"
  publish_path: "path/to/report" # optional Testspace result's path to publish status to, defaults to ""

issues:
  provider: # optional, defaults to "github:" (current org/repo)
  label: # optional, defaults to "testspace"

release: "*_rel" # optional one or more branch-wildcard entries

commit_status: true # optional, defaults to true

Manual

To enable manual testing the following minimum content:

manual:

The path represents the root folder for spec files. It the path is omitted, the root defaults to specs.

manual:
  path: "/path/to/thespecs" # optional path to specs root, defaults to "specs"

The publish_path represents the folder-path to publish status. It the publish_path is omitted, the root defaults to "".

manual:
  publish_path: "/path/to/report" # optional path to specs root, defaults to "specs"

Note that the publish_path is typically only used when publishing automated results into the same space.

Issues

issues:
  provider: # optional, defaults to "github:" (current org/repo)
  label: # optional, defaults to "testspace"

The provider can be configured for github, jira, or generic.

For github an organization and repo are required to be specified: provider: github:org/repo

issues:
  provider: "github:s2technologies/mircoservices"

tip

The default is GitHub using the current organization/repo connected to the project.

For jira a site and a project key are required to be specified: provider: jira:site/key

issues:
  provider: "jira:s2technologies/TST"

info

To use Jira requires establishing a service connection.

For generic the following is required to be specified: provider: generic

Issues are read only and can only be referenced.

issues:
  provider: generic

The label is used to associate an existing label with issues generated by Testspace. Defaults to testspace.

Release

A repo's default branch (i.e. main) is always a release space. All other branches are sandbox spaces unless explicitly configured or apart of an Open Pull Request (non-draft).

Testspace can be customized to manage "non" default branches as release spaces.

release:
  - "*_rel.1*" # optional one or more branch-wildcard entries
  - "*_rel.2*"

When using * or &, at the beginning of a wildcard, make sure to use quotes.

info

A repo's default branch (i.e. main) is always a release space.

Commit Status

Testspace adds a status check when test results are published with an associated commit-id. This behavior is enabled by default (true) but can be disabled.

commit_status: false

tip

For repos that contain only tests, we recommend disabling the "commit_status". The commit status is only applicable for repos containing application source code.

Deletion

A repository deletion does not result in the connected project being deleted. A project can only be deleted manually through its options. Deleted projects may be restored up to thirty days after they are deleted. Refer to the Standalone Project Deletion for restoration policy.

A Space in a connected Project follow the life time of its corresponding branch (or fork-PR) - it is automatically hidden when the branch is deleted (or fork-PR closed). All associated metric data is maintained up to 12 months to provide statistics for the project.

note

The lifetime of individual Results is bound to a separate retention policy.