Repository Dependency Scanner
Inspect a GitHub, GitLab, or generic Git repository to discover package dependencies, HTTP/API/config references, matches to registered applications, and gaps in the dependency registry.
Who this is for
Architects and application owners who want to compare source-of-truth code with the PlanIT application and API registry.
How to open it
In the workspace, go to Tools → Repository Dependency Scanner.
Before you scan
- You must be signed in. Application matching uses the current enterprise’s application inventory.
- Public repositories usually work without a token.
- Private repositories need an access token for that host (GitHub PAT, GitLab token, or equivalent). The token is used only for this scan and is not stored.
- Optionally pick a Source Application so registry cross-checks can prefer that application’s known APIs.
Scan form
| Field | Required | Notes |
|---|---|---|
| Repository URL | Yes | Full URL (https://github.com/owner/repo, https://gitlab.com/group/project) or GitHub-style owner/repo. Git HTTPS/SSH URLs are also accepted. |
| Branch | No | Defaults to the repository default (typically main). |
| Source application | No | Applications in your enterprise. |
| Access token | No | Required for private repos. Password-style field; not persisted. |
Choose Scan Repository.
What the scanner reads
It walks the repository tree (API listing, with clone fallback when needed) and inspects:
Package manifests (up to 25 files, plus up to 15 .csproj files):
package.jsonpackages.configrequirements.txt,pyproject.toml,Pipfilepom.xmlbuild.gradle,build.gradle.ktsgo.modGemfilecomposer.json*.csproj(NuGetPackageReference)
Source and config files (up to 45 files, skipped if larger than 512 KB):
- Extensions:
.cs,.js,.ts,.tsx,.jsx,.py,.java,.go,.rb,.php - Config names:
appsettings.json,appsettings.development.json,application.yml/.yaml,docker-compose.yml/.yaml,.env.example
The scanner looks for HTTP URLs, API-style paths, and configuration hostnames in those files.
Results
A successful scan shows:
| Summary card | Meaning |
|---|---|
| Repository | Display name, provider (GitHub / GitLab / Git), and branch used |
| Package dependencies | Deduplicated packages with name, version, and ecosystem |
| Code references | HTTP / API / config snippets with file path |
| App matches | Registered applications whose names appear in discovered references |
Additional sections:
- Warnings — truncated trees, missing files, clone fallback, and similar.
- Manifests scanned — paths that were actually parsed.
- Package dependencies — first 100 rows in the table.
- Application matches — confidence and a link to the application detail page.
- Code references — first 80 items, with type, reference, file, and snippet.
- Dependency registry cross-check — whether the reference is already registered. Registered rows link to the API detail page. Unregistered rows offer Register dependency (
Create → New Interface).
Use Open registry to jump to the application dependencies list.
Limits and behavior
- Package lists are unique by ecosystem and name.
- Code references are unique by file and reference, capped at 200 internally (80 shown in the code section, 80 in the registry table).
- Temporary clones are deleted after the scan.
- Failures (bad URL, auth, network) show an error on the same page; the form values are kept.
Tips
- Prefer the canonical HTTPS URL of the default branch for the most complete tree.
- For self-hosted GitLab, use the full instance URL and a token with
read_repository(or equivalent) scope. - Run the scan after onboarding so application and API names can match.
- Register missing APIs, then scan again to confirm they show as registered.