dependabot-demo: The Repo That Shows Dependabot’s Decision Tree
Two requirement styles, one update policy, and raw bot logs reveal how Dependabot decides what deserves a pull request.
- dependabot-demo turns Dependabot into a policy engine by checking in the logs that usually stay hidden behind a pull request.
- The real experiment is not whether updates happen, but how `~=` and `==` steer the same automation toward different outcomes.
- The repository shows Dependabot as a chain of gates, where config, ignore rules, manifest parsing, and the updater all shape the final decision.
- The practical choice for teams is not Dependabot versus no automation, but Dependabot versus a stricter or more configurable update policy.
The weirdest thing in this repo is the point
Most Dependabot demos stop at the visible output. A pull request appears, a version changes, and the story ends there. ankitvgupta/dependabot-demo is interesting because it refuses to stop at the output. It checks in the raw execution logs, which turns the repo into a little laboratory for automated dependency policy.
That choice changes the whole read. Instead of treating Dependabot like a black box that happens to be hosted by GitHub, the repo exposes the parts that usually stay invisible: manifest parsing, version interpretation, proxy fetches, and the updater’s final decision. The result is less like a sample app and more like a field note from inside the bot.
Fork me to try out Dependabot
Two directories, two dependency philosophies
The core experiment lives in two sibling folders. compatible_release uses the Python compatible release operator, ~=`, while pinned_release uses the exact pin, ==. That sounds subtle, but it is the whole story. The same bot sees two dependency contracts and reacts differently because the contracts mean different things.
| Strategy | What it says | What Dependabot can do | Operational meaning |
|---|---|---|---|
| <code>~= 1.24.0</code> | Stay within the compatible release range. | Suggest updates that still fit the range, or open a PR when the constraint itself needs to move. | You are accepting some automatic movement, but only inside a boundary. |
| <code>== 1.24.0</code> | Use this exact version and nothing else. | Every change requires a deliberate version bump in the requirement file. | You are trading convenience for tight control and repeatable installs. |
| Patch ignore rule | Skip semver patch updates at the policy layer. | Dependabot focuses on larger changes instead of tiny churn. | The repo makes policy visible, because the bot is not just scanning versions, it is obeying rules. |
Inside Dependabot’s gatekeeping
The repository’s config file is the brainstem. In .github/dependabot.yml, the same ecosystem is configured for two directories, then a global patch ignore rule cuts off low-value noise. That means the bot is not simply checking for newer versions. It is checking versions through policy.
version: 2
updates:
- package-ecosystem: "pip"
directory: "/compatible_release"
schedule:
interval: "weekly"
- package-ecosystem: "pip"
directory: "/pinned_release"
schedule:
interval: "weekly"
ignore:
- dependency-name: "*"
update-types: ["version-update:semver-patch"]From there, the flow gets more interesting than a normal update bot. Dependabot reads the manifest, interprets the version operator, checks what the policy allows, and uses its updater and proxy layers to gather metadata before deciding whether a PR should exist. The checked-in logs matter because they show that the decision is assembled, not guessed.
That is why the logs feel so revealing. They expose the difference between version semantics and update policy. A compatible release can move inside its range, a pinned release cannot, and the ignore rule can block patch noise even before the bot gets to the more interesting decisions.
Why this demo exists
This is not a production app. It is a teaching artifact. The repository exists to make an invisible system legible, which is a valuable move whenever automation starts making decisions on your behalf. Ankit Gupta’s repo does that by making the path from manifest to PR inspectable.
That framing matters because Dependabot often gets discussed as a convenience feature. This repo pushes the conversation one layer deeper. It shows that the convenience comes from a policy machine with a narrow set of choices, and those choices are the real product.
Dependabot is not the only answer
The natural comparison is Renovate. Dependabot wins on zero-friction GitHub integration, while Renovate wins on breadth and control. This repo is useful because it helps you see what you give up, or keep, when you choose the GitHub-native default.
| Tool | Where it fits best | Strength | Trade-off |
|---|---|---|---|
| Dependabot | Teams already living in GitHub. | Simple setup and native pull requests. | Less expressive policy and fewer cross-repo presets. |
| Renovate | Teams that want deeper configuration. | Broader platform support and richer rules. | More setup, more tuning, more surface area. |
The point is not to crown a winner. It is to notice what this repo teaches about automation: the more invisible the policy, the more useful a demo becomes. Dependabot feels simple at the top because the policy is doing careful work underneath.
The practical lesson for teams
If you use ~=`, you are saying that compatible movement is acceptable. If you use ==, you are saying that every change deserves explicit attention. Dependabot does not erase that difference. It makes the difference operational.
That is the real value of dependabot-demo. It shows that dependency automation is not just about staying current. It is about deciding how much change to absorb automatically, how much noise to ignore, and how much control you want to keep in the repository itself.