Request icon
Script icon
Docker icon
If icon
Schedule icon

BumpPilot

Check a repo's requirements.txt against PyPI on a schedule and open a pull request bumping whatever is outdated. No duplicates, no noise.

Categories
CoreInfrastructure

Pinned Python dependencies go stale quietly. Nobody checks requirements.txt every week, so projects end up running old versions with known bugs until something breaks. This blueprint turns a scheduled PyPI check into an automatic bump PR: it reads the requirements file, asks PyPI for the latest version of each pin, and opens one pull request with the updates.

How it works

  1. fetch_requirements (io.kestra.plugin.core.http.Request) asks the GitHub API for the requirements file on the base branch. GitHub returns the file base64-encoded.
  2. get_base_sha (io.kestra.plugin.core.http.Request) asks the GitHub API for the latest commit on the base branch. The new bump branch starts from this commit.
  3. list_open_prs (io.kestra.plugin.core.http.Request) asks the GitHub API for the repo's open pull requests, so the flow never opens a duplicate bump PR.
  4. find_outdated (io.kestra.plugin.scripts.python.Script) decodes the file, goes line by line through the == pins, asks PyPI for each package's latest version, and keeps only the outdated ones that do not already have an open bump PR. It also builds the updated file content and the new branch name.
  5. process_updates (io.kestra.plugin.core.flow.If) runs only when something is outdated. Inside it, create_branch makes the bump branch, update_file writes the new requirements file to it, and open_pr opens the pull request.

What you get

  • A scheduled PyPI check for every pinned package in requirements.txt.
  • One pull request per run with all the outdated pins bumped, never two PRs for the same package.
  • A quiet run when everything is already current: no branches, no PRs, no noise.

Who it's for

  • Teams with Python services whose requirements.txt only gets updated when someone remembers.
  • Maintainers who want dependency updates as reviewable PRs instead of surprise breakages.
  • Anyone who has been bitten by running an old pinned version in production.

Why orchestrate this with Kestra

Dependabot covers this on GitHub, but its behavior is fixed and it only watches what GitHub tells it to. Kestra keeps the whole thing in one visible flow: the schedule, the PyPI version check, the duplicate-PR guard, and the branch and PR creation are all one auditable execution history, and every step is editable. You can point it at any pins file, add an ignore list, or change the schedule without asking a bot for permission.

Prerequisites

  • A GitHub repo with a requirements.txt (or a similarly formatted pins file).
  • A Kestra instance with Docker, because the version check runs in a Python container.

Secrets

  • GITHUB_TOKEN: GitHub personal access token with repo scope. The flow creates branches, writes files, and opens pull requests. In Kestra OSS, secrets are supplied as environment variables prefixed SECRET_, base64-encoded, and read back with {{ secret('NAME') }}, for example SECRET_GITHUB_TOKEN=$(echo -n '<token>' | base64).

Quick start

  1. Save your GitHub token as the GITHUB_TOKEN secret (base64-encoded, see above).
  2. Import the flow and hit Execute. Type the repo owner and repo name when it asks; the file path and branch already have defaults.
  3. Check the execution: if anything was outdated, a bump PR is now open on the repo.
  4. The Monday schedule takes care of the rest.

How to extend

  • Point requirements_path at a different pins file, like requirements-dev.txt.
  • Add an ignore_packages input and skip those pins in the Python step.
  • Change the schedule to run more or less often.

Inputs

  • repo_owner: who owns the repo.
  • repo_name: the repo name.
  • requirements_path: where the requirements file lives (defaults to requirements.txt).
  • base_branch: the branch the bump branch starts from (defaults to main).

Links

Pitfalls

  • PyPI's JSON API is unauthenticated and rate-limited; a requirements file with hundreds of pins can take a while or get throttled.
  • If a maintainer closes a bump PR without merging, the next run will propose it again, because closing is not the same as merging.
Share this Blueprint
See How

New to Kestra?

Use blueprints to kickstart your first workflows.