## What changed
Remove the `repo-checks` steps that staged a Codex npm package from a fixed
release workflow and uploaded the resulting tarball as an artifact.
GitOrigin-RevId: bb3756188eeea2ed236710273234e70f17dc9e9d
## 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
Keep the App Store Connect private key in Azure Key Vault instead of exporting it to release runners as a base64-encoded `.p8` secret.
## What changed
- Add a notarization client that creates notary-scoped Apple JWTs with a pinned Azure Key Vault key, submits and streams artifacts to Apple's notarization service, polls for completion, and saves developer diagnostics.
- Update the binary and DMG release wrappers to use the new client while continuing to staple accepted DMGs with `rcodesign`.
- Configure release jobs with the notarization vault key name and version instead of private-key material.
## Testing
- Add unit coverage for key validation, JWT signing, uploads, polling, diagnostic logs, and the binary and DMG wrapper contracts.
GitOrigin-RevId: 8f526c5691d774964fd33f847f8420cac0840b05
## Why
CI jobs repeat common bootstrap steps, which makes it harder to keep
Bazel and Cargo lanes aligned. Centralizing the lightweight setup gives
us one place for future runner-wide optimizations without adding Rust
toolchain or component installation to the Windows Bazel long poles.
## What
- add zero-input `.github/actions/setup-ci` to set Cargo's git
transport, install DotSlash and `just`, expose DotSlash from stable PATH
locations, and enable Windows Git long paths
- have `setup-bazel-ci` compose the common setup, then remove its
DotSlash/test-prerequisite plumbing
- migrate Bazel, Cargo CI, V8 canary, repo checks, nextest, and Windows
release call sites while keeping Rust toolchain and MSVC setup explicit
- preserve the existing nextest Dev Drive setup unchanged
## Validation
- `just test-github-scripts` (30 tests)
- parsed workflow and composite-action YAML with `yq`
## Why
The standalone installers currently perform separate unauthenticated
GitHub REST API lookups while resolving the latest version, locating the
platform package, locating its checksum manifest, and retrieving asset
digests. A single install can therefore make up to four release-metadata
requests.
When GitHub's shared unauthenticated rate limit is exhausted, valid
releases fail to install. The shell installer also suppresses the
metadata request failure while probing assets, so a `403` is misreported
as though the release assets do not exist. This makes the failure both
more likely and harder to diagnose.
Fixes#28538.
## What changed
- Resolve the selected version and fetch its release metadata together.
- Reuse that one metadata response for package, checksum, and
legacy-package selection in both `install.sh` and `install.ps1`.
- Report metadata fetch failures as possible GitHub availability or
rate-limit failures instead of missing assets.
- Add a mocked-`curl` regression suite covering exact releases,
`latest`, and a simulated metadata `403`, and run it in `repo-checks`.
For `latest`, the metadata returned by `/releases/latest` now supplies
both the resolved version and the asset list. For an explicitly selected
version, the installer makes one request to that release's tag endpoint.
## Verification
- `python3 -m unittest discover -s scripts/install -p 'test_*.py' -v`
- `sh -n scripts/install/install.sh`
- Parsed `scripts/install/install.ps1` with the PowerShell language
parser.
## Scope
This change reduces GitHub API usage and preserves the underlying error,
but it does not move release artifacts away from GitHub's CDN.
## 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.
