Hooks for running commands after files update

[S1M0N38]

Question: Is there a way to update generated files during release PR creation?

Context

I have a Python project using Astral's uv for dependency management. When release-please creates a new version, I need to update uv.lock to match.

Currently, this happens in a separate commit after release:

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: write
  pull-requests: write

name: Release tag

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@v4
        id: release
        with:
          token: ${{ secrets.MY_RELEASE_PLEASE_TOKEN }}
          release-type: python

      - uses: actions/checkout@v4
        if: ${{ steps.release.outputs.release_created }}
        with:
          fetch-depth: 0
          ref: main

      - name: Install uv
        if: ${{ steps.release.outputs.release_created }}
        uses: astral-sh/setup-uv@v5

      - name: Configure Git
        if: ${{ steps.release.outputs.release_created }}
        run: |
          git config --local user.email "github-actions[bot]@users.noreply.github.com"
          git config --local user.name "github-actions[bot]"

      - name: Update lock file
        if: ${{ steps.release.outputs.release_created }}
        run: uv lock

      - name: Commit and push updated lock file
        if: ${{ steps.release.outputs.release_created }}
        run: |
          if [[ -n $(git status --porcelain uv.lock) ]]; then
            git add uv.lock
            git commit -m "chore(deps): update uv.lock for version ${{ steps.release.outputs.version }}"
            git push
          else
            echo "No changes to uv.lock"
          fi

Why updating after tag is problematic

Updating the lock file after the release tag creates several issues:

1. The tagged release doesn't match the actual dependencies needed for the version
2. Anyone checking out the tag will get an incorrect/outdated uv.lock file
3. Build reproducibility is compromised as the lock file isn't synchronized with the code version
4. The separate commit creates a state in the repository that wasn't properly tested before release

Question

Does release-please have any hooks or mechanisms to run commands (like uv lock) during PR creation, allowing generated files to be included in the release PR itself rather than added after the tag?

Environment

• Python project using astral.sh uv
• Using release-please-action@v4 with release-type: python

[JonasCir]

Hi,
from my experience with uv and release-please, you can try something like this:

1. create release-please-config.json
2. Add the following:

  {
    "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
    "packages": {
      "your-package": {
        "release-type": "python",
        "package-name": "your-package",
        "extra-files": [
          {
            "type": "toml",
            "path": "uv.lock",
            "jsonpath": "$.package[?(@.name.value=='your-package')].version"
          }
        ]
      }
  }

3. You can read about the bug that makes the jsonpath looks strange here
4. More docs on extra-files here
5. Adjust the config file as need. From my experience this is the way to go and preferable over the action input (except for the token)

Hope that helps!

Best,
Jonas

[S1M0N38]

I don't think that with this approach you can run custom comands like uv lock.

[JonasCir]

Correct, you cannot. But your lock file will be up-to-date in the release, so there is no need to run uv lock in the first place.

[mischavandenburg]

Thank you @JonasCir this worked perfectly!

[JonasCir]

I actually would like to revise my answer from above. This works fine if the extra file is located inside your package (i.e, you have project_root/some_package/uv.lock with extra-path and "path": "uv.lock" set).

However, if you use something like uv workspaces, the uv.lock resides above your package (i.e,. project_root/uv.lock). In this case, release-please unfortunately errors with release-please failed: illegal pathing characters in path: some_package/../uv.lock if you set "path": "../uv.lock".

It is a shame that this does not work and I do not get why relative paths should not be allowed here (think of a table in the toplevel README which holds all the component names and versions).

So yeah, either allowing relative paths or something like extra_cmd or extra_script would be great for flexibility.