## What changed
- Authenticate eligible protected `main` runs and Rust release tags with GitHub OIDC. Allow cache uploads only on `main` pushes; use read-only access for manual runs and release tags, and leave pull requests without GCS credentials.
- Rename the shared wrapper to `.github/scripts/run_bazel.py` and route Bazel callers through it. Disable the disk cache in GitHub Actions and default macOS GCS connections to 20 while respecting explicit limits.
- Gate additional Bazel release artifacts on `CODEX_BAZEL_RELEASES` and cache configuration, sharing the selected build systems across building, signing, and packaging. Keep Cargo as the default and prepare native Windows dependencies for Bazel releases.
- Add a `Bazel result` check for the full workflow and extend Bazel job timeouts.
## Testing
Add wrapper tests for cache access by event, argument preservation, and macOS connection limits. The wrapper test suite passes.
GitOrigin-RevId: d85edbd083acfaa8bafaa8fd5241daed3e9ef871
## Why
The BuildBuddy key is revoked. Temporarily keep Bazel-dependent checks from blocking CI and release only Cargo artifacts.
## What changed
- Remove Bazel from the `blocking-ci` required dependencies.
- Make the Bazel-backed argument comment lint and SDK jobs advisory, and stop requiring the lint job to succeed in the Rust CI results check.
- Restrict release build and packaging matrices to Cargo, including Windows and provisioned macOS packages, and exclude Bazel binaries and symbols from release artifact downloads.
GitOrigin-RevId: 2c0d23471bbd0ab2eb4d90d318b518d0b33db97f
## Why
Checking only the pull request head can miss conflicts with changes already on
`main`.
## What changed
Remove explicit pull request head refs from required workflow checkouts so
GitHub Actions checks out the synthetic merge commit by default. Keep the
blocking gate on the same combined revision as the child workflows it
evaluates, and document the merge-commit policy in the workflow README.
GitOrigin-RevId: dc357caa5dc43f46b9b9a0edea6ee560b4fe8efb
## Why
It's hard to change the set of required jobs when they're managed in the
GitHub UI, and when each workflow is responsible for choosing it's own
scheduling it's easy to end up with skew between what we enforce on PRs
vs. on main.
## What
- add a `blocking-ci` caller workflow, triggered by pull requests and
pushes to `main`, for Bazel, blob size, cargo-deny, Codespell,
`repo-checks`, rust CI, and SDK CI
- add an `always()` terminal job named `CI required` that fails unless
every called workflow succeeds
- add a `postmerge-ci` caller workflow for `rust-ci-full` and
`v8-canary`, with a terminal `Postmerge CI results` job
- centralize V8 relevance detection in `v8_canary_changes.py`; unrelated
PR and postmerge runs execute metadata only and skip the expensive build
matrices
- leave `v8-canary` outside the blocking gate and leave the external
`cla` check independent
## Rollout
A repository admin must replace the existing required GitHub Actions
contexts with `CI required` in the main-branch ruleset. Retain `cla` as
a separate required check. Until that change is coordinated, this PR
cannot satisfy the old standalone check names. In-flight PRs will need
to be rebased after this lands.
Dmitriy Kovalenko