Skip to Content
OperationsRelease Gate

Release Gate

Use the release gate before treating an OSS core change as operationally ready.

The individual unit, integration, DB-selection, and make targets are documented once in Test Commands. This page covers only the release gate itself and its acceptance criteria.

Release Gate Command

make test-it-release-gate

This gate verifies:

  • unit tests
  • PostgreSQL integration tests 3 consecutive times
  • PostgreSQL DB interruption stability 5 consecutive times
  • all-DB smoke path
  • MySQL special-character credential connection
  • SQL Server require / verify-full TLS against a TLS-enabled real database, including wrong CA and hostname rejection
  • Docker image operational tests
  • Docker Compose env-file operational tests
  • test/subtest skip count is zero in required mode (go test -json package records with no Test field are not test skips)
  • testcontainers residue is zero

GitHub Actions

Every push and pull request runs go test ./... and go vet ./....

Pull requests targeting main and pushes to main also run these checks:

CheckScope
release-gate / integration-linuxRuns make test-it-release-gate once on Linux
service-lifecycle / linux-systemdInstalls, starts, inspects, stops, and removes the agent with systemd
service-lifecycle / macos-launchdRuns the same lifecycle with launchd
service-lifecycle / windows-serviceRuns the same lifecycle with Windows Service

The three service checks use the native OS managers and a real PostgreSQL instance. They cover service registration and process lifecycle only; the general unit, integration, all-database, and Docker suites remain in integration-linux.

Requirements

Release gate commands require a Go toolchain compatible with the version declared in go.mod. CI reads go.mod as the Go version source of truth.

Container-backed tests require Docker daemon access. To make container availability mandatory, use:

ONPREST_IT_REQUIRE_CONTAINERS=1

If Docker is unavailable and mandatory mode is not enabled, container-backed tests may skip. Required release gates should run with no skipped integration or operational cases.

Acceptance Criteria

A release candidate should pass integration-linux and all three native service checks, and preserve the architecture boundaries:

  • two deployable binaries: onprest-gateway and onprest-agent
  • no gateway SQL construction
  • no gateway DB credentials
  • no Caddy-specific implementation dependency
  • direct and reverse-proxy deployment both remain valid
  • error detail redaction remains intact
Capability ChangesTroubleshooting