Skip to Content
OperationsRelease Gate

Release Gate

Maintainers use the release gate before treating an OSS core change as operationally ready. Users install published releases without Go or the source repository; see Install from a release.

Release Gate Command

make test-it-release-gate

This gate verifies:

  • Go vulnerability analysis reports zero reachable known vulnerabilities for ./...
  • unit tests
  • PostgreSQL integration tests 3 consecutive times
  • public schema validation: the unit and PostgreSQL integration tests check real values against the published OpenAPI and MCP schemas
  • PostgreSQL DB interruption stability 5 consecutive times
  • all-DB conformance: every TestContainerDBDriver* case, including Oracle immediate transaction start/cancel, PostgreSQL nullable Agent response/OpenAPI 3.1 validation, and PostgreSQL timestamp JSON/timezone compatibility
  • MySQL special-character credential connection
  • the four-database TLS contract against real databases: disable, require, and verify-full for PostgreSQL, MySQL, SQL Server, and Oracle, plus PostgreSQL verify-ca
  • encryption observation, private/wrong CA, hostname and server_name, expiry, certificate replacement/pool recreation, reconnect without plaintext downgrade, and supported PostgreSQL/MySQL client-certificate authentication
  • Oracle TCPS through the pure-Go driver without Oracle Instant Client
  • Docker image operational tests
  • Docker Compose env-file operational tests
  • test/subtest skip count is zero in required mode
  • testcontainers residue is zero
  • when given extracted release binaries, the Quick Start runs against those binaries outside the source tree

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 / package-candidateBuilds the five OS/CPU archives and the Quick Start archive, scans the ten distributed binaries, and verifies checksums
release-gate / integration-linuxRuns make test-it-release-gate once on Linux with the binaries extracted from the Linux amd64 archive
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
release-gate / native-testsRuns the agent’s OS-dependent tests natively on Linux arm64, macOS, and Windows; a skipped test fails the check
release-gate / release-readyRequires packaging, Linux integration, the native tests, and the complete reusable service lifecycle workflow to succeed

The three service checks run the binaries from the release archives under the native OS service manager, against a real gateway and PostgreSQL.

Cross-builds do not prove native runtime compatibility. Before release, verify the exact candidate on each supported OS baseline; results from a newer OS do not establish minimum-version support.

Release Publication

A semantic version tag (vX.Y.Z) starts the release workflow. Publication requires a successful release-ready result for the exact tagged commit SHA; missing, failed, canceled, or different-SHA results block the release. The workflow rebuilds and checks the tagged assets, attaches a GitHub artifact attestation to each asset, publishes SHA256SUMS, and creates the GitHub Release. It never overwrites an existing Release.

Requirements

Release gate commands require Go 1.26.10 or later as declared in go.mod. Schema validation also needs Node.js and npm to install the pinned validator. CI reads go.mod as the Go version source of truth, and Docker builds use the same Go 1.26.10 builder image pinned by digest. The govulncheck scanner version is pinned as a Go tool dependency and is executed by the release gate.

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, the native tests, all three native service checks, and the final release-ready aggregation for the exact candidate commit, and preserve the architecture boundaries:

  • zero reachable known vulnerabilities reported by govulncheck ./...
  • two deployable binaries: onprest-gateway and onprest-agent
  • no gateway SQL construction
  • no gateway DB credentials
  • direct and reverse-proxy deployment both remain valid
  • error detail redaction remains intact
TroubleshootingOverview