Repositories & sources

A System is built from your code. That code reaches Nomain through repositories, and the repositories attached to a particular System are its sources.

Repositories vs sources

• A repository is a saved connection to where your code lives, either a Git repository or an SFTP location. You define it once under your account and reuse it across any number of Systems. It has a name, a type, and connection details.
• A source is a repository that has been attached to a specific System. A System's sources are the repositories it is built and analyzed from. The same repository can be a source of several Systems at once.

When you attach a source to a System, Nomain pulls a fresh copy of the code, stores it securely, and analyzes it to build the System's model.

Managing repositories

Repositories live in the Integrations dialog, opened from the user menu (bottom-left). Its Repositories section lets you:

• Add repository: enter a Name, choose a Type (Git or SFTP), and fill in the connection details.
• Edit repository: change its name or connection details.
• Delete repository: remove it entirely; it leaves the list immediately (see the warning below).

Connection details and credentials

Type	Fields	Credentials
Git	URL	A Credentials Type selector: None or User/Password. Username and password fields appear only when User/Password is chosen; if you set one, the other is required.
SFTP	URL, Path	Username and Password (required).

The dialog flags any missing required fields before saving, so incomplete connection details are caught up front.

For Git repositories, the credentials must grant read access to any git submodules the repository references. Credentials are stored in a secure vault, never inside the System itself.

Deleting a repository unlinks it everywhere

Deleting a repository removes its stored code copies, its analysis records, its saved credentials, and its link to every System that used it. There is no per-System "detach source" button; removing a repository from a System is done by deleting the repository from the Repositories list.

Multi-repository Systems

A single System can be built from several repositories so that related code held in separate repos is understood as one connected whole. When multi-repository support is enabled, the New System dialog lets you choose repositories (plural), and the System page shows a Sources list you can add to.

Cross-repository linking

After every source has been processed, Nomain re-matches references that span repositories, so items defined in one repo connect to the code that uses them in another within the same System. For example, a CICS file definition in one repository links up to the programs and datasets that reference it in another. Job steps, file definitions and the programs they call resolve across the whole System, not just within a single repo.

Availability

Multi-repository Systems are governed by a feature setting. Where it is not enabled, a System is built from a single repository and the Sources list is hidden. Adding a source and editing a source's path filter are administrator actions.

Path filters

By default, Nomain analyzes the whole repository. A path filter lets you narrow what gets analyzed in a given source. Each filter has:

• A mode: Include (analyze only matching paths) or Exclude (skip matching paths).
• Patterns: gitignore-style patterns, one per line (for example /src or *.cbl).

Leave the filter as "No filter (whole repository)" to analyze everything. Blank lines and # comment lines in the patterns are ignored, and an empty include list is treated as "analyze the whole tree" rather than "analyze nothing".

You set a path filter when adding a source, and you can change or clear it later from the Sources section on the System page (the sliders button next to a source). Changing a filter does not re-run analysis by itself; the new filter takes effect on the next code pull.

Secret scanning

Alongside the path filter, each source has a secret scanning toggle, set in the same New System, add source, and edit source dialogs. It is off by default, and turning it on is an administrator action, because scanning rewrites the stored copy of your code.

When enabled, on each analysis Nomain scans the downloaded code for committed secrets (API keys, tokens, credentials) and masks every finding in place: the secret is replaced with ***MASKED:<ruleId>*** before anything downstream reads it. Because masking happens on the stored copy before parsing, the secret never reaches the analyzed code, the graph nodes, the explanations, or the embeddings. Findings are surfaced in the analysis Job Log as rule: file:line, never the secret value itself. The detection rules pair industry-standard patterns with mainframe-aware ones, covering hardcoded passwords and credential literals in COBOL, PL/I and assembler sources, embedded SQL connection credentials, and CICS sign-on passwords.

Masking rewrites your stored code

Enabling secret scanning is deliberate: it modifies Nomain's stored copy of the source (line count and line endings are preserved, only the secret span changes). It does not alter your original repository. As with credentials, the goal is that no secret ever persists inside the System (see the vault note above).

What Nomain reads

Nomain parses a broad range of mainframe and modern source types. See the full list under Supported languages & sources. In short, it covers COBOL, PL/I, JCL, copybooks, CICS/BMS maps and CSD, DB2/DDL, and batch scheduler definitions (such as Control-M), plus modern application code in C#/.NET and JavaScript/TypeScript.

Uploading documents instead of code

You can also add functional documentation (Markdown, PDF, Word) to a System without going through a code repository. That is handled separately by Document management, not by the Repositories list.