Auto-pin flow¶

After the build workflow pushes a new rig-agent-runtime image, the HelmRelease manifests in dashecorp/rig-gitops need to point at the new SHA tag. This doc describes the current flow (post-#393, 2026-05-15).

Why the flow changed¶

A previous version of this pipeline labeled the chore-pin issue with agent-ready, which routed it to Dev-E via rig-conductor's IssueScanService. Dev-E (a rig agent) then opened the rig-gitops PR.

This violated the operator-set HARD RULE that rig agents (dev-e-*, review-e, iBuild-E, planner) must not pick up issues in rig-internal repos. See feedback_rig_no_self_work_hard_rule.md.

rar#393 (2026-05-15) dropped the agent-ready label. The chore issue is now bare — IssueScanService leaves it alone. The orchestrator triggers the rig-gitops pin workflow directly.

Current pipeline¶

rig-agent-runtime/main merge
  → build.yml builds + pushes :{node|dotnet|python}-sha-<SHA> tags
  → request-pin job files a BARE chore issue (no labels)
        title: "chore(deploy): pin rig-agent-runtime image to sha-<SHA>"
        body:  exact one-liner the orchestrator needs to run

  → orchestrator runs (manually, from #tasks Discord notification):
        gh workflow run pin-rig-agent-runtime.yml \
          -f sha_tag=sha-<SHA> \
          -R dashecorp/rig-gitops

  → rig-gitops/pin-rig-agent-runtime.yml:
        - branch: chore/pin-rig-agent-runtime-<short-sha>
        - sed -i all 10 HelmRelease YAMLs
        - opens PR as github-actions[bot]

  → Review-E reviews the bot-authored PR (codex), auto-merges

  → Flux reconciles, pods roll to new image SHA

  → chore issue auto-closes (cross-repo `Closes` ref in PR body)

Step	Actor	Auth	Cross-repo?
1. Push image	`build.yml`	`GITHUB_TOKEN` (`packages: write`)	no
2. Open bare chore issue	`build.yml`	`GITHUB_TOKEN` (`issues: write`)	no
3. Trigger pin workflow	orchestrator (claude-3)	personal `gh` auth	yes
4. Open chore-pin PR in rig-gitops	`github-actions[bot]`	default `GITHUB_TOKEN`	no
5. Review + auto-merge	Review-E (codex)	`review-e-bot` App install	yes
6. Reconcile manifests	Flux	cluster	yes

No long-lived cross-repo PAT in any image-producing repo. Dev-E is not involved.

Why this is HARD RULE compliant¶

The bare chore issue has no agent-ready (or any) label → IssueScanService takes no action.
The orchestrator (claude-3, a human-loop interactive agent) triggers the pin workflow. Not an autonomous rig agent.
The pin workflow itself is a deterministic sed-based YAML edit — no LLM involved in producing the PR contents.
Review-E still reviews the resulting PR. This is allowed because the rule is about autonomous claim of rig-internal issues (agent-ready → IssueScanService → Dev-E), not about Review-E acting on pull_request.opened events for bot-authored PRs.

Issue contract¶

The build workflow opens an issue with this shape:

Field	Value
Title	`chore(deploy): pin rig-agent-runtime image to sha-<SHA>`
Labels	(none)
Body — SHA tag	`sha-<SHA>`
Body — Stacks	`node, dotnet, python`
Body — Target HelmReleases	full paths in `dashecorp/rig-gitops` (see below)
Body — Orchestrator action	exact `gh workflow run` one-liner

Target HelmReleases (10 files):

Path in `dashecorp/rig-gitops`	Stack
`apps/dev-e/rig-agent-helmrelease.yaml`	node
`apps/dev-e/dotnet-helmrelease.yaml`	dotnet
`apps/dev-e/python-helmrelease.yaml`	python
`apps/dev-e/rig-agent-helmrelease-codex.yaml`	node (codex)
`apps/dev-e/dotnet-helmrelease-codex.yaml`	dotnet (codex)
`apps/dev-e/python-helmrelease-codex.yaml`	python (codex)
`apps/review-e/rig-agent-helmrelease.yaml`	node (review-e)
`apps/review-e/rig-agent-helmrelease-codex.yaml`	node (codex, review-e)
`apps/rig-planner/rig-agent-helmrelease.yaml`	node (rig-planner)
`apps/rig-planner/rig-agent-helmrelease-codex.yaml`	node (codex, rig-planner)

Adding a new agent namespace. Any new namespace running the rig-agent-runtime image MUST be added to: - the issue-body list in build.yml - the HelmRelease file list in pin-rig-agent-runtime.yml (in rig-gitops) - this table

Forgetting any of the three strands the new pod on the previous SHA on every subsequent rar push.

Historical note: workflow_dispatch registry staleness¶

Between #435 (2026-05-14, removed dummy push trigger) and the rename in dashecorp/rig-gitops#452 (2026-05-15), gh workflow run pin-agent-runtime.yml returned HTTP 422: Workflow does not have 'workflow_dispatch' trigger even though the trigger was present. GitHub's workflow registry had cached the old trigger set and a comment-only touch (#451) did not refresh it.

Fix: the workflow file was renamed pin-agent-runtime.yml → pin-rig-agent-runtime.yml. Rename forces a fresh workflow_id and clean trigger parse. If this symptom recurs after a future trigger change, rename again.

During the broken window (2026-05-15 ~06:00–08:30 UTC), orchestrator opened the pin PR manually (checkout rig-gitops, sed, gh pr create, admin-merge). The manual workaround is documented in dashecorp/rig-gitops/docs/sha-pin-agent-runtime.md.

Phase 2 — fully autonomous (tracked rar#391)¶

The orchestrator manual step can be eliminated by giving build.yml cross-repo dispatch authority. Options:

A. Provision RIG_BOT_PAT as a secret in rig-agent-runtime (already exists in rig-conductor). Workflow uses it to gh workflow run or repository_dispatch into rig-gitops.
B. Add dev-e-bot GitHub App private key as a secret, mint short-lived tokens via actions/create-github-app-token@v1. Cleaner security, more setup.

Either option keeps HARD RULE compliance because the dispatch goes directly to the workflow — Dev-E (the agent) is never involved.