Skip to content

API collection planning

Audit rules declare the GitLab data capabilities they require. After configuration selects the active rules, the orchestrator builds a minimal collection plan before making API calls.

Examples:

  • governance.pipeline-required needs only project metadata.
  • variables.masking needs only CI/CD variable metadata and does not fetch project metadata.
  • project.readme-present fetches project metadata and probes only README candidates.
  • pipelines.status-summary fetches pipeline history without inspecting failed-job metadata.
  • releases.release-notes fetches releases without fetching tags.

Project metadata is shared across project, governance, and CI collectors within a single audit, so the project endpoint is fetched at most once when those capabilities are selected.

The planner is conservative: every selected rule must have declared capabilities, otherwise audit planning fails explicitly instead of running a rule with incomplete context.

Portfolio request accounting

Large portfolio audits can share one thread-safe request controller across project clients. The controller enforces an optional hard request budget and observes GitLab rate-limit response headers. Portfolio execution uses those observations to reduce later batch concurrency under pressure.