Verification

The code and its tests define ObjectStoreViewer's behavior. The Makefile groups those tests and structural checks by the environment they need; it does not maintain separate slice, milestone, or acceptance-ID taxonomies.

Local checks

Target	What it runs
make build	build bin/objectstoreviewer
make test	hermetic unit tests in both Go modules
make test-race	the complete unit suite under the race detector
make test-stress	repeated publication, channel, runtime, and probe lifecycle tests under the race detector
make check-api	the API module's zero-dependency boundary and generated-artifact drift check
make lint	gofmt, vet, license boilerplate, read-only source/policy scan, read-store surface check, golangci-lint, and gosec
make vuln	pinned govulncheck v1.6.0
make check	every non-Docker check above
make docs	documentation type checking, broken-link checking, and production build

make check is the normal completion gate for a code change. Run the narrowest affected package tests while developing, then run make check before handoff.

Docker and resource checks

Target	What it runs
make test-barman-fixtures	regenerates the committed metadata with pinned Barman 3.19.1 and requires byte-identical output
make test-s3 / test-azure / test-gcs	runs one pinned provider-emulator journey
make test-provider-parity	runs the shared journey over pinned MinIO, Azurite, and fake-gcs-server environments and compares byte-identical normalized output
make test-integration	the Barman fixture and provider-parity checks together
make test-scale	the million-object bounded-memory scan plus the cached-render benchmark
make test-container	standalone and sidecar images under restricted ordinary/OpenShift-style profiles
make test-multiarch	amd64 and arm64 image builds and restricted-runtime smoke tests
make supply-chain	SPDX SBOM, image digest, license report, and high/critical vulnerability result
make release-check	local checks, docs, integration, scale, container, packaging, multi-architecture, and supply-chain checks

Docker and network access to the pinned images are required for integration, container, multi-architecture, and supply-chain work. Local arm64 emulation also needs privileged binfmt setup. Release binaries are written to dist/, while retained image and supply-chain output is written to artifacts/release/. Ordinary CI logs are already tied to the exact commit by the CI system and are not copied into a second checksummed log bundle.

Required semantic cases

The semantic suites include at least: successful, in-progress, failed, missing, malformed, and unsupported catalog outcomes; missing expected artifacts or dependencies and duplicate objects; supported and unknown compressed classifications; partial WALs, malformed names, one missing segment, and a large missing range; a non-default WAL segment size; a valid timeline switch, missing history, malformed history, and a cycle; an object appearing between scan pages; retention deletion during a scan; provider pagination failure and maximum-object truncation; and a stale previous snapshot after a failed refresh.

Barman cases additionally cover completed, STARTED, FAILED, missing, and malformed per-backup backup.info; missing main data or tablespaces; supported split and compression variants; timeline history; and supported backup types.

Incomplete, stale, unsupported, truncated, or failed evidence must remain unknown. A first complete gap observation is only a candidate; an incomplete refresh neither confirms nor clears it; the next complete observation confirms it; and a filled range clears it. These assertions live in the package tests, where new behavior must add its pathological cases.

CI

Every pull request runs build/unit/race/stress/API checks, lint and static analysis, vulnerability scanning, documentation, Barman/provider integration, the bounded-resource suite, and both restricted container profiles. A push to main additionally builds release binaries, checks amd64 and arm64 images, and retains the SBOM, image digest, license report, and vulnerability result.