deps: bump libarchive to v3.8.7, fix all dep-update workflows - #29289
Conversation
The update-libarchive.yml workflow was failing because it read the pinned commit from cmake/targets/BuildLibArchive.cmake, which was removed in #28640 when the build moved to scripts/build/deps/*.ts. - Point the workflow at scripts/build/deps/libarchive.ts and update the sed extraction/replacement to match the `const LIBARCHIVE_COMMIT = "..."` format. - Bump libarchive 3.8.1 -> 3.8.7 (ded82291ab41d5e3). - Rebase archive_write_add_filter_gzip.c.patch onto the new upstream source, which reformatted the compression-level branches around compressed[8]. Semantics unchanged: still adds the `os` option, defaults to Unix, and narrows crc to uint32_t. The other update-*.yml workflows have the same stale cmake reference and will be fixed separately.
|
Updated 10:09 PM PT - Apr 13th, 2026
❌ @Jarred-Sumner, your commit 57abf42 has some failures in 🧪 To try this PR locally: bunx bun-pr 29289That installs a local version of the PR into your bun-29289 --bun |
|
This PR may be a duplicate of:
🤖 Generated with Claude Code |
Same root cause as the libarchive fix in the previous commit: these seven workflows still read the pinned commit from cmake/targets/*.cmake files that were removed in #28640. Point each one at the corresponding scripts/build/deps/<name>.ts file and update the sed patterns to match the `const <NAME>_COMMIT = "..."` format. Covers cares, hdrhistogram, highway, libdeflate, lolhtml, lshpack, zstd.
Jarred-Sumner
changed the title
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughWorkflows were changed to read/update dependency SHAs from TypeScript dependency files instead of CMake targets; the libarchive dependency SHA was bumped; a gzip compressor patch adds a configurable OS field and changes the CRC type; a test expectation was updated to the new libarchive SHA. Changes
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
patches/libarchive/archive_write_add_filter_gzip.c.patch (1)
33-52: 🧹 Nitpick | 🔵 TrivialAdd a regression test for
gzip:os=Unknown.This is Bun-specific carry-patch behavior. Please extend
test/cli/install/bun-pack.test.ts(or equivalent) with an assertion that gzip header byte 9 is0xff, so the next libarchive rebase can't silently fall back to3again.Also applies to: 62-62
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@patches/libarchive/archive_write_add_filter_gzip.c.patch` around lines 33 - 52, The gzip OS mapping patch sets data->os = 255 for "Unknown" but we need a regression test to ensure libarchive writes byte 9 of the gzip header as 0xFF when using gzip:os=Unknown; add a test to test/cli/install/bun-pack.test.ts (or the equivalent CLI pack test) that creates a gzip with the option gzip:os=Unknown (or exercises the bun pack path that emits that header), reads the produced gzip file bytes and asserts that header byte index 9 equals 0xFF, and add the same assertion for any duplicate OS-handling code path (the other "os" branch) to prevent future regressions where it falls back to 3.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/update-libarchive.yml:
- Around line 23-24: The sed pattern reading/writing CURRENT_VERSION is too
strict and will break if whitespace or the trailing semicolon/quote style
changes; update the regexes that reference const LIBARCHIVE_COMMIT in the
workflow (the lines that set DEP_FILE and CURRENT_VERSION and the other
occurrence around line 80) to use a more tolerant pattern that allows optional
whitespace, optional semicolon, and either single or double quotes around the
SHA (e.g., match LIBARCHIVE_COMMIT\s*=\s*['"]([0-9a-f]{40})['"]\s*;?) so the
updater can still find and replace the SHA in scripts/build/deps/libarchive.ts
even after formatting-only edits.
---
Outside diff comments:
In `@patches/libarchive/archive_write_add_filter_gzip.c.patch`:
- Around line 33-52: The gzip OS mapping patch sets data->os = 255 for "Unknown"
but we need a regression test to ensure libarchive writes byte 9 of the gzip
header as 0xFF when using gzip:os=Unknown; add a test to
test/cli/install/bun-pack.test.ts (or the equivalent CLI pack test) that creates
a gzip with the option gzip:os=Unknown (or exercises the bun pack path that
emits that header), reads the produced gzip file bytes and asserts that header
byte index 9 equals 0xFF, and add the same assertion for any duplicate
OS-handling code path (the other "os" branch) to prevent future regressions
where it falls back to 3.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: af192f6e-99b8-41fe-bb91-cf5fa5abe520
📒 Files selected for processing (3)
.github/workflows/update-libarchive.ymlpatches/libarchive/archive_write_add_filter_gzip.c.patchscripts/build/deps/libarchive.ts
| DEP_FILE=scripts/build/deps/libarchive.ts | ||
| CURRENT_VERSION=$(sed -nE 's/^const LIBARCHIVE_COMMIT = "([0-9a-f]{40})";$/\1/p' "$DEP_FILE") |
There was a problem hiding this comment.
Loosen the sed patterns before a formatting-only edit breaks the updater.
Both expressions require the line to stay exactly const LIBARCHIVE_COMMIT = "<sha>";. Extra whitespace or a dropped semicolon in scripts/build/deps/libarchive.ts will make the workflow stop reading or rewriting the pin even though the value is still there.
💡 More tolerant `sed` patterns
- CURRENT_VERSION=$(sed -nE 's/^const LIBARCHIVE_COMMIT = "([0-9a-f]{40})";$/\1/p' "$DEP_FILE")
+ CURRENT_VERSION=$(sed -nE 's/^[[:space:]]*const[[:space:]]+LIBARCHIVE_COMMIT[[:space:]]*=[[:space:]]*"([0-9a-f]{40})";?[[:space:]]*$/\1/p' "$DEP_FILE")
- sed -i -E 's/^(const LIBARCHIVE_COMMIT = ")[0-9a-f]{40}(";)$/\1'"$LATEST"'\2/' scripts/build/deps/libarchive.ts
+ sed -i -E 's/^([[:space:]]*const[[:space:]]+LIBARCHIVE_COMMIT[[:space:]]*=[[:space:]]*")[0-9a-f]{40}(";?[[:space:]]*)$/\1'"$LATEST"'\2/' scripts/build/deps/libarchive.tsAlso applies to: 80-80
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/update-libarchive.yml around lines 23 - 24, The sed
pattern reading/writing CURRENT_VERSION is too strict and will break if
whitespace or the trailing semicolon/quote style changes; update the regexes
that reference const LIBARCHIVE_COMMIT in the workflow (the lines that set
DEP_FILE and CURRENT_VERSION and the other occurrence around line 80) to use a
more tolerant pattern that allows optional whitespace, optional semicolon, and
either single or double quotes around the SHA (e.g., match
LIBARCHIVE_COMMIT\s*=\s*['"]([0-9a-f]{40})['"]\s*;?) so the updater can still
find and replace the SHA in scripts/build/deps/libarchive.ts even after
formatting-only edits.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — straightforward workflow fix pointing to the correct dep file, clean version bump, and a semantically identical patch rebase.
Extended reasoning...
Overview
Three files changed: (1) the update-libarchive workflow is fixed to read/write LIBARCHIVE_COMMIT from scripts/build/deps/libarchive.ts instead of the deleted cmake file, (2) LIBARCHIVE_COMMIT is bumped from 3.8.1→3.8.7, and (3) the gzip patch is rebased onto the new upstream context lines with no semantic changes.
Security risks
The workflow change moves the SHA interpolation into an env: block (LATEST: ${{ steps.check-version.outputs.latest }}) rather than inline in the run: shell script — this is the correct pattern and avoids expression-injection risk. No auth, crypto, or permission-sensitive code is touched.
Level of scrutiny
Low. This is a dependency version bump + workflow repair with thorough manual verification documented in the PR description (build, archive tests, pack tests, byte-9 confirmation). The patch rebase is mechanical — only context lines shifted, the actual diff hunks are identical in effect.
Other factors
The only reported issue is a pre-existing fragility in the tag SHA dereference (annotated vs lightweight tags) that is entirely unmodified by this PR and does not affect correctness today. The fix is self-contained and unblocks a scheduled workflow that has been broken since the cmake migration.
|
|
||
| - name: Update version if needed | ||
| if: success() && steps.check-version.outputs.current != steps.check-version.outputs.latest | ||
| env: | ||
| LATEST: ${{ steps.check-version.outputs.latest }} | ||
| run: | | ||
| set -euo pipefail | ||
| # Handle multi-line format where COMMIT and its value are on separate lines | ||
| sed -i -E '/[[:space:]]*COMMIT[[:space:]]*$/{n;s/[[:space:]]*([0-9a-f]+)[[:space:]]*$/ ${{ steps.check-version.outputs.latest }}/}' cmake/targets/BuildLibArchive.cmake | ||
| sed -i -E 's/^(const LIBARCHIVE_COMMIT = ")[0-9a-f]{40}(";)$/\1'"$LATEST"'\2/' scripts/build/deps/libarchive.ts | ||
|
|
||
| - name: Create Pull Request | ||
| if: success() && steps.check-version.outputs.current != steps.check-version.outputs.latest | ||
| uses: peter-evans/create-pull-request@v7 | ||
| with: | ||
| token: ${{ secrets.GITHUB_TOKEN }} | ||
| add-paths: | |
There was a problem hiding this comment.
🟣 Pre-existing fragility: the two-step tag SHA dereference at lines 53–68 only works for annotated tags; if libarchive ever switches to lightweight tags, step 2 (GET /git/tags/{sha}) would return 404 and jq would yield 'null', failing the workflow. This code is unmodified by the PR — libarchive currently uses annotated tags so it works in practice.
Extended reasoning...
The tag SHA resolution block uses a two-step dereference pattern:
Step 1: GET /git/refs/tags/{LATEST_TAG} → extracts .object.sha as LATEST_TAG_SHA
Step 2: GET /git/tags/{LATEST_TAG_SHA} → extracts .object.sha as LATEST_SHA
This is correct only for annotated tags. In that case, step 1 returns a tag-object SHA (not a commit SHA), and step 2 dereferences the tag object to get the underlying commit SHA.
For lightweight tags, the behavior breaks: step 1 returns the commit SHA directly (there is no intermediate tag object). Step 2 then calls GET /git/tags/{COMMIT_SHA}, which returns HTTP 404 because no tag object exists for that SHA. The jq -r '.object.sha' call on a 404 response body returns null, causing LATEST_SHA to be set to the string "null".
The subsequent validation (if [ -z "$LATEST_SHA" ] || [ "$LATEST_SHA" = "null" ]) does catch this case and exits with an error — so the failure is loud, not silent. However, the workflow would then stop producing automatic update PRs until the code is fixed.
Concrete proof:
- libarchive releases lightweight tag
v4.0.0 GET /git/refs/tags/v4.0.0→{ "object": { "sha": "abc123...commit_sha", "type": "commit" } }LATEST_TAG_SHA=abc123...commit_shaGET /git/tags/abc123...commit_sha→ HTTP 404 (no tag object)jq -r '.object.sha'on the 404 body →null- Validation:
[ "null" = "null" ]→ true →exit 1
This code is pre-existing and entirely unmodified by this PR. The PR changes only: the CURRENT_VERSION extraction (awk→sed), the env block for LATEST, and the add-paths list. libarchive currently uses annotated tags so this does not fail in practice, but switching to lightweight tags would break the workflow.
Fix: use the /git/commits/{sha} endpoint or check the .object.type field from step 1 — if it's "commit", use that SHA directly; if it's "tag", do the second dereference.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/update-highway.yml:
- Around line 23-24: The workflow duplicates the sed-based extract/replace logic
for DEP_FILE and HIGHWAY_COMMIT; extract that routine into a single reusable
helper (either a shell script e.g., scripts/update-commit.sh or a composite
GitHub Action) and call it from this workflow and the other duplicate spots (the
same pattern at the other occurrence around the 95-99 block). The helper should
accept the dep file path (DEP_FILE) and the commit constant name
(HIGHWAY_COMMIT) and perform the sed extraction and rewrite so future format
changes need one edit.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 82e89e20-2757-4a0e-943e-a1dbb30f9b93
📒 Files selected for processing (7)
.github/workflows/update-cares.yml.github/workflows/update-hdrhistogram.yml.github/workflows/update-highway.yml.github/workflows/update-libdeflate.yml.github/workflows/update-lolhtml.yml.github/workflows/update-lshpack.yml.github/workflows/update-zstd.yml
| DEP_FILE=scripts/build/deps/highway.ts | ||
| CURRENT_VERSION=$(sed -nE 's/^const HIGHWAY_COMMIT = "([0-9a-f]{40})";$/\1/p' "$DEP_FILE") |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider extracting the *_COMMIT update routine into a shared helper.
This same sed extraction and rewrite pattern is duplicated across the dependency update workflows touched in this PR. A small shared script or composite action would make the next dep-file format change a one-place edit.
Also applies to: 95-99
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/update-highway.yml around lines 23 - 24, The workflow
duplicates the sed-based extract/replace logic for DEP_FILE and HIGHWAY_COMMIT;
extract that routine into a single reusable helper (either a shell script e.g.,
scripts/update-commit.sh or a composite GitHub Action) and call it from this
workflow and the other duplicate spots (the same pattern at the other occurrence
around the 95-99 block). The helper should accept the dep file path (DEP_FILE)
and the commit constant name (HIGHWAY_COMMIT) and perform the sed extraction and
rewrite so future format changes need one edit.
|
|
||
| - name: Update version if needed | ||
| if: success() && steps.check-version.outputs.current != steps.check-version.outputs.latest | ||
| env: | ||
| LATEST: ${{ steps.check-version.outputs.latest }} | ||
| run: | | ||
| set -euo pipefail | ||
| # Handle multi-line format where COMMIT and its value are on separate lines | ||
| sed -i -E '/[[:space:]]*COMMIT[[:space:]]*$/{n;s/[[:space:]]*([0-9a-f]+)[[:space:]]*$/ ${{ steps.check-version.outputs.latest }}/}' cmake/targets/BuildHdrHistogram.cmake | ||
| sed -i -E 's/^(const HDRHISTOGRAM_COMMIT = ")[0-9a-f]{40}(";)$/\1'"$LATEST"'\2/' scripts/build/deps/hdrhistogram.ts | ||
|
|
||
| - name: Create Pull Request | ||
| if: success() && steps.check-version.outputs.current != steps.check-version.outputs.latest | ||
| uses: peter-evans/create-pull-request@v7 | ||
| with: | ||
| token: ${{ secrets.GITHUB_TOKEN }} | ||
| add-paths: | | ||
| cmake/targets/BuildHdrHistogram.cmake | ||
| scripts/build/deps/hdrhistogram.ts | ||
| commit-message: "deps: update hdrhistogram to ${{ steps.check-version.outputs.tag }} (${{ steps.check-version.outputs.latest }})" | ||
| title: "deps: update hdrhistogram to ${{ steps.check-version.outputs.tag }}" | ||
| delete-branch: true |
There was a problem hiding this comment.
🔴 In update-hdrhistogram.yml, the annotated-tag dereference uses a silent fallback (2>/dev/null + .object.sha // empty) that cannot distinguish a legitimate lightweight tag from a transient network error on the second curl; if the second call fails while the tag is annotated, the fallback silently pins LATEST_TAG_SHA (a tag-object SHA, not a commit SHA) into hdrhistogram.ts, creating a PR with a wrong SHA that passes 40-char hex validation. The other three workflows fixed in this same PR (update-highway.yml, update-lolhtml.yml, update-lshpack.yml) avoid this by checking .object.type from the first API response instead.
Extended reasoning...
The hdrhistogram workflow resolves a tag to a commit SHA using this pattern (lines ~61-65 of the updated file):
LATEST_SHA=$(curl -sL ".../git/tags/$LATEST_TAG_SHA" 2>/dev/null | jq -r '.object.sha // empty')
if [ -z "$LATEST_SHA" ]; then
LATEST_SHA="$LATEST_TAG_SHA"
fiThe intent is correct for the lightweight-tag case: if HdrHistogram uses a lightweight tag, GET /git/tags/{sha} returns 404, jq gets no parseable JSON, and .object.sha // empty produces an empty string, so the fallback correctly reuses the commit SHA from step 1.
The problem is that "empty output" is also what you get when curl itself fails. In bash with set -euo pipefail, a command substitution pipeline does not abort the outer script even under -e, so a failed curl inside $(...) is swallowed silently. The 2>/dev/null additionally suppresses any stderr. If the call produces no JSON (connection timeout, etc.), jq -r '.object.sha // empty' outputs an empty string — identical to the legitimate lightweight-tag path.
Why this produces incorrect output, not just an error: When HdrHistogram uses annotated tags (common for release tags), LATEST_TAG_SHA is the SHA of a tag object, not of the underlying commit. If the second curl call fails, the fallback sets LATEST_SHA = LATEST_TAG_SHA (a tag-object SHA). The subsequent 40-char hex validation passes — tag object SHAs are also 40-character lowercase hex strings. The workflow then writes this tag-object SHA into scripts/build/deps/hdrhistogram.ts and creates a PR. A build that tries to fetch at that SHA will fail because the SHA refers to a tag object, not a commit/tree.
Concrete failure path:
- HdrHistogram releases annotated tag
v0.12.0 GET /git/refs/tags/v0.12.0succeeds →LATEST_TAG_SHA = abc123...tag_object_sha(type: tag)GET /git/tags/abc123...tag_object_shafails due to transient network error; curl exits 0 with no output;2>/dev/nullhides stderrjq -r '.object.sha // empty'on empty input → empty string →LATEST_SHA=""- Fallback:
LATEST_SHA="$LATEST_TAG_SHA"= tag-object SHA - 40-char hex validation passes (tag-object SHAs are valid 40-char hex)
- Workflow writes tag-object SHA into
hdrhistogram.tsand opens a PR - Downstream build fetches at a tag-object SHA → build failure
Contrast with the three correctly-fixed workflows in this same PR:
update-highway.yml: readsTAG_OBJECT_TYPE=$(... | jq -r '.object.type')from the first response; branches on"commit"vs"tag"; error-exits on unexpected typeupdate-lolhtml.yml: same pattern — checksTAG_OBJECT_TYPEfrom the first call, only does second dereference if type is"tag"update-lshpack.yml: same pattern
The fix is to extract .object.type from the first /git/refs/tags/ call (which already succeeded) and branch on it, eliminating any reliance on the second curl outcome to distinguish the two cases. No extra HTTP round-trip is needed.
| run: | | ||
| set -euo pipefail | ||
|
|
||
| # Extract the commit hash from the line after COMMIT | ||
| CURRENT_VERSION=$(awk '/[[:space:]]*COMMIT[[:space:]]*$/{getline; gsub(/^[[:space:]]+|[[:space:]]+$/,"",$0); print}' cmake/targets/BuildCares.cmake) | ||
| DEP_FILE=scripts/build/deps/cares.ts | ||
| CURRENT_VERSION=$(sed -nE 's/^const CARES_COMMIT = "([0-9a-f]{40})";$/\1/p' "$DEP_FILE") | ||
|
|
||
| if [ -z "$CURRENT_VERSION" ]; then | ||
| echo "Error: Could not find COMMIT line in BuildCares.cmake" | ||
| echo "Error: Could not find CARES_COMMIT in $DEP_FILE" | ||
| exit 1 | ||
| fi | ||
|
|
||
| # Validate that it looks like a git hash | ||
| if ! [[ $CURRENT_VERSION =~ ^[0-9a-f]{40}$ ]]; then | ||
| echo "Error: Invalid git hash format in BuildCares.cmake" | ||
| echo "Error: Invalid git hash format in $DEP_FILE" | ||
| echo "Found: $CURRENT_VERSION" | ||
| echo "Expected: 40 character hexadecimal string" | ||
| exit 1 |
There was a problem hiding this comment.
🔴 Four of the eight updated workflows (update-libarchive, update-cares, update-libdeflate, update-zstd) still use a naive two-step tag dereference that assumes all upstream releases use annotated tags; if any of those four projects publishes a lightweight tag, the second API call returns 404, jq yields 'null', and the workflow exits 1, silently stopping auto-updates. The fix was already applied to the other four workflows (update-highway, update-lolhtml, update-lshpack, update-hdrhistogram) in this very PR, making the omission an oversight — apply the same type-aware dereference pattern to the remaining four.
Extended reasoning...
What the bug is and how it manifests
This PR updates all eight dep-update workflows to read/write pinned commits from TypeScript files instead of CMake files. Four of the workflows (update-highway, update-lolhtml, update-lshpack, update-hdrhistogram) were additionally upgraded to handle both lightweight and annotated Git tags by checking .object.type from the GitHub refs API. The remaining four (update-libarchive, update-cares, update-libdeflate, update-zstd) received only the TypeScript migration and still use a naive two-step annotated-tag-only dereference pattern.
The specific code path that triggers it
For the four affected workflows, the SHA resolution works as follows:
- Step 1:
GET /git/refs/tags/{TAG}→ extracts.object.shaasLATEST_TAG_SHA - Step 2:
GET /git/tags/{LATEST_TAG_SHA}→ extracts.object.shaasLATEST_SHA
Step 2 unconditionally assumes LATEST_TAG_SHA is an annotated tag object SHA. If the upstream project publishes a lightweight tag instead, step 1 returns the commit SHA directly (.object.type = "commit"), and step 2 calls GET /git/tags/{COMMIT_SHA} — an endpoint that returns HTTP 404 because no tag object exists for a raw commit SHA.
Why existing code doesn't prevent it
The null checks (if [ -z "$LATEST_SHA" ] || [ "$LATEST_SHA" = "null" ]) will catch the 404 and exit 1, so the failure is not silent per se. However, they do not recover — the workflow simply dies with an error, and no update PR is created. The real impact is that auto-updates silently stop working until the code is manually fixed.
Step-by-step proof
- libarchive (or c-ares / libdeflate / zstd) releases
v4.0.0as a lightweight tag LATEST_TAG_SHA=$(curl .../git/refs/tags/v4.0.0 | jq -r '.object.sha')→ returns the commit SHA, e.g.abc123…(type=commit)LATEST_SHA=$(curl .../git/tags/abc123… | jq -r '.object.sha')→ GitHub returns HTTP 404; jq on the 404 body yieldsnull[ "$LATEST_SHA" = "null" ]is true →exit 1— no update PR is generated- The scheduled weekly run will keep failing until someone manually fixes the workflow
How to fix it
Apply the same type-aware pattern already used in update-highway.yml (or the // empty fallback in update-hdrhistogram.yml). For each of the four affected workflows, read .object.type alongside .object.sha from the refs API response: if type == "commit", use that SHA directly; if type == "tag", perform the second dereference to get the underlying commit SHA.
Context on the pre-existing review comment
A prior inline comment on this PR flagged the libarchive workflow's two-step dereference as a pre-existing fragility and said the code was "unmodified by the PR". However, all eight workflows previously used cmake-based awk extraction — none had this two-step dereference pattern before this PR. The pattern was introduced by this PR, but applied inconsistently: four workflows received the type-aware fix, four did not, making the omission an oversight within this PR rather than a pre-existing issue.
…h#29289) ## What does this PR do? The scheduled `update-*.yml` workflows have been failing since oven-sh#28640 removed `cmake/targets/*.cmake` — they were still reading pinned commits from those files. The dependency definitions now live in `scripts/build/deps/*.ts` as `const <NAME>_COMMIT = "..."`. **Workflows fixed** — `update-{libarchive,cares,hdrhistogram,highway,libdeflate,lolhtml,lshpack,zstd}.yml` now read/write the `_COMMIT` constant in the corresponding `scripts/build/deps/*.ts` file. The replacement step also moved to the safe `env:` pattern instead of inlining `${{ }}` into the shell. **libarchive bumped** — 3.8.1 → 3.8.7 ([compare](libarchive/libarchive@9525f90...ded8229)). `archive_write_add_filter_gzip.c.patch` rebased onto the new upstream, which reformatted the surrounding code; no semantic change — still adds the `gzip:os` option used by `bun pm pack` for reproducible tarballs. The other 7 deps were not version-bumped here; their now-working workflows will open bump PRs on the next scheduled run. Closes [oven-sh#26652](oven-sh#26652) Closes [oven-sh#26432](oven-sh#26432) Closes [oven-sh#26209](oven-sh#26209) Closes [oven-sh#25955](oven-sh#25955) Closes [oven-sh#25818](oven-sh#25818) Closes [oven-sh#25726](oven-sh#25726) Closes [oven-sh#25625](oven-sh#25625) Closes [oven-sh#25507](oven-sh#25507) Closes [oven-sh#25380](oven-sh#25380) ## How did you verify your code works? - [x] `bun scripts/build.ts --target=libarchive` — patches apply cleanly, builds `libarchive.a` with `ARCHIVE_VERSION_NUMBER 3008007` - [x] `bun bd test test/js/bun/archive.test.ts` — 99 pass - [x] `bun bd test test/cli/install/bun-pack.test.ts` — 70 pass - [x] `bun pm pack` gzip header byte 9 = `0xff`, confirming the rebased patch is functional - [x] All 8 workflows: extraction sed returns valid 40-char hash from the live `.ts` file (GNU sed) - [x] All 8 workflows: replacement sed rewrites exactly one line, round-trips back through extraction - [x] All 8 workflows: YAML parses, no `cmake` references remain
…h#29289) ## What does this PR do? The scheduled `update-*.yml` workflows have been failing since oven-sh#28640 removed `cmake/targets/*.cmake` — they were still reading pinned commits from those files. The dependency definitions now live in `scripts/build/deps/*.ts` as `const <NAME>_COMMIT = "..."`. **Workflows fixed** — `update-{libarchive,cares,hdrhistogram,highway,libdeflate,lolhtml,lshpack,zstd}.yml` now read/write the `_COMMIT` constant in the corresponding `scripts/build/deps/*.ts` file. The replacement step also moved to the safe `env:` pattern instead of inlining `${{ }}` into the shell. **libarchive bumped** — 3.8.1 → 3.8.7 ([compare](libarchive/libarchive@9525f90...ded8229)). `archive_write_add_filter_gzip.c.patch` rebased onto the new upstream, which reformatted the surrounding code; no semantic change — still adds the `gzip:os` option used by `bun pm pack` for reproducible tarballs. The other 7 deps were not version-bumped here; their now-working workflows will open bump PRs on the next scheduled run. Closes [oven-sh#26652](oven-sh#26652) Closes [oven-sh#26432](oven-sh#26432) Closes [oven-sh#26209](oven-sh#26209) Closes [oven-sh#25955](oven-sh#25955) Closes [oven-sh#25818](oven-sh#25818) Closes [oven-sh#25726](oven-sh#25726) Closes [oven-sh#25625](oven-sh#25625) Closes [oven-sh#25507](oven-sh#25507) Closes [oven-sh#25380](oven-sh#25380) ## How did you verify your code works? - [x] `bun scripts/build.ts --target=libarchive` — patches apply cleanly, builds `libarchive.a` with `ARCHIVE_VERSION_NUMBER 3008007` - [x] `bun bd test test/js/bun/archive.test.ts` — 99 pass - [x] `bun bd test test/cli/install/bun-pack.test.ts` — 70 pass - [x] `bun pm pack` gzip header byte 9 = `0xff`, confirming the rebased patch is functional - [x] All 8 workflows: extraction sed returns valid 40-char hash from the live `.ts` file (GNU sed) - [x] All 8 workflows: replacement sed rewrites exactly one line, round-trips back through extraction - [x] All 8 workflows: YAML parses, no `cmake` references remain
…29295) ## What does this PR do? The `process.versions` test in `test/js/node/process/process.test.js` hardcoded the expected commit hash for every vendored dependency. Each dep bump — including the automated `update-*.yml` workflows fixed in #29289 — required a matching edit here, and forgetting it broke CI. This rewrites the test to read each pinned commit out of `scripts/build/deps/<name>.ts` at test time using the same `^const X_COMMIT = "([0-9a-f]{40})";$` pattern the workflows use. Single source of truth: bumping a dep no longer requires touching this test, and it still catches the real failure mode (build didn't propagate the source-tree commit through `depVersionsHeader.ts` → `bun_dependency_versions.h` → `process.versions`). ## How did you verify your code works? - [x] `bun bd test test/js/node/process/process.test.js` — 101 pass, 0 fail - [x] `USE_SYSTEM_BUN=1 bun test ... -t "^process.versions$"` — fails (system bun has older libarchive than source tree) - [x] Negative check: temporarily edited `ZSTD_COMMIT` in `scripts/build/deps/zstd.ts` to a dummy hash → test fails with clear expected/received diff Co-authored-by: robobun <robobun@oven.sh>
2 participants
What does this PR do?
The scheduled
update-*.ymlworkflows have been failing since #28640 removedcmake/targets/*.cmake— they were still reading pinned commits from those files. The dependency definitions now live inscripts/build/deps/*.tsasconst <NAME>_COMMIT = "...".Workflows fixed —
update-{libarchive,cares,hdrhistogram,highway,libdeflate,lolhtml,lshpack,zstd}.ymlnow read/write the_COMMITconstant in the correspondingscripts/build/deps/*.tsfile. The replacement step also moved to the safeenv:pattern instead of inlining${{ }}into the shell.libarchive bumped — 3.8.1 → 3.8.7 (compare).
archive_write_add_filter_gzip.c.patchrebased onto the new upstream, which reformatted the surrounding code; no semantic change — still adds thegzip:osoption used bybun pm packfor reproducible tarballs.The other 7 deps were not version-bumped here; their now-working workflows will open bump PRs on the next scheduled run.
Closes oven-sh/bun#26652
Closes oven-sh/bun#26432
Closes oven-sh/bun#26209
Closes oven-sh/bun#25955
Closes oven-sh/bun#25818
Closes oven-sh/bun#25726
Closes oven-sh/bun#25625
Closes oven-sh/bun#25507
Closes oven-sh/bun#25380
How did you verify your code works?
bun scripts/build.ts --target=libarchive— patches apply cleanly, buildslibarchive.awithARCHIVE_VERSION_NUMBER 3008007bun bd test test/js/bun/archive.test.ts— 99 passbun bd test test/cli/install/bun-pack.test.ts— 70 passbun pm packgzip header byte 9 =0xff, confirming the rebased patch is functional.tsfile (GNU sed)cmakereferences remain