Hey all - I'm not sure if this is of interest to a...
# general
p
Hey all - I'm not sure if this is of interest to anyone, but we are moving to pants and wanted to be able to • use renovatebot as we do in our polyrepo setup • update lockfiles when renovate makes a change My first stab at this is a workflow that • Runs when conventional commit includes `chore(deps):`or
fix(deps):
• updates lockfiles with
pants generate-lockfiles
• If our lockfile (
3rdparty/python/default.lock
) has changed, commit it This is a rough draft, and I'd love to know if people have better ideas or places where we can improve this, but at this point, it got me past stakeholder concerns and is working. 🧵
Copy code
---
name: Update lockfiles when dependencies change is merged

on:
  pull_request:
    branches: [main]

concurrency:
  group: ${{ github.ref }}-${{ github.workflow }}
  cancel-in-progress: true

jobs:
  update-lockfiles:
    name: update-lockfiles
    runs-on: arc-runner-set
    if: |
      contains(github.event.pull_request.title, 'chore(deps)') ||
      contains(github.event.pull_request.title, 'fix(deps)')
    outputs:
      AFFECTED_PROJECTS: ${{ steps.get_affected_projects.outputs.AFFECTED_PROJECTS }}
      CHANGE_BASE: ${{ steps.set-change-base.outputs.CHANGE_BASE }}
    env:
      AGENT_TOOLSDIRECTORY: /opt/hostedtoolcache
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4
        with:
          token: ${{ secrets.GH_ACCESS_TOKEN }}
          fetch-depth: 0

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Initialize Pants
        uses: pantsbuild/actions/init-pants@main
        with:
          gha-cache-key: cache0-py3.12

      - name: Update lockfiles
        run: |
          pants generate-lockfiles

      - name: Commit changes
        run: |
          git switch ${GITHUB_HEAD_REF}
          CHANGES_NEEDED=$(git status --porcelain | grep "python/default.lock" | wc -l)
          if [ "${CHANGES_NEEDED}" -lt 1 ]; then
            echo "No changes to lockfile - not pushing change"
          else
            git config --global user.name "github-actionspantslockfilebot"
            git config --global user.email "<mailto:github-actionsactionspantslockfilebot@users.noreply.github.com|github-actionsactionspantslockfilebot@users.noreply.github.com>"
            git add 3rdparty/python/default.lock
            git commit -m "Update python lockfile with dependency change"
            git push origin HEAD:${GITHUB_HEAD_REF}
          fi
d
We're doing something similar, but we are using the postUpgradeTasks to generate the lockfile: https://docs.renovatebot.com/configuration-options/#postupgradetasks I think that might have some advantages, because the changes are part of the renovate commit.
p
oooooh - thanks - I'll take a look at that! Do you have an example of how you're ensuring
pants
is available for that to run successfully please?
d
oh, yeah, I wrote a little python script that lives in the repo and is the postUpgradeTask. It does
which pants || ./get-pants.sh
before running
pants generate-lockfiles
p
Ta - let me go and try that to replace my monstrosity 😄
@dazzling-pizza-75442 Are you running renovate self hosted?
d
using the github action
well our self-hosted gha
p
I'll look at the action or the k8s cronjob approach. We have self-hosted runners, but we just run through the Renovate application today which doesn't allow us to customize an image
d
ahh
p
We've been looking to move to our own runners for a while anyway to solve some other things, so this is a good day for it 🙂
c
We use a group and postUpgradeTasks as well. We run renovate ourselves in a custom docker container that has Pants.
p
That's where we've ended up - we added docker to our standard self-hosted runner container and have a postUpgradeTask that runs a script that simply does
/home/ubuntu/.local/bin/pants generate-lockfiles
We're trying to solve an issue where with multiple changes, lockfiles in subsequent PRs cause merge conflicts - if we have 3 library upgrades today, the first one is clean, but the next two require intervention
That's on the 'fix next week' list
c
We use a group to batch all python updates, there's 1 big PR for all updates (we only have 1 resolve). Upside is no merge conflicts (and tbh testing 1 large PR is easier for us), downside is that all the updates are grouped.
Copy code
{
"packageRules": [{
  "groupName": "Python",
  "groupSlug": "python",
  "matchDataSources": ["pypi"],
  "postUpgradeTasks": {
    "commands": ["pants generate-lockfiles --resolve=python-default"],
    "executionMode": "branch"
  }]
}
(Rip formatting I'm on mobile)