How repositories are added
- Connecting a provider imports every repository the credential can see, subject to the connection’s include/exclude rules, and starts a first scan (organization setting Auto-scan all repositories on connect, on by default).
- New repositories are found automatically. About once an hour TigerGate lists every connected GitHub, GitLab (GitLab.com and self-managed), Bitbucket and Azure DevOps account. Repositories created since the last listing are imported and scanned — nothing to resync by hand. On GitHub and Bitbucket their webhook comes with them; on GitLab and Azure DevOps, re-run the webhook installer script (see Webhooks). Existing repositories are never changed or rescanned by this, and nothing is removed.
- Sync now (in Coverage, or Integrations → Code Providers → Sync) lists a connection straight away instead of waiting for its next hourly run.
- CLI / CI uploads add the repository the pipeline names.
Coverage
Repositories → Coverage shows, for every connection and in total:| Number | Meaning |
|---|---|
| At provider | Repositories the provider exposes to TigerGate, from its latest listing |
| Integrated | In TigerGate and connected: scanned, waiting for a first scan, or disabled |
| Being scanned | Included and connected — scanned on webhooks, schedules and Scan now |
| Excluded | Disabled, left out by the connection’s include/exclude rules, or deleted |
| Not imported | At the provider and allowed by the rules, but not in TigerGate yet |
| Disconnected | No longer at the provider, or the connected account lost access; past results are kept |
Webhooks
Webhooks are what start a scan on a push or a pull / merge request.- GitHub — nothing to do: the GitHub App delivers every repository’s events, new repositories included.
- Bitbucket — connecting over OAuth installs the webhook on every repository, and repositories found later get theirs automatically.
- GitLab and Azure DevOps — their OAuth apps cannot create webhooks for TigerGate, so you run our installer script with a token of your own. It adds the webhook to every project or repository at once. Run it again after adding projects or repositories: the ones that already have the TigerGate webhook are left as they are, and only the new ones get it.
Scheduled scans
Repositories → Scheduled scans. Nothing is scanned on a timer until you create a schedule.- What: the whole organization, chosen projects (GitLab groups include their subgroups), or chosen repositories. A repository follows its most specific schedule: a repository schedule takes over from a project schedule, and a project schedule from the organization one.
- Branches: each repository’s default branch, plus any branches you name. A named branch is skipped in repositories that do not have it.
- When: every 4 hours, every 6 hours, daily at a time, every 30 days, or a custom 5-field cron expression (at most once an hour), in the timezone you pick.
- Run now starts a schedule immediately; its history lists what each run scanned, skipped and why.
Which branches webhooks scan
By default, every pull or merge request is scanned, whatever branch it targets, and merges and pushes are scanned formain and master.
Repositories → Webhook branches narrows that with a rule for the organization, projects or chosen repositories; the most specific rule wins.
- A pull or merge request is scanned when the branch it targets matches; a push when the pushed branch matches.
- Branches are exact names or patterns:
*matches within one path segment (release/*coversrelease/1.2, notrelease/1.2/hotfix),**across segments (hotfix/**),?one character. Matching is case-sensitive. - A rule can instead turn webhook scans off. Manual and scheduled scans are never affected by rules.
Disable, enable and delete
Click Select on the repository list, tick repositories, then Disable or Delete — or use the repository’s Settings → Repository.- Disable — no new scans from anything: webhooks, Scan now, schedules or CLI / CI uploads (an upload’s run completes with a note, so the pipeline is not failed). The repository leaves every list, count and dashboard; its findings are kept. Disabled repositories are listed under Disabled in the corner of the repository list, where Enable brings one back as it was.
- Delete — permanently removes the repository’s findings, scans, SBOM, code quality results, pull request reviews, triage and fix history. You confirm by typing the repository’s name. The repository is not imported or scanned again, even though it still exists at the provider. Audit log entries are kept.