Code Repositories
The Administration → Code Repositories page registers connections to Git repositories. A project connects a registered repository for either or both of two purposes:
- QuickScript — the repository of your test automation code. It supplies source-file context to AI-powered test export, so generated automation scripts follow the framework, fixtures, and page objects your team already uses instead of generic boilerplate. See Project QuickScript settings.
- Impact Analysis — the repositories of the application under test (a project can connect several, one per service). It compares two commits of one of them and lists the test cases the changes affect, and test cases can be pinned to their files. See Project Impact Analysis settings and Test Impact Analysis.
- Automated Execution — the repository whose CI runs your automated cases. An execution target reuses the connection's credentials to start a GitHub Actions workflow or a GitLab pipeline from a test run. See Project Automated Execution settings and Automated Execution.
Administrators register and manage repository connections here. The connection is then selected and configured per project under Project Settings → QuickScript, Project Settings → Impact Analysis or Project Settings → Automated Execution.
How to access
- Open the Admin area from the top navigation.
- Select Code Repositories under Tools & Integrations in the admin menu.
Supported providers
| Provider | Connection fields |
|---|---|
| GitHub | Personal Access Token, Owner, Repository, optional API Base URL (GitHub Enterprise Server only) |
| GitLab | Personal Access Token, Project ID or Path, optional GitLab URL (self-hosted) |
| Bitbucket (Cloud) | Atlassian account email, API Token, Workspace, Repository Slug |
| Azure DevOps | Personal Access Token, Organization URL, Project Name, Repository Name or ID |
| Gitea / Forgejo / Gogs | Personal Access Token, Server URL, Owner, Repository |
Authentication is per-repository (token-based, or email + API token for Bitbucket). Credentials are entered by an administrator when the repository is registered, stored encrypted, and never shown again: when you edit a repository the secret fields start blank, and leaving one blank keeps the stored value. Repositories registered before TestPlanIt encrypted these credentials are encrypted automatically the first time the upgraded server starts; scripts/encrypt-code-repository-credentials.ts runs the same pass by hand.
Bitbucket Cloud requirements
- Token type: use an Atlassian API token created for the account whose email you enter. Repository, project and workspace access tokens are not accepted, and app passwords no longer work on Bitbucket Cloud.
- Token scope: the API token needs at least
read:repository:bitbucket. - Git on the workers: TestPlanIt reads a Bitbucket repository's files with a single shallow Git fetch over HTTPS. The
workersDocker image includesgit. If you run the workers outside Docker, installgitand make sure it is on the worker process'sPATH. - Without Git: when no
gitbinary is found, TestPlanIt downloads the repository as a zip from bitbucket.org instead. Bitbucket refuses that download for repositories whose Git history is larger than 2 GB.
Registering a repository
- Click Add (or Add Repository from the empty state).
- Enter a unique Name and choose a Provider. A name another repository already uses is refused, so a second registration can never overwrite the first.
- Fill in the provider-specific connection fields.
- Click Test Connection to verify the credentials and target. A green Connection successful confirms the repo is reachable.
- Save the repository.
Always use https:// URLs for self-hosted servers. If you enter an http:// URL, TestPlanIt warns that credentials would be sent in plaintext.
Managing repositories
The table lists each repository with these columns:
| Column | Description |
|---|---|
| Name | The repository's display name. |
| Provider | GitHub, GitLab, Bitbucket, Azure DevOps, or Gitea / Forgejo / Gogs. |
| Active | A toggle that enables or disables the connection. |
| Projects | How many projects use the repository (through a QuickScript or Impact Analysis connection, or an execution target). Click the badge to list them. |
| Last Tested | When the connection was last verified, or Never. |
| Actions | Edit and delete. |
- Edit reopens the connection form. The provider cannot be changed after creation — to switch providers, delete the repository and add a new one.
- Delete soft-deletes the repository (it can be restored from Trash).
- The Active toggle enables or disables the connection without deleting it.
Connection health
A failed Test Connection flips the repository into an Error state and disables its Active toggle until a successful test re-activates it. Re-run Test Connection after fixing the credentials or target.
How projects use repositories
The data flow spans the admin page and project settings:
- Admin registers the repository here (credentials + a successful connection test).
- A project admin connects the repository to a project, choosing a branch and one or more path patterns (base path + glob):
- under Project Settings → QuickScript for test automation code;
- under Project Settings → Impact Analysis for the application under test;
- under Project Settings → Automated Execution as the repository whose GitHub Actions workflow or GitLab CI pipeline runs the project's automated cases (starting a job needs the
workflowscope on GitHub or theapiscope on GitLab).
- The project's features read from that connection:
- QuickScript: AI test export reads the cached file context so generated scripts match the repository's real code. Repository file context is capped at 500 KB per export; when a project's matched files exceed that budget, files are ranked by relevance and the lowest-ranked are skipped.
- Impact Analysis: Analyze impact lists the repository's branches and commits, compares two commits, and selects the Affected Tests; the Code Pins panel on test case pages picks from the repository's files; and repository markers and ticket keys in recent commit messages are scanned into Code Pins on each cache refresh.
File listings are cached (in Valkey) and can be refreshed from the project's QuickScript or Impact Analysis settings.
When the provider rejects the repository's token or rate limits the account, the cache refresh stops and the project's QuickScript or Impact Analysis settings show the reason. The previously cached files stay in use until a refresh succeeds.
For security, TestPlanIt blocks repository URLs that resolve to private or loopback addresses (SSRF protection). Self-hosted hosts must be allowlisted via the ALLOWED_PRIVATE_HOSTS environment variable.
Related pages
- Project QuickScript settings — connect a repository of test automation code to a project.
- Project Impact Analysis settings — connect the repositories of the application under test to a project.
- Test Impact Analysis — compare commits, select Affected Tests, and pin test cases to code.
- QuickScript Templates — define the export templates AI generation follows.