Daily dependency update fails: merging main into the update branch produces a uv.lock that uv cannot parse
维护者通常 1 天内回复
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 25/100
调研方向
Start with .github/workflows/update-dependencies.yml and .github/scripts/dependency-update-prepare-branch.sh, then review the failed run’s merge behavior and the open pull request #890. The issue describes rebuilding the update branch from origin/main, updating it, and replacing the remote branch with a lease check; verify the workflow handles unchanged files and updates the existing PR description.
由索引模型根据 Issue 内容生成。
描述
The daily Update dependencies workflow (.github/workflows/update-dependencies.yml) has failed on every run since at least 2026-10-10.
What happens
Run 39659265166 fails at the "Generate API clients" step (./scripts/generate-clients.sh):
error: Failed to parse `uv.lock`
cause: The entry for package `cryptography` (50.0.1) has wheel `cryptography-49.0.0-cp311-abi3-macosx_11_0_arm64.whl` with inconsistent version (49.0.0), which indicates a malformed wheel.
Cause
When an update PR is open (#583, branch update-dependencies, opened in June), .github/scripts/dependency-update-prepare-branch.sh checks out that branch and runs git merge --no-edit -X theirs origin/main. The run log shows git auto-merging all seven uv.lock files. A line-by-line merge of two generated lock files mixes entries from two different resolutions: here a cryptography 50.0.1 entry kept a 49.0.0 wheel list, and uv refuses the lock.
Fix
Build the update branch from origin/main on every run instead of merging main into the old branch, run the update, and replace the remote branch with --force-with-lease against the commit it pointed at when the run started. Skip the push when the branch already holds the same files. Keep reusing the open update PR and replace its description.
- 主要语言
- Python
- 星标
- 1
- 派生
- 1
- 平均合并
- 1 天 16 小时
- 30 天内合并 PR
- 60
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
PolicyEngine/policyengine-sim-api 的其他 Issue
-
Update policyengine to 6.7.3可能重新可做 关联的 PR 已关闭且未合并。 未关闭
难度 2/5 半天 新手友好度 70/100
PolicyEngine/policyengine-sim-api#823 ·
维护者通常 1 天内回复
-
Integration tests fail due to missing UV virtual environment setup可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 65/100
PolicyEngine/policyengine-sim-api#314 ·
维护者通常 1 天内回复
-
Staging deployments do not promote their tested Simulation Entrypoint revision可能已有人在做 @anth-volk 于 1 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 35/100
PolicyEngine/policyengine-sim-api#893 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
PolicyEngine/policyengine-sim-api#884 ·
维护者通常 1 天内回复
-
Update policyengine to 6.10.0可能已有人在做 @policyengine 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 35/100
PolicyEngine/policyengine-sim-api#882 ·
维护者通常 1 天内回复
查看 PolicyEngine/policyengine-sim-api 的全部 Issue
相似的 Issue
-
good first issue priority: low size: XS testing
难度 1/5 1-3 小时 新手友好度 86/100
cubrid-lab/cubrid-mcp-server#385 ·
维护者通常 1 天内回复
-
good first issue priority: low size: S testing
难度 2/5 1-3 小时 新手友好度 85/100
cubrid-lab/cubrid-cookbook-python#447 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
ArduCAM/Arducam_tof_camera#125 ·
-
area:curator enhancement
难度 2/5 1-3 小时 新手友好度 74/100
CassioDalla/Scrinalia#150 ·
维护者通常 1 天内回复
-
documentation good first issue
难度 2/5 1-3 小时 新手友好度 72/100