ci(release): prepare v0.39.0 — bump agents gate pin past agents#1010, tag the gate-validated SHA

[waynesun09]

Summary

Preparation for the next release (v0.38.0). Two changes to release.yml, both maintainer-owned (workflow file):

1. Bump the agents gate pin a8566cd5 → b9c07455 (agents main). This includes agents#1010, which makes the gate check out fullsend-ai/agents at an explicit ref instead of github.workflow_sha — proven on the v0.37.0 run to be the caller's commit (not our ref). With this pin, a fullsend release can validate agents content cross-repo for the first time, and the gate exposes the validated commit as the agents_sha workflow_call output.
2. tag-agents tags the gate-validated SHA (needs.validate-agents.outputs.agents_sha), falling back to resolve-agents' release-start resolution only if the gate output is empty, and logs which source it used. Closes the resolve-once loop end to end (fullsend#6512): the tree the gate validated is the tree that gets tagged.

Also: the checks: read grant pre-granted in #6513 is now actually exercised by the gate's roll-up job; comments updated to match.

Why now

v0.38.0 carries the user-facing pi-runtime readiness (#6583 per-agent runtime/model/effort in config.yaml, #6540 local-run flow, #6523 provider-update retry) plus the #6585 SSRF fix; the agents tag it cuts will carry agents#1010, #1025 (harness images repinned to release builds, shipping the xai-vertex extension) and the risk-assessment review feature. This PR is what lets that release's gate do its job instead of taking the manual-recovery path again.

What to watch on the release run

• validate-agents / detect checkout log shows an agents ref (not the caller SHA) — first time ever
• tag-agents logs source: validate-agents and the SHA matches the gate's
• The pin-drift annotation should be quiet or near-zero (pin = agents main at PR time)
• After release: repin agents/harness/*.yaml image digests to the new :0.38.0 builds (release: automate the fullsend-ai/agents harness image digest repin after each release #6607 tracks automating this)

Validation

• YAML parses; actionlint clean (tag-triggered workflow gets no CI parse until the next tag)
• b9c07455 verified to contain agents#1010 (dd9ca90) via merge-base --is-ancestor
• Next tag push exercises it end to end

Related: fullsend#6512, agents#1001, agents#1010, #6513

[qodo-code-review]

PR Summary by Qodo

Tag agents releases at the gate-validated commit

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Pin the agents validation gate to the cross-repository checkout fix.
• Tag the gate-validated agents commit, with release-start resolution as a fallback.

Diagram

graph TD
  A["Release tag"] --> B["Release build"] --> C["Pinned agents gate"] -->|"validated SHA"| D{"Gate SHA present?"} -->|"yes"| F["Tag agents"] --> G["Agents version tag"]
  B --> E["Resolve agents main"] -->|"fallback"| D

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Require the gate output

• ➕ Guarantees every agents tag points to a gate-reported commit
• ➕ Removes fallback selection logic
• ➖ Makes releases fail if the reusable workflow omits or temporarily breaks its output
• ➖ Reduces compatibility during the gate-output rollout

2. Keep release-start resolution only

• ➕ Uses a locally controlled and deterministic SHA
• ➕ Avoids coupling tagging to reusable-workflow outputs
• ➖ Can tag a different agents tree than the gate validated
• ➖ Leaves the cross-repository validation gap unresolved

Recommendation: Keep the PR's gate-first selection with a validated release-start fallback. It preserves release resilience while ensuring the normal path tags exactly the agents tree that passed the gate; the source and divergence notices make fallback behavior observable.

Files changed (1) +19 / -16

Bug fix (1) +19 / -16

release.ymlTag the agents commit reported by the validation gate +19/-16

Tag the agents commit reported by the validation gate

• Advances the pinned agents reusable workflow to the revision containing the cross-repository checkout and 'agents_sha' output fix. The tagging job now prefers that validated SHA, falls back to the release-start resolution when absent, validates the selected value, and logs its source or any divergence.

.github/workflows/release.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can hide the parts of a finding you never read, like the evidence or the agent prompt

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 9:33 PM UTC · Completed 9:51 PM UTC

Commit: 4d43687 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $4.00

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[fullsend-ai-review]

Risk Assessment: moderate (2/5)

Details

Small, focused CI workflow change (1 file, 35 lines) to bump the agents gate pin and tag the validated SHA for v0.38.0, but elevated git history signals (release.yml has 8 recent authors and 4 fix/revert commits in 90d) temper the low metadata risk, yielding a moderate composite score; signals are unchanged from prior assessment so score is preserved at 2.

Previous run

Risk Assessment: moderate (2/5)

Details

Small, focused CI workflow change (1 file, 35 lines) to bump the agents gate pin and tag the validated SHA for v0.38.0, but elevated git history signals (release.yml has 8 recent authors and 4 fix/revert commits in 90d) temper the low metadata risk, yielding a moderate composite score.

[fullsend-ai-review]

Review

Findings

Medium

• [protected-path] .github/workflows/release.yml — This PR modifies .github/workflows/release.yml, which is under the protected path .github/. The PR links to issue release: validate-agents startup failure (caller permissions) + agents gate validates a different tree than tag-agents tags #6512 and provides clear rationale for the changes (bumping the agents gate pin past agents#1010 and wiring tag-agents to tag the gate-validated SHA). Human approval is always required for protected-path changes, regardless of context.

Low

• [edge-case] .github/workflows/release.yml:152 — The preference for the gate-validated SHA (GATE_SHA) depends on the called reusable workflow (functional-tests.yml at beed20e7...) declaring agents_sha as a workflow_call output. This cannot be verified from this repository alone. If the output declaration is missing, GATE_SHA will silently be empty and the fallback to RESOLVED_SHA will always activate — making the gate-preference logic functionally inert. The fallback is safe (tagging still works), but the PR's core improvement would not take effect. The pin update and PR title assert that agents#1010 is included, which mitigates this risk.
  Remediation: Confirm the agents workflow at beed20e7e85f7f7cf9678a78fd1f440755560ca3 declares agents_sha under on.workflow_call.outputs. Consider adding a ::warning annotation when GATE_SHA is empty to make the fallback more visible in CI logs.

• [GHA workflow command injection] .github/workflows/release.yml:158 — The ::notice:: line interpolates GATE_SHA and RESOLVED_SHA without the //::/} sanitization pattern used on the ::error:: line above it. Not exploitable in practice (both values are validated as 40-character hex strings before this line is reached), but applying consistent sanitization would be a defense-in-depth improvement.
  Remediation: Change to: echo "::notice::tagging the gate-validated SHA ${GATE_SHA//::/} (agents main was ${RESOLVED_SHA//::/} at release start)"

Previous run

Review

Findings

Medium

• [protected-path] .github/workflows/release.yml — This PR modifies .github/workflows/release.yml, which is under the protected path .github/. The PR links to issue release: validate-agents startup failure (caller permissions) + agents gate validates a different tree than tag-agents tags #6512 and provides clear rationale for the changes (bumping the agents gate pin past agents#1010 and wiring tag-agents to tag the gate-validated SHA). Human approval is always required for protected-path changes, regardless of context.

Low

• [edge-case] .github/workflows/release.yml:152 — The preference for the gate-validated SHA (GATE_SHA) depends on the called reusable workflow (functional-tests.yml at b9c07455...) declaring agents_sha as a workflow_call output. This cannot be verified from this repository. If agents#1010 did not add that output declaration, GATE_SHA will silently be empty and the fallback to RESOLVED_SHA will always activate — making the gate-preference logic functionally inert. The fallback is safe (tagging still works), but the PR's core improvement would not take effect.
  Remediation: Confirm the agents workflow at b9c0745580084af09d1f1e2df8448d1d478458c6 declares agents_sha under on.workflow_call.outputs. Consider adding a warning log when GATE_SHA is empty to make the fallback observable.

---

Labels: PR modifies .github/workflows/release.yml (CI release workflow)

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 6:43 PM UTC · Completed 7:03 PM UTC

Commit: 7523c05 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $5.00

[fullsend-ai-review]

See the review comment for full details.

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 5:35 PM UTC · Completed 5:45 PM UTC

Commit: 7523c05 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $3.07

[fullsend-ai-retro]

Retro: PR #6613 — bump agents gate pin, tag gate-validated SHA

Workflow quality: Good. This human-authored release-prep PR had a clean lifecycle: two review agent runs, one human approval, no rework, merged without issues.

Timeline

1. 2026-08-25 21:31 — Wayne Sun opens PR with commit 4d43687, bumping the agents gate pin from a8566cd5 to b9c07455 and adding gate-first SHA selection logic in tag-agents.
2. 2026-08-25 21:32–21:51 — First review agent run (19 min, ~$4). Finds: protected-path flag (medium), GATE_SHA output dependency edge case (low), ::notice:: sanitization inconsistency (low).
3. 2026-08-27 09:09 — Human reviewer rh-hemartin approves with no comments.
4. 2026-08-27 18:40 — Wayne pushes commit 7523c05, bumping the pin SHA to beed20e7 (latest agents main).
5. 2026-08-27 18:41–19:04 — Second review agent run (23 min, ~$5). Produces the same findings updated with the new pin SHA.
6. 2026-08-31 17:33 — PR merged; retro dispatched.

Review quality

The review agent's findings were all valid:

• Protected-path (medium): Correctly flagged .github/ modification requiring human approval — satisfied by rh-hemartin's review.
• GATE_SHA edge case (low): Valid observation that if the agents workflow stops declaring the agents_sha output, the fallback silently activates. The fallback is safe, so this is informational.
• Sanitization inconsistency (low): The ::notice:: line interpolates variables without ${VAR//::/} sanitization, unlike the ::error:: line. Not exploitable (values are validated as 40-char hex first) but inconsistent. This was not addressed before merge.

Evidence for existing issues

• Redundant re-review (~$5 cost): The second review run on commit 7523c05 produced the same findings as the first run on 4d43687 because the inter-commit diff only changed the pin SHA constant — no logic change. This is additional evidence for the cluster of issues about skipping or lightening re-reviews on non-semantic pushes (Skip re-review when bot dep-bump PR is rebased with no semantic change #1355, Review agent should detect rebase-only force-pushes and skip re-review when the effective diff is unchanged #4401, Review agent should avoid full re-reviews when Renovate rebases without content changes #4596, Skip redundant re-reviews when Renovate rebases a dependency PR without changing the diff #4652, Review agent re-ran on unchanged commit, wasting tokens #4022). Total review cost for this 35-line single-file diff was ~$9.
• Unresolved low-severity findings merged: The sanitization inconsistency finding was not addressed before merge. This is evidence for existing issues about surfacing unresolved finding counts (Review agent should alert when human approves with unresolved Medium+ findings #2099, Review status comment should surface unresolved finding count for human reviewers #2677) and post-merge follow-up tracking (Auto-file tracking issues for unresolved medium+ severity review findings #1956).

Autonomy readiness

The review agent's analysis fully covered what the human reviewer assessed — the human approved without inline comments, and the agent's findings were informative context about edge cases. For CI workflow changes under the requires-manual-review / component/ci policy, the review agent provides useful supplementary analysis but human sign-off remains appropriate given the release-critical nature of the file.

Proposals filed

• Review agent should flag version/identifier mismatches between PR title, branch name, and commit messages (in fullsend-ai/agents)