Automating Releases

Manually tagging services is error-prone, so we hand that job to googleapis/release-please-action. The configuration lives under .github/utils/:

• release-please-config.json enumerates each package path, component name, and release type (Node, Go, Python). The linked-versions plugin keeps the Go API and its migrator in sync.
• release-please-manifest.json tracks the last published version per service.

Release Please reads conventional commit messages (feat:, fix:, chore:, revert:) to determine semantic version bumps, opens aggregate release PRs, and—once merged—cuts git tags that in turn trigger the build/push and GitOps workflows. Using a personal access token bypasses GitHub’s “workflows don’t trigger other workflows” limitation.

Auxiliary Workflows

Two lightweight workflows round out the automation suite:

• Stale issue/PR management: actions/stale runs nightly (or on demand), labels items after a period of inactivity, and closes them a week later if no one responds. Tweaking days-before-stale/days-before-close keeps the backlog manageable.
• Workflow telemetry: corentinmusard/otel-cicd-action exports timing data whenever the test or build workflows finish. Honeycomb dashboards can then visualize duration trends, identify bottlenecks, and alert when jobs regress.