Company-level GitHub connection (app/bot or shared token) instead of a token per project

[antonyramirez-at-m42]

Is your feature request related to a problem? Please describe.

The GitHub connection is configured per project, so on an instance with many projects the same credential has to be set up over and over.

We are self-hosted, our test projects map to repositories, and we have 100+ repositories across two GitHub organizations — 24 services with integration tests reporting today and more to come. Each project needing its own GitHub token means the same connection is re-entered for every project, has to be re-entered again whenever it is rotated, and is easy to get wrong or forget on a newly created project. It is the one piece of per-project configuration that does not vary between projects: the token is identical every time.

This was raised in the Testomat.io Slack channel and confirmed to be in your backlog already (thank you Tetiana) — filing it here so it can be tracked and so we get notified when it ships.

Describe the solution you'd like

A GitHub connection configured once per company or per instance, which projects inherit.

Either shape would solve it:

• a company-level (or instance-level) GitHub token that every project in the company uses by default, with an optional per-project override
• or better, a GitHub App / bot installation that can be authorised once against an organization and reused by every project in the company, so no long-lived personal token is stored at all

Two details that matter for self-hosted:

• please note the release or image version the change lands in. We deploy from your published images and need to know which tag to bump to in order to pick it up
• if it becomes a GitHub App, self-hosted instances need to be able to register their own app against their own domain, rather than depending on an app owned by app.testomat.io

Describe alternatives you've considered

1. Setting the token on every project by hand. What we do now. It works, but the effort and the rotation cost scale with the project count, and a missed project fails quietly rather than loudly.
2. Scripting it through the API. We could not find a project-settings endpoint that sets the GitHub connection, so there is nothing to automate against.
3. Keeping one shared project for all repositories so there is only one place to configure. We tried this and rejected it for reporting reasons: a single project mixes every service's tests and consolidates their metrics into one graph (see Group projects within a company (organizations/categories on the Projects dashboard) #1664 for the related grouping problem).

Additional context

This is the same theme as two other requests we filed, all pointing the same way — configuration that is identical for every project should live above the project:

• Public API: endpoint to create a project (POST /api/projects) #1663 — no API endpoint to create a project, so projects cannot be provisioned per repository from CI
• Group projects within a company (organizations/categories on the Projects dashboard) #1664 — no way to group projects within a company, so a large project list cannot be classified

Reporting itself already works this way for us and it is a good model to compare against: one organization-level secret holds a general API token, CI exchanges it for the right project's token at report time, and no per-repository credential is stored anywhere. A company-level GitHub connection would give the GitHub integration the same property.