Release job: create the autobuild tag at the commit that was built - #461
Release job: create the autobuild tag at the commit that was built#461robobun wants to merge 1 commit into
Conversation
`gh release create` with no `--target` creates the tag at the default branch's HEAD at the time the release job runs, not at inputs.build_ref, which is what every build job checked out and what the tarballs contain. For preview releases the tag therefore never points at the PR head it is named after (autobuild-preview-pr-<n>-<sha8>), and for main releases it points at whatever landed on main during the ~35 minute build (33 of the last 186 autobuild-<sha> tags point at a commit other than <sha>). Pass `--target "$BUILD_REF"`. build.yml and build-preview.yml both pass a full commit sha as build_ref, which is one of the two forms --target takes; the input description now says so. Existing tags are left as they are.
|
Warning Review limit reached
Next review available in: 4 minutes Limit details: You’ve used all 5 included reviews currently available under your plan. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — adds --target "$BUILD_REF" to gh release create so the autobuild tag points at the built commit.
What was reviewed:
- Verified both callers (
build.yml→github.sha,build-preview.yml→pr.head.sha) pass full 40-hex SHAs, which--targetaccepts. BUILD_REFis passed viaenv:and quoted in the bash array; sourced from GitHub-controlled SHAs, so no injection surface.- The
gh release viewguard is unchanged, so re-runs of an existing release still do not move the tag.
Extended reasoning...
Overview
This PR touches a single file, .github/workflows/build-reusable.yml, and makes three changes to the release job's "Release" step: (1) updates the build_ref input description to note it must be a full SHA or branch name, (2) exposes inputs.build_ref as the BUILD_REF env var, and (3) inserts --target "$BUILD_REF" into the gh release create flags array with an explanatory comment. Nothing else about release creation or asset upload changes.
Security risks
None identified. inputs.build_ref is supplied only by the two calling workflows: build.yml passes ${{ github.sha }} and build-preview.yml passes pr.head.sha fetched via github.rest.pulls.get / the pull_request event payload — both are GitHub-generated 40-character hex strings, not attacker-controllable free text. The value is plumbed through a step env: block and referenced as "$BUILD_REF" inside a bash array element, so there is no shell-injection or expression-injection vector introduced. The step already had contents: write permission and already created releases; this change only pins target_commitish on the release-create API call.
Level of scrutiny
Low-to-moderate. This is CI release plumbing rather than runtime engine code, and the diff is a one-flag addition with a doc-string tweak. Failure modes are loud (the gh release create call would error and fail the job), not silent. I confirmed the two call sites pass values compatible with --target (full SHAs), and that a PR head commit is reachable in the repo via refs/pull/<n>/head so GitHub can create a tag at it. The existing gh release view idempotency guard is untouched, so re-runs remain safe.
Other factors
The repo's CODEOWNERS lists /.github under an upstream-WebKit maintainer; that file is inherited verbatim from Apple's WebKit and names contributors outside oven-sh, while build-reusable.yml is a Bun-fork-specific workflow that does not exist upstream and is routinely modified here — so I did not treat that entry as blocking. The PR description is unusually thorough (root cause, sampled evidence, local stub verification), and the preview build of this PR itself exercises the changed step end-to-end. No prior human or bot review comments to address.
Preview Builds
|
…low clones, and use the tag as a second source for previews `git fetch origin` only brings in what the clone's refspec covers, so in a --single-branch or --depth clone a pin that is not the tip of main was never found; the old script only got away with it because `--tags` happened to drag the history in. Fetch the pinned sha by id instead, and pass --depth when the clone is already shallow: fetching a ref whose history does not connect to the few commits such a clone has otherwise downloads all of WebKit's history (observed: 10 GB and counting for one refs/pull/<n>/head in the depth-1 vendor/WebKit clone). Previews fetch refs/pull/<n>/head and the release's tag, each best effort, and then look for the 8 hex among the commits present. The PR ref covers every release made so far (their tags point at main); the tag covers a push the PR has since force-pushed away, once tags point at the commit they are named after (oven-sh/WebKit#461). A release whose tag is gone still resolves through the PR ref.
|
Follow-up this PR does not do, for whoever owns the releases: moving the existing tags to the commit their name says. Counting every tag in the repo right now: 76 of the 620
This is optional as far as oven-sh/bun#39459 is concerned, which now reads the full sha from the downloaded tarball and fetches it by id; it is about the tags describing their releases correctly and keeping replaced pushes alive. Merging this PR first stops the set from growing. I can put the backfill together as a one-off script or a |
…e tag object oven-sh/WebKit names every release after the commit it built (autobuild-<sha>, autobuild-preview-pr-<n>-<sha8>), but the tag object behind a release was created at main's HEAD of the moment the release job ran (oven-sh/WebKit#461 fixes that for new releases). Resolving WEBKIT_VERSION through the tag therefore checks vendor/WebKit out at a different tree than the prebuilt that bun links against: always for a preview pin, and for the autobuild-<sha> tags whose build overlapped a merge. Take the sha from the name instead. Preview pins fetch refs/pull/<n>/head when the clone does not have the commit; sha pins fetch origin's branches as before (tags are no longer needed). A pin in neither form, or a preview commit that is not at the PR ref either, fails instead of checking out whatever the tag says. The resolution is exported so test/internal/source-lints/sync-webkit-source.test.ts can run it against small repos whose tags deliberately point at the wrong commit.
…low clones, and use the tag as a second source for previews `git fetch origin` only brings in what the clone's refspec covers, so in a --single-branch or --depth clone a pin that is not the tip of main was never found; the old script only got away with it because `--tags` happened to drag the history in. Fetch the pinned sha by id instead, and pass --depth when the clone is already shallow: fetching a ref whose history does not connect to the few commits such a clone has otherwise downloads all of WebKit's history (observed: 10 GB and counting for one refs/pull/<n>/head in the depth-1 vendor/WebKit clone). Previews fetch refs/pull/<n>/head and the release's tag, each best effort, and then look for the 8 hex among the commits present. The PR ref covers every release made so far (their tags point at main); the tag covers a push the PR has since force-pushed away, once tags point at the commit they are named after (oven-sh/WebKit#461). A release whose tag is gone still resolves through the PR ref.
1 participant
Problem
refs/tags/autobuild-preview-pr-459-9203122dpoints at e462c38 (main's HEAD when that release job ran); the 42 tarballs on it were built from PR head 9203122. Every preview tag checked behaves this way (387 sampled, back to the first ones from October 2025), so this predates Build -lto variants for freebsd and android; publish the release with gh instead of per-label action steps #412:action-gh-releasewas not given a target either.refs/tags/autobuild-781d6abb94b9eaee825e95ef700a83d8cf576f55points at a2f8782 (WTF: Linux memoryFootprint always parsed as 0, so the critical-memory GC mode never engaged #449, merged 85 seconds after 781d6ab). 33 of the 186 most recentautobuild-<sha>tags point at a commit other than<sha>..github/workflows/build-reusable.yml, jobrelease, step "Release" runsgh release create "$TAG" --title "$TAG" --generate-notes [--prerelease]with no--target, so GitHub creates the tag at the default branch's current HEAD. The build jobs all check outinputs.build_refand bake it into the tarballs asBUN_WEBKIT_VERSION; only the tag object is wrong.bun sync-webkit-sourceresolvesWEBKIT_VERSIONthrough the tag, so with a preview pin (or one of the 33 main pins above)vendor/WebKitis checked out at a different tree than the prebuilt JSC bun links against, silently: wrong lines when stepping through JSC, andbuild:localbuilding a different engine than the prebuilt.Fix
--target "$BUILD_REF"(inputs.build_ref) togh release create, so the tag is created at the commit that was built. Nothing else about the release changes: same title, generated notes, prerelease flag, and the upload loop.build_refis by construction the commit the tarballs contain:build.ymlpassesgithub.shaandbuild-preview.ymlpasses the PR head sha, and both deriverelease_tagfrom that same sha. Both are full 40-hex shas, which is one of the two forms--targetaccepts (the other is a branch name); thebuild_refinput description now says so. A PR head commit is in this repository's object store (refs/pull/<n>/head), so the tag can be created at it.gh release viewguard is unchanged, so a re-run of a job whose release already exists still neither recreates nor moves the tag.autobuild-<sha>tags and 627 of the 628 preview tags point elsewhere (full count in the comment below, which proposes moving them as a follow-up). sync-webkit-source: check out the commit named by the release, not the tag object bun#39459 makessync-webkit-sourcetake the commit from the release name (for a preview, from the full sha recorded in the downloaded tarball) and never from the tag, so it does not depend on the existing tags being moved.ghwith the inputs of the two examples above: it issuesgh release create autobuild-preview-pr-459-9203122d --title ... --target 9203122d... --generate-notes --prereleaseandgh release create autobuild-781d6abb... --title ... --target 781d6abb... --generate-notes. The preview build of this PR ran the changed step for real:refs/tags/autobuild-preview-pr-461-9be14059points at 9be1405, this PR's head, with all 42 assets on the release (gh api repos/oven-sh/WebKit/git/ref/tags/autobuild-preview-pr-461-9be14059); main's HEAD at the time was e462c38, which is where every earlier preview tag of the day points.Background
build-reusable.ymlis the shared workflow behind both release kinds.build.ymlcalls it for every push to main withbuild_ref = release_tag's sha;build-preview.ymlcalls it for PRs with the PR head sha and a tag namedautobuild-preview-pr-<n>-<first 8 hex of that sha>. Thereleasejob downloads the build jobs' artifacts, creates the release, and uploads them; it does not check anything out.target_commitishif given and at the default branch's HEAD otherwise;gh release create --targetis how that field is set.