## Summary
- Fixed all `update-*.yml` workflows that were creating duplicate PRs
every week
## Problem
The update workflows (libarchive, zstd, cares, etc.) were using `${{
github.run_number }}` in the branch name, e.g.:
```yaml
branch: deps/update-libarchive-${{ github.run_number }}
```
This caused a new unique branch to be created on every workflow run, so
the `peter-evans/create-pull-request` action couldn't detect existing
PRs and would create duplicates.
**Evidence:** There are currently 8+ open duplicate PRs for libarchive
alone:
- #26432 deps: update libarchive to v3.8.5 (deps/update-libarchive-56)
- #26209 deps: update libarchive to v3.8.5 (deps/update-libarchive-55)
- #25955 deps: update libarchive to v3.8.5 (deps/update-libarchive-54)
- etc.
## Solution
Changed all workflows to use static branch names, e.g.:
```yaml
branch: deps/update-libarchive
```
This allows the action to:
1. Detect if an existing branch/PR already exists
2. Update the existing PR with new changes instead of creating a new one
3. Properly use `delete-branch: true` when the PR is merged
## Files Changed
- `.github/workflows/update-cares.yml`
- `.github/workflows/update-hdrhistogram.yml`
- `.github/workflows/update-highway.yml`
- `.github/workflows/update-libarchive.yml`
- `.github/workflows/update-libdeflate.yml`
- `.github/workflows/update-lolhtml.yml`
- `.github/workflows/update-lshpack.yml`
- `.github/workflows/update-root-certs.yml`
- `.github/workflows/update-sqlite3.yml`
- `.github/workflows/update-vendor.yml`
- `.github/workflows/update-zstd.yml`
## Test plan
- [x] Verified the change is syntactically correct
- [ ] Wait for next scheduled run of any workflow to verify it updates
existing PR instead of creating a new one
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Summary
Fixes the broken update hdrhistogram GitHub Action workflow that was
failing due to multiple issues.
## Issues Fixed
1. **Tag SHA resolution failure**: The workflow failed when trying to
resolve commit SHA from lightweight tags, causing the error "Could not
fetch SHA for tag 0.11.8 @ 8dcce8f68512fca460b171bccc3a5afce0048779"
2. **Branch naming bug**: The workflow was creating branches named
`deps/update-cares-*` instead of `deps/update-hdrhistogram-*`
3. **Wrong workflow link**: PR body was linking to `update-cares.yml`
instead of `update-hdrhistogram.yml`
## Fix Details
- **Improved tag SHA resolution**: Updated logic to handle both
lightweight and annotated tags:
- Try to get commit SHA from tag object (for annotated tags)
- If that fails, use the tag SHA directly (for lightweight tags)
- Uses jq's `// empty` operator and proper error handling with
`2>/dev/null`
- **Fixed branch naming**: Changed from `deps/update-cares-*` to
`deps/update-hdrhistogram-*`
- **Updated workflow link**: Fixed PR body to link to correct workflow
file
## Test Plan
- [x] Verified current workflow logs show the exact error being fixed
- [x] Tested API calls locally to confirm the new logic works with
latest tag (0.11.8)
- [x] Confirmed the latest tag is a lightweight tag pointing directly to
commit
The workflow should now run successfully on the next scheduled execution
or manual trigger.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
