ci(release): prepare v0.38.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.

[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 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]

See the review comment for full details.

[fullsend-ai-review]

[low] edge-case

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 but the PR's core improvement would not take effect.

Suggested fix: 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.