Skip to content
PYD ENTERPRISES

Source control · Ingest and export

PYD ENTERPRISES and GitLab

Clone self-managed GitLab projects inside your network, run PYD ENTERPRISES as a CI job on your own runners, and publish specs back as merge requests.

GitLab logo

GitLab

Source control

Ingest and export
.gitlab-ci.ymlYAML
1pyd-scan:
2 stage: analyze
3 image: registry.internal/pyd/cli:2026.11
4 tags: [protected, pyd]
5 rules:
6 - if: $CI_COMMIT_BRANCH == "main"
7 script:
8 - pyd scan --system lending --ref "$CI_COMMIT_SHA" --wait
9 - pyd diff --against baseline --fail-on new-unresolved,new-review

Self-managed GitLab is the common case

In regulated banks and insurers, GitLab is usually self-managed and sits inside the same perimeter as the mainframe build servers. That makes it a natural ingest point: PYD ENTERPRISES clones projects with a project or group access token limited to read_repository, mirrors them on its own volume and pins every scan to the commit SHA it resolved at start.

Groups map well to legacy systems. A group such as lending/ might hold the COBOL batch, the CICS online programs, the copybook library and a Java EE front end as separate projects. PYD ENTERPRISES scans them as one system so cross-project references, for example a Java connector calling a CICS program through a COMMAREA, resolve into one symbol graph instead of four disconnected ones.

Running PYD ENTERPRISES from GitLab CI

Many teams prefer to trigger scans from a pipeline rather than from the PYD ENTERPRISES console. The PYD ENTERPRISES CLI ships as a container image you load into your internal registry; a job on a self-hosted runner pulls it, points it at the PYD ENTERPRISES API inside the cluster and starts a scan of the commit that triggered the pipeline.

  • Use a protected, tagged runner that can reach the PYD ENTERPRISES service; shared SaaS runners are not appropriate for source you cannot let leave the building.
  • Store the PYD ENTERPRISES API token as a masked, protected CI variable.
  • The job exits non-zero when a scan reports new unresolved symbols or new rules flagged for review, which turns spec drift into a visible pipeline failure.

Results stay in PYD ENTERPRISES. The job log carries counts and a link to the scan in your internal console, not code.

Exports as merge requests

With export enabled, PYD ENTERPRISES commits the specification bundle (OpenAPI 3.1, DMN 1.5, JSON Schema, Mermaid diagrams and a manifest) to a dedicated specification project and opens a merge request. Approval rules and code owners on that project decide who signs off: typically a business analyst for DMN changes and an architect for OpenAPI changes. Each merge request description lists rules added, changed and retired since the previous baseline.

FAQ

GitLab questions.

Do we have to use GitLab CI to use PYD ENTERPRISES with GitLab?

No. PYD ENTERPRISES can poll or be triggered from its own console. The CI job is a convenience for teams that want spec drift to show up as a pipeline status.

Can PYD ENTERPRISES read GitLab projects that contain EBCDIC files?

Files committed as EBCDIC are read with the code page you configure per source, for example IBM-1047. Most teams convert at migration into Git, which PYD ENTERPRISES handles as UTF-8.

What access does the export token need?

Write access to the specification project only, enough to push a branch and open a merge request. It never needs access to the legacy projects.

See the GitLab 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.