# 解决 Dependabot 生成 broken uv.lock 的问题 (April 13, 2025)

昨天我在 Dependabot 的 uv 支持的 issue 下面发了一条评论：

[dependabot/dependabot-core#10478 · GitHub](https://github.com/dependabot/dependabot-core/issues/10478#issuecomment-2798746196)

起因是，Dependabot 最近支持更新 uv 的 lockfile 了，但是支持的很不好，总是会给出 broken 的 lockfile，大家就都在下面抱怨。很搞笑的是，大家不知道是不是没看出来其实都是同一个问题，还是想借此机会给自己的项目打广告，很多人在评论中附上自己的项目的 CI 日志，即使这些都是重复的

我昨天的评论，就是在想，既然我本地是可以修复（重建？）这个 lock 文件的，那我为什么不能在 GitHub Actions 里运行？为什么不能在 Dependabot 打开一个 PR 的时候自动地触发修复？

然后我就跟 LLM 简要描述了下，稍加修改就成了。

```yaml
name: Fix uv.lock for Dependabot

on:
  push:
    branches:
      - "dependabot/uv/**"
  workflow_dispatch:

jobs:
  update-lockfile:
    permissions:
      contents: write
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          ref: ${{ github.ref }}
      - name: Set up Python
        uses: astral-sh/setup-uv@v5
        with:
          python-version: 3.12
      - name: Fix lockfile
        run: uv sync
      - name: Commit and push uv.lock if changed
        run: |
          git config --global user.name 'github-actions[bot]'
          git config --global user.email 'github-actions[bot]@users.noreply.github.com'

          # Check if uv.lock was modified or created
          if git diff --quiet --exit-code uv.lock; then
              echo "uv.lock is up-to-date."
          else
              echo "uv.lock changed, committing updates."
              git add uv.lock
              git commit -m "fix `uv.lock` after dependency update"
              git push origin HEAD:${{ github.ref_name }}
          fi
```

当然，还是我一直以来的观点：

**LLM 辅助编码的上限是你的能力**

比如我有一些碰壁的经历，让我知道：

+ 提交到`github.ref`会导致一个很奇怪的 bug，GitHub 会以 Dependabot 的身份把你的那个 ref merge 过来。虽然我上面的代码中最后是提交到`github.ref_name`，但这是我改的，LLM 生成的不是这样
+ LLM 忘记了`permissions: { contents: write }`
+ LLM  让我在 job 里的`if:`语句中判断是不是 Dependabot 的请求。事实上在`on:`中去 filter 更好

### 鲁棒地编码
我觉得过了这么久，我现在发现我有一个经验，就是尽量把代码解耦合，就能让 debug 容易很多。

比如，我有的代码，给每个幂等的函数结果都用 [diskcache](https://github.com/CNSeniorious000/diskcache2) 缓存下来，这样调试的时候就会快很多，也会便宜很多（当代码需要一些LLM请求时）。这也使得复现更容易了。

当然，用 [hmr](/blog/mwgggl2taiigch6w) 会更高效，因为它的 invalidate 是 on-demand 的，而且不涉及重启进程。不过 hmr 0.3 我引入了一些 bug 到现在还没修复 哈哈哈