[rossirpaulo]

What changed

• create an immutable baml-language-source-<sha> tag after canary CI succeeds
• dispatch the production release workflow from that tag instead of mutable canary
• attest that the workflow event SHA, requested source_sha, and checked-out SHA are identical
• reuse the same immutable workflow ref for the follow-on nightly release
• add release-pipeline contract coverage for the dispatch and attestation invariants

Why

A delayed CI run could dispatch release-baml-language.yml from the latest canary workflow while checking out an older source_sha. That combined pipeline instructions from one commit with product files from another. The observed failure loaded the new CFFI export-allowlist path from the newer workflow against an older checkout where that path did not exist.

Release stamping already freezes package metadata and product source, but GitHub chooses the workflow YAML before checkout and stamping. This change pins that missing workflow identity.

Validation

• python3 -m unittest discover -s scripts/tests -p 'test_*.py' -v (25 tests)
• pre-commit hooks, including YAML validation
• actionlint .github/workflows/release-baml-language.yml
• git diff --check

The existing release GitHub environment also needs the baml-language-source-* deployment-tag policy before merge; no new environment is introduced and boundary-tools-prod requires no change.

Summary by CodeRabbit

• Release Process

  • Release workflows now use immutable source tags, ensuring production and nightly releases are built from the exact intended commit.
  • Added validation to confirm release metadata and source references match before publishing.
  • Improved handling of concurrent release reruns.

• Tests

  • Expanded automated checks to verify immutable release references, permissions, and workflow attestation requirements.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
beps	Ready	Preview, Comment	Jul 24, 2026 8:24pm
promptfiddle	Ready	Preview, Comment	Jul 24, 2026 8:24pm
promptfiddle2	Ready	Preview, Comment	Jul 24, 2026 8:24pm

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 31f45c29-8488-4e99-9b91-a2aafe09579a

📥 Commits

Reviewing files that changed from the base of the PR and between ddb3e60 and a5a923e.

📒 Files selected for processing (3)

• .github/workflows/ci.yaml
• .github/workflows/release-baml-language.yml
• scripts/tests/test_release_pipeline_contract.py

---

📝 Walkthrough

Walkthrough

The release pipeline now creates immutable source tags, dispatches workflows from those tags, validates workflow attestation metadata, pins nightly releases to the triggering ref, and adds contract tests for the updated behavior.

Changes

Immutable release pipeline

Layer / File(s)	Summary
Create and dispatch from immutable source tags .github/workflows/ci.yaml	The canary release job creates or reuses baml-language-source-$GITHUB_SHA, verifies its target commit, and dispatches the release workflow using that tag.
Validate source metadata and propagate workflow refs .github/workflows/release-baml-language.yml	Production attestation checks the workflow SHA and tag metadata, while nightly dispatches reuse the triggering immutable ref.
Assert immutable dispatch contracts scripts/tests/test_release_pipeline_contract.py	Contract tests verify tag creation parameters, attestation checks, and the absence of moving canary refs.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant CanaryCI
  participant GitHubAPI
  participant ReleaseWorkflow
  participant Attestation
  CanaryCI->>GitHubAPI: Create or reuse immutable source tag
  GitHubAPI-->>CanaryCI: Return validated commit target
  CanaryCI->>ReleaseWorkflow: Dispatch using immutable tag ref
  ReleaseWorkflow->>Attestation: Provide workflow SHA and tag metadata
  Attestation-->>ReleaseWorkflow: Accept or reject source match
  ReleaseWorkflow->>GitHubAPI: Dispatch nightly workflow using source ref

Loading

Possibly related PRs

• BoundaryML/baml#4124: Introduced the CI-to-release workflow pipeline extended by these immutable ref changes.
• BoundaryML/baml#4174: Updates related release workflow attestation and dispatch contracts.
• BoundaryML/baml#3674: Modifies related downstream release workflow dispatch behavior.

Suggested reviewers: hellovai, codeshaunted

Poem

I tagged the commit with a rabbit-bright seal,
Pinned every workflow to keep it real.
No drifting canary, no ref left loose,
Attestation checks guard the source we use.
Hop, hop—nightly releases follow the trail!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly captures the main change: pinning the release workflow to the source commit instead of the mutable canary ref.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch agent/pin-release-workflow-source

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

⏭️ Performance benchmarks were skipped

Perf benchmarks (CodSpeed) are opt-in on pull requests — they no longer run on every push. They always run automatically after merge to canary/main.

To run them on this PR, do any of the following, then push a commit (or re-run CI):

• Add RUN_CODSPEED=1 to the PR description, or
• Include run-perf or /perf in the PR title or any commit message.

[github-actions]

Binary size checks passed

✅ 7 passed

	Artifact	Platform	File	Gzip	Gated on	Baseline	Delta	Status
✅	baml-cli	Linux	🔒 27.1 MB	11.5 MB	file	27.1 MB	+29.9 KB (+0.1%)	OK
✅	packed-program	Linux	🔒 17.4 MB	7.2 MB	file	17.4 MB	+12.3 KB (+0.1%)	OK
✅	baml-cli	macOS	🔒 21.1 MB	10.1 MB	file	21.0 MB	+33.2 KB (+0.2%)	OK
✅	packed-program	macOS	🔒 13.6 MB	6.3 MB	file	13.6 MB	+32 B (+0.0%)	OK
✅	baml-cli	Windows	🔒 22.7 MB	10.3 MB	file	22.7 MB	+23.0 KB (+0.1%)	OK
✅	packed-program	Windows	🔒 14.5 MB	6.4 MB	file	14.5 MB	+9.2 KB (+0.1%)	OK
✅	bridge_wasm	WASM	16.4 MB	🔒 4.5 MB	gzip	4.5 MB	+4.2 KB (+0.1%)	OK

🔒 = the size this artifact is GATED on (ceiling + delta). Binaries gate on file size (installed binary); WASM gates on gzip (download size). The other size is shown for information only.

---

Generated by cargo size-gate · workflow run