Skip to content
PYD ENTERPRISES

Source control · Ingest and export

PYD ENTERPRISES and GitHub

Mirror GitHub or GitHub Enterprise Server repositories inside your VPC, scan a pinned commit, and return specifications to a review repository as pull requests.

GitHub logo

GitHub

Source control

Ingest and export
scan.yaml (GitHub source)YAML
1sources:
2 - kind: git
3 url: git@github.internal.bank:lending/loan-servicing-ejb.git
4 ref: 4f1c9e2a7b
5 auth: { secret: gh-deploy-key-lending }
6 dialect: java-ee-6
7export:
8 git:
9 url: git@github.internal.bank:specs/loan-servicing-specs.git
10 branch: scan/{scanId}
11 pullRequest: true

How PYD ENTERPRISES ingests from GitHub

Most Java EE, Struts and .NET estates already live in Git, and many banks have moved their COBOL source into GitHub Enterprise Server alongside it. PYD ENTERPRISES never asks GitHub to send code anywhere. A scan worker inside your cluster performs a mirror clone over HTTPS or SSH using a read-only deploy key or a fine-grained token scoped to the repositories you list, and keeps that mirror on a volume you control.

Every scan is pinned to a commit SHA. The SHA is written into the scan manifest and into every exported artifact, so a DMN row or an OpenAPI property can always be traced to repo@sha:path:lines, not to "whatever main looked like that week". When you rescan, PYD ENTERPRISES fetches only new objects and diffs the symbol graph against the previous SHA, which is how rule-level change reports are produced.

  • Monorepos: point a scan at sub-paths and give each one a dialect (for example java-ee-6 for /ejb, ibm-enterprise-cobol-6.4 for /cobol).
  • Submodules are resolved when the deploy key can read them; unreadable submodules are listed as unresolved inputs rather than skipped silently.
  • Git LFS pointers to binary artifacts (JARs, DLLs) are recorded but not decompiled.

How PYD ENTERPRISES exports back to GitHub

The review loop works best when specifications live next to code. PYD ENTERPRISES can commit its outputs to a separate specification repository (we recommend one per legacy system) on a branch named after the scan, and open a pull request for your architects. The bundle contains openapi/*.yaml, dmn/*.dmn, schemas/*.json, diagrams/*.mmd and a MANIFEST.json listing source SHA, parser versions and rule counts.

Because each export is a plain commit, your existing branch protection, CODEOWNERS and required reviews apply unchanged. Reviewers comment on YAML and DMN XML the same way they review code. PYD ENTERPRISES does not post comments on your legacy repository and does not need write access to it.

Air-gapped and restricted networks

If your GitHub Enterprise Server sits in the same network segment as PYD ENTERPRISES, nothing leaves that segment. If you use github.com, the only traffic is the clone and, optionally, the push to the specification repository, both initiated from your cluster through your egress proxy. Teams that keep egress fully denied export a git bundle from a jump host and drop it on the PYD ENTERPRISES ingest volume; PYD ENTERPRISES reads bundles the same way it reads a live remote.

FAQ

GitHub questions.

Does PYD ENTERPRISES need write access to our legacy repositories?

No. Ingest is read-only. Write access is only needed for the separate specification repository, and only if you enable pull request exports.

Can we scan a specific tag instead of a branch?

Yes. Any ref resolves to a commit SHA at scan start, and that SHA is what every artifact records. Tags are convenient for release baselines before a cutover.

Does it work with GitHub Enterprise Server behind our firewall?

Yes. PYD ENTERPRISES only needs network reachability to the Git endpoint from the scan workers. No GitHub app installation or webhook is required for scanning.

See the GitHub flow on your own code.

Run PYD ENTERPRISES on 100,000 lines of COBOL or Java in your private VPC and review OpenAPI specs and DMN tables tomorrow.