This message was deleted.
# gitops
s
This message was deleted.
l
I’m using Renovate which is doing the same as dependabot but more and better. From my experience, there is no one way fit all. There are many considerations to take into account. My idea is to start small (MVP) and continuously improve according to the feedback/requirements which pile up.
p
we did a lot of hand-wringing around turning on automated dependabot approvals but once we did, we never looked back. It has become pretty crucial to our process. We have the advantage though of having fantastic automated test coverage (> 85%) across every one of our services. I would feel a lot less good about it if we did not have good test coverage. We’ve been operating with auto-approving both minor and patch updates for > 1yr. In that year, there is only a single breaking change that was merged in (an upgrade to boto) across thousands of merged PRs. We caught it before it made it to customers though via some manual testing. We have been really happy with it but as @Liora Milbaum said, YMMV
but the volume of updates is hard to keep up with
another strategy could be to tone down the frequency of updates, for instance only have dependabot check for updates once a week
if you’re interested in auto-approve, this is the GitHub action we use:
Copy code
name: Dependabot auto-approve
on: pull_request_target
permissions:
  pull-requests: write

# From the docs at <https://github.com/dependabot/fetch-metadata#enabling-auto-merge>
jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: ${{ github.event.pull_request.user.login == 'dependabot[bot]' }}
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v1.3.0
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Auto-approve minor or patch updates
        if: |
          steps.metadata.outputs.update-type == 'version-update:semver-minor'
                || steps.metadata.outputs.update-type == 'version-update:semver-patch'
        run: gh pr review --approve "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
and then we also flip on ‘auto-squash-merge’ (which you have to enable at the repo level I believe) for all dependabot PRs once they are approved
Copy code
name: Dependabot auto-merge
on: pull_request
permissions:
  pull-requests: write
  contents: write

# Mostly from <https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/automating-dependabot-with-github-actions#enable-auto-merge-on-a-pull-request>

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: ${{ github.event.pull_request.user.login == 'dependabot[bot]' }}
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v1.3.0
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Enable auto-merge for Dependabot PRs
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
k
Thanks! We're still in the hand wringing phase, we did turn down to once a week but it's still a lot of PRs. We were thinking of doing the auto approve like you are doing @Phillip Verheyden, but glad to hear that it's worked well for you. We had thought about Renovate also a while ago, but it may also be worth a rethink
l
With renovate, you can generate one PR for multiple updates. That saves us a lot of effort.
j
Thanks for the suggestions in this 🧵 dependabot hell is real!
m
We're using renovate, here too. Like @Liora Milbaum, this capacity to group multiple updates in one consistent PR really helped us. For some dependencies that are updated multiple times per day, we grouped AND limit schedule to one PR per week.
143 Views