Skip to content

Automate dependency updates with a scheduled Action#21640

Description

@prazian

馃殌 The feature, motivation and pitch

Hi, thanks for creating and maintaining this package. I use it in some of my own projects and wanted to help make sure it stays secure and well maintained with the least effort from maintainers.

Looking through the commit history, dependency bumps look like they're done manually right now, but I've recently created a new GitHub Action called Update Dependencies that might help here: https://github.com/marketplace/actions/update-dependencies

It scans your package manager(s), opens a PR with version bumps, and labels each change as breaking or non-breaking (Depending on which strategy we use).

Suggested setup for this repo:

  • Run it monthly, non-breaking updates only, so not much manual review is needed.
  • Set min-release-age-days to 14 (default is 3, similar to Github's Dependabot). That gives the community about two weeks to catch bugs or security issues in a new release before it lands here.
  • If you already run tests on every PR (which it seems you do), no extra config needed; your CI just checks the update PR like any other PR.

One thing worth noting: the GitHub token should be a PAT rather than the default token, so your CI actually triggers on the PR it opens. That'd need an admin to create and maintain.

Example workflow:

name: Update Dependencies

on:
  schedule:
    - cron: '0 2 1 * *' # monthly, 1st of month at 02:00 UTC
  workflow_dispatch:

permissions:
  contents: write
  pull-requests: write

jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: yanovian/update-dependencies-action@v1
        with:
          update-strategy: non-breaking
          min-release-age-days: 14
          create-pull-request: true
          github-token: ${{ secrets.PAT_TOKEN }}

What do you think? Happy to help set it up if useful.

Alternatives

Manual update or "custom scripts" but none of them actually check with the list of CVEs, and also it is not easy to check the update time for every single package.

Additional context

No response

RFC (Optional)

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions