## 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>
## What does this PR do?
Fixes the failing `update-lshpack.yml` GitHub Action that has been
consistently failing with the error: "Could not fetch SHA for tag v2.3.4
@ {SHA}".
## Root Cause
The workflow assumed all Git tags are annotated tags that need to be
dereferenced via the GitHub API. However, some tags (like lightweight
tags) point directly to commits and don't need dereferencing. When the
script tried to dereference a lightweight tag, the API call failed.
## Fix
This PR updates the workflow to:
1. **Check the tag type** before attempting to dereference
2. **For annotated tags** (`type="tag"`): dereference to get the commit
SHA via `/git/tags/{sha}`
3. **For lightweight tags** (`type="commit"`): use the SHA directly
since it already points to the commit
## Changes Made
- Updated `.github/workflows/update-lshpack.yml` to properly handle both
lightweight and annotated Git tags
- Added proper tag type checking before attempting to dereference tags
- Improved error messages to distinguish between tag types
## Testing
The workflow will now handle both types of Git tags properly:
- ✅ Annotated tags: properly dereferences to get commit SHA
- ✅ Lightweight tags: uses the tag SHA directly as commit SHA
This should resolve the consistent failures in the lshpack update
automation.
## Files Changed
- `.github/workflows/update-lshpack.yml`: Updated tag SHA resolution
logic
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
