Documentation
¶
Overview ¶
Package cmd is the Plumber command line: the cobra commands (analyze, config, explain, catalog, version), the provider dispatch between the GitLab and GitHub analysis paths, terminal rendering, and every output writer (results JSON, SARIF, GitLab SAST, OCSF, CSV, PBOM) plus the platform push. It orchestrates; the analysis itself lives in control.
Index ¶
Constants ¶
This section is empty.
Variables ¶
var ( Version = "dev" Commit = "none" BuildDate = "unknown" )
Functions ¶
Types ¶
type ComplianceError ¶ added in v0.1.65
ComplianceError is returned when the deprecated --threshold gate is active and the measured percentage of passing controls falls below it. It maps to the same exit code 1 as ScoreGateError and disappears with --threshold.
func (*ComplianceError) Error ¶ added in v0.1.65
func (e *ComplianceError) Error() string
type DegradedError ¶ added in v0.3.51
type DegradedError struct {
Count int
}
DegradedError is returned when --fail-warnings is set and the run produced one or more "could not verify" warnings — e.g. a known-CVE check skipped because an action's pinned commit could not be resolved to a version (tag list blocked by an org IP allow list, rate limit, or network). The run itself completed; some data could not be checked. It maps to exit code 3 (runtime / data condition), distinct from a gate failure (1) and a configuration error (2), so strict CI can tell "we could not fully verify" apart from "a real control failed".
func (*DegradedError) Error ¶ added in v0.3.51
func (e *DegradedError) Error() string
type IncompleteDataError ¶ added in v0.3.57
type IncompleteDataError struct {
Reasons []string
}
IncompleteDataError is returned when a run is data-collection-degraded: a GitLab merged-CI fetch failed, or some GitHub workflow files / the branch-protection fetch could not be retrieved. The analysis ran on partial data, so Plumber withholds the verdict — the score banner in the terminal, badge/MR updates — and fails the run rather than pass an incomplete scan. Artifacts are still written but stamped degraded (#220). Maps to exit code 3, the same "could not fully verify" lane as DegradedError, distinct from a real gate failure (1) and a configuration error (2).
func (*IncompleteDataError) Error ¶ added in v0.3.57
func (e *IncompleteDataError) Error() string
type PlatformGateError ¶ added in v0.4.38
type PlatformGateError struct {
Reason string
Policies []platformGatePolicy
}
PlatformGateError reports that the platform's post-push gate evaluation blocked this run: one or more policies has live-monitoring failures the operator configured as blocking. It is a verdict on the project, exactly like ScoreGateError, not a program error - classifyExecError maps it to the same exit code (1). Policies is already filtered to the blocking subset of gate.policies.
func (*PlatformGateError) Error ¶ added in v0.4.38
func (e *PlatformGateError) Error() string
type PlatformTokenError ¶ added in v0.4.37
type PlatformTokenError struct{ Reason string }
PlatformTokenError reports that the run could not obtain the CI OIDC id-token the platform push requires. It is the ONLY platform-push condition that fails a run: the grant is missing from the pipeline's own configuration, the user can fix it, and a silently skipped push would hide that from them. Everything remote — unreachable, 4xx, 5xx, oversized — is a warning.
func (*PlatformTokenError) Error ¶ added in v0.4.37
func (e *PlatformTokenError) Error() string
type ScoreGateError ¶ added in v0.4.0
type ScoreGateError struct {
Points float64
MinPoints float64
// PointsGate reports whether the points gate was the one that failed;
// otherwise the letter gate did.
PointsGate bool
Letter string
MinLetter string
// NoControls marks a run where zero controls were evaluated: a
// .plumber.yaml that only configures the other provider, all controls
// disabled, a skip-all filter, or — on GitLab, whose compliance zeroes
// the control count on a missing/invalid CI — a project with no usable
// CI configuration. Zero findings then means "nothing was checked",
// not "clean", so the gate fails. On GitHub, a repository with no (or
// unparseable) workflows keeps its control count and passes on a clean
// score — the pre-0.4.0 behavior, restored on purpose so fleet
// scanners don't fail on CI-less repositories.
NoControls bool
}
ScoreGateError is returned when analysis completes successfully but the Plumber Score falls below the configured gate (--min-points and/or --min-score).
It is distinct from a generic runtime error so that callers (e.g. Execute) can map it to a dedicated exit code:
0 – analysis passed (score gate met) 1 – gate failure (score below --min-points / --min-score) 2 – runtime / configuration error
func (*ScoreGateError) Error ¶ added in v0.4.0
func (e *ScoreGateError) Error() string
Source Files
¶
- analyze_github.go
- analyze_gitlab.go
- analyze_shared.go
- artifact_provenance.go
- catalog.go
- config.go
- config_explain.go
- config_migrate.go
- config_resolve.go
- config_slim.go
- csv.go
- doc.go
- errors.go
- explain.go
- glsast.go
- init.go
- legacy_json.go
- legacy_json_github.go
- location_link.go
- ocsf.go
- platform_eval.go
- platform_gate.go
- platform_mode.go
- platform_notices.go
- platform_outputs.go
- platform_provenance.go
- platform_push.go
- platform_render.go
- platform_results.go
- render_details.go
- root.go
- sarif.go
- score_push.go
- spinner.go
- styles.go
- update_check.go
- version.go