CI Inventory Standards

The old Trac ContinuousIntegration page is a useful warning: a build-badge dashboard combines live service URLs, branch names, CI job names, dependency versions, and human-readable host notes. That kind of table becomes stale quickly if it is edited as prose.

Keep durable testing guidance in this repository, but treat live badge matrices as generated or checkable inventory. A maintained CI inventory should follow these rules.

Source of Truth

Do not duplicate CI behavior by hand. Point each inventory entry at the file or service that owns the behavior:

CI surface	Source of truth
Linux Docker matrix on GitHub Actions	`.github/workflows/ci.yml` plus `ci/github/run_*.sh`
FreeBSD GitHub Actions job	`.github/workflows/ci-freebsd.yml`; see FreeBSD development environment
macOS GitHub Actions job	`.github/workflows/ci-macos.yml`; see macOS development environment
MSYS2/MinGW GitHub Actions job	`.github/workflows/msys.yml`
GitHub CodeQL, codespell, and contributor-credit jobs	`.github/workflows/codeql.yml`, `.github/workflows/codespell.yml`, and `.github/workflows/contributor-credits.yml`
Debbie build, docs, and release jobs	`ci/debbie/`, the Debbie Jenkins jobs, and release-process notes
Winnie Windows jobs	`ci/winnie/` and the Winnie Jenkins jobs
Bessie and Berrie/Berrie64 jobs	`ci/bessie/`, `ci/berrie*`, and the corresponding Jenkins worker labels
Docker build images used by GitHub Actions	`postgis/postgis-build-env` image tags referenced from `.github/workflows/ci.yml`

When a dashboard row describes dependency versions, operating systems, branch coverage, or test modes, the row should be regenerated from those sources or checked against them before publication.

Badge Inventory Rules

For every badge entry, record enough metadata for another maintainer to verify it without guessing:

service name and canonical job or workflow URL;
badge image URL, if the dashboard renders one;
branch or release line covered by the badge;
source file, script, or external job configuration that owns the job;
test mode covered, such as standard tests, coverage, garden, upgrade, dump/restore, sanitizer, docs, or release distribution build;
expected platform and dependency family, when that information is not already obvious from the owning workflow or image tag.

Avoid free-form dependency summaries when the source is an image tag, package manager command, Jenkins job, or workflow matrix. Prefer linking to the source or generating the summary. If a summary is kept for readability, it needs the same check path as the badge URL.

Updating The Inventory

Update the inventory when any of these change:

a workflow file under .github/workflows/;
a script under ci/;
a postgis/postgis-build-env tag used by the GitHub Actions matrix;
a Jenkins job, worker label, or badge URL referenced from Trac or website dashboards;
a supported release branch or support-window row that affects which branches should have badges.

Use utils/ci-trac-line.sh when maintaining the Trac badge table or a copied badge inventory. Fetch or export the current Trac table into a temporary file before using --check or --replace:

utils/ci-trac-line.sh 3.7
utils/ci-trac-line.sh --check /tmp/ContinuousIntegration.tracwiki 3.7
utils/ci-trac-line.sh --replace /tmp/ContinuousIntegration.tracwiki 3.7

The helper prints the expected row for a stable release branch, verifies that a file already contains the generated row, or replaces an existing row for that release line. It checks row shape, branch names, and badge URLs generated by the helper. It does not prove that external Jenkins, GitHub Actions, GitLab, or Woodie services are currently green; release work still needs a live service readback.

Relationship To Other Docs

Use Testing and debugging for test commands and local validation workflows. Use Release process for release-manager greenlight checks, Debbie release jobs, and branch-opening steps. Use Website maintenance and the public website compatibility matrix for user-facing support status.