An Autonomous PR-to-Deploy Loop: CI Gate, Dual Approval, Auto-Merge, Versioned Deploy

An Autonomous PR-to-Deploy Loop#

The goal: a contributor (human or agent) opens a PR; if it passes CI and gets the required approvals, it merges and deploys itself with no human clicking buttons. The loop:

PR → CI gate (required status) → N approvals → auto-merge → auto-tag → build image:<tag> → deploy (pin tag)

This is buildable on plain Jenkins/Gitea/Kubernetes (or GitHub/Actions/Argo equivalents). The pieces are independent; wire them in order.

Closed-Loop DONE for Autonomous Agent CI/CD: Why 'PR Opened' Is Not Shipped

A backlog item flips to status='completed' in the database. The dashboard ticks up. The agent posts “PR ready for review” and walks away. Three hours later, a different agent notices the fleet is running yesterday’s binary. The PR was never reviewed. CI was red on main. No image got built. Nothing actually shipped.

This is the closed-loop problem. When an autonomous agent declares work complete, what does “complete” mean? In most agent fleets, it means the agent called the last tool in its own workflow — typically open_pr or its equivalent. That is not the same as “the change is live for users”, and the gap between the two is where state-of-record systematically lies.

Gitea Collaborator Grants and Review Officiality

A pull request has two state: APPROVED reviews from different reviewers. Branch protection requires required_approvals: 1. The merge attempt returns HTTP 405 — "Does not have enough approvals". The protection config looks correct, the reviews look correct, and the error message looks misleading. The actual root cause is hidden in a field most operators never check: official.

What official means#

Every Gitea review carries an official boolean. Branch protection’s required_approvals counts only reviews where official: true. A reviewer’s APPROVE only flips to official: true if they were a write-level repository collaborator at the moment the review was filed.

Self-hosting Gitea on Kubernetes: Identities, Protection, Webhooks, Backup

A self-hosted Gitea forge running on Kubernetes covers four operational concerns that the upstream chart leaves to the operator: identity hygiene for bots and humans, branch protection rendered from code rather than clickops, webhook wiring to CI, and a backup story that survives a cluster wipe. The companion article Gitea Collaborator Grants and Review Officiality covers the narrow operational gotcha of official=false reviews; this article is the broader runbook for running the forge well.