docs: spec for dependabot conventions in the Charm Tech repos by tonyandrewmeyer · Pull Request #17 · canonical/charm-tech

tonyandrewmeyer · 2026-06-16T08:57:51Z

This PR adds a spec proposing changes and standardisation for the Dependabot configuration across the Charm Tech repos, to make the volume more manageable, but without losing the frequent updates.

It only covers Dependabot config, and does not cover (a) dropping dependencies or using ones that update less frequently, or (b) assistance with quality review of these PRs. There may be follow-up work on those.

…ain ignore - api_demo_server: row + rollout point at api_demo_server#45 baseline (pip→uv, drop Dockerfile, flit→uv_build); no-substance delta after that lands. - httpbin-demo: drop the docs-toolchain inheritance mention; canonical shape inherits as-is. - Docs toolchain: remove the `ignore:` block (sphinx/furo/myst aren't in tracked lockfiles; pygments noise belongs to the transitive-deps story). Reframe paragraph as a structural statement that the routine lane never reaches docs deps, with Sphinx Stack owning those bumps. Drop the now-moot dependabot-core#12354 caveat. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

benhoyt

Thanks. Looks good at a quick scan. I'm happy to leave more thorough review for others on the team.

james-garner-canonical

I'm broadly in favour of this approach, thanks for doing this.

Co-authored-by: James Garner <james.garner@canonical.com>

tromai

Thank you for writing the spec.

I am happy and excited to see the introduced policies in action. I think this is a good way going forward. I have a couple of questions, mostly to clarify some details, there is no major change requested.

@dwilding

address @dwilding: the bullet had ended up in a messy double-negative state. The transitive-deps direction is already covered by the Transitive dependencies section and the open question; the bullet added nothing. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

@james-garner-canonical

…rmation address @james-garner-canonical: the Specification section opened with 60-odd lines of tables before reaching any spec text. Keep a tight takeaways block at the head of Baseline (key totals + the two observations that drive the design), and move the per-repo config snapshot, aggregate volume, and per-repo PR-volume tables into a Further information section at the end of the doc. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

- Add charm-tech group (ops/ops-scenario/ops-tracing/jubilant/pytest-jubilant); remove jubilant and ops-scenario from test-deps. - Raise open-pull-requests-limit to 100 on both routine lanes; grouping is what keeps PR volume sane. - Note that requirements.txt only exists in charm-ubuntu. - Drop redundant 'why not test-deps: ["*"]' paragraph. - Trim 'majors as own PR' bullet; drop the orthogonal per-example ignore-drift parenthetical. - Rename 'Resolved scoring rules' section to 'Other decisions'. - Reshape charmlibs delta: one updates: entry per top-level library directory, so per-codeowner PR routing actually works. Add a follow-up open question on whether to tool-generate the file. - Clarify the operator row: both adding examples/httpbin-demo and dropping the obsolete k8s-5-observe / machine-tinyproxy blocks; link to context. - Drop the misleading '+ zizmor' charmhub-listing-review delta. - Spell out the 'repo-level toggle' inline and link to the rationale section. - Remove the bogus master->main pebble normalisation. - Standardise the filename on .yaml (both .yaml and .yml are GitHub- supported; .yaml matches charmcraft.yaml etc). - Replace 'None of substance' with 'No per-repo changes' to be clearer to non-author readers. - Drop the duplicate Replication hygiene paragraph; fold rationale into the Acceptance criteria bullet. - Expand Rollout lead-in to spell out what 'regression' and 'block' actually mean. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

tromai

Thank you for the clarification.

james-garner-canonical · 2026-06-17T23:57:44Z

@@ -0,0 +1,427 @@
+# OP???: Dependabot config conventions for Charm Tech repos


When does this workflow result in a spec number? Only at the 'add to Google docs' stage?

Yeah, I think so (which would be pre-merge presumably). "Claiming" the number is basically looking at what already exists, so it doesn't seem like there is another option, assuming that all these specs do end up there too (rather than having some OP-git-123 type thing with specs that are only here). I guess I could add a blank doc there just for number claiming.

james-garner-canonical · 2026-06-18T00:04:03Z

+2. **`charmlibs` PRs are separated per charmlib.** One `updates:` entry per
+   top-level library directory, not a single shared lane spanning the
+   monorepo. Required because multiple teams own different libraries (per
+   `CODEOWNERS`), so each PR needs to land with one team's reviewers, not
+   batch every team's bumps together. Dependabot's `groups:` matches on
+   dependency *name*, not on which directory or library depends on it, so
+   the only way to get per-library PRs is per-library `updates:` entries.
+   This is verbose enough to be a candidate for generation (see
+   [§open questions](#charmlibs-generation)).


Would the outcome of this spec result in directly touching charmlibs? I'm not clear from the contents of the spec. I don't think we should apply the key change (grouping by dependency names), as this will result in grouping across codeowners that level of grouping would have to be downstream of grouping by charm library, which I think the spec is flagging as out of scope. Happy for charmlibs to be aligned on what does make sense though. But maybe this mostly just results in a rainy day item for charmlibs?

Definitely not at first - I think we want to roll it out on a repo or two and then validate that things are ok. Then I think we do roll it out to everything other than charmlibs.

Charmlibs is by far the trickiest case, I think. The spec is probably unclear because I'm uncertain. If the spec design works for charmlibs, then we should do it there, although I'm definitely fine with charmlibs (maybe also some of the others) being rainy day issues. This whole thing is sprint-followup rather than roadmap work anyway.

Sounds good to me. The rollout section might need updating to reflect this.

The first pass of this branch landed a dependabot.yml that diverged from canonical/charm-tech#17 in several ways. Fix: - Drop the daily security-only lane. The spec explicitly forbids a YAML security lane; CVE PRs come from the repo-level "Dependabot security updates" toggle (canonical-repo-automation manages the setting), which is event-driven and not schedule-driven. - open-pull-requests-limit: 5 -> 100. Grouping caps PR count structurally; the limit is the spec's effectively-unlimited value. - Add the canonical charm-tech group (ops, ops-scenario, ops-tracing, jubilant, pytest-jubilant). This repo doesn't currently depend on them, but the spec is "no per-repo changes; matches the template", and the group costs nothing if unused. - Drop the docs group (sphinx/furo/myst-parser/pygments). Not in the canonical template; spec says no per-repo changes for this repo. Doc deps fall into runtime (minor + patch only). - Drop the zizmor entry from dev-tooling. Not in the canonical template; zizmor falls into runtime. (If we want zizmor in dev-tooling everywhere, amend the spec - don't deviate here.) - Restore the spec's leading rationale comment about the repo-level security toggle. Also rename the file dependabot.yml -> dependabot.yaml to match the charm-tech-wide .yaml convention.

…refix Match the resolved rule from the dependabot-conventions spec (canonical#17): 'chore:' with no scope, on both the pip and github-actions ecosystems. Setting only 'prefix: chore' produces 'chore: bump ...' automatically — Dependabot inserts the colon-space when the prefix ends in a letter — so 'include: scope' is unnecessary and would produce the non-conforming 'chore(pip): ...' / 'ci(github-actions): ...' shape. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Aligns .github/dependabot.yaml with [the spec](canonical/charm-tech#17): * Two lanes per ecosystem. * uv ecosystem (charm-ubuntu is now on uv). * Grouped along dev-tooling / test-deps / runtime seams. No docs group; no sphinx toolchain in this repo. * commit-message.prefix: "chore" on every entry. * Cooldown: 7d default, 14d for majors. File renamed .yml -> .yaml so it matches the .github/workflows/*.yaml convention already in use. --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> Co-authored-by: James Garner <james.garner@canonical.com>

tonyandrewmeyer added 9 commits June 16, 2026 19:53

initial version

5ea0f0f

fix the security check bit

a1d324f

more security cleanup

2cd7f16

drop docs

999efcd

dynamic uv.lock for examples

73ec292

drop irrelevant block, pr open for this already

121c635

more tweaks

324d5c6

transitive deps

6040513

English

a88abb6

tonyandrewmeyer requested review from benhoyt, dwilding, hpidcock, james-garner-canonical and tromai June 16, 2026 09:00

dwilding reviewed Jun 16, 2026

View reviewed changes

Comment thread specs/OP0xx-dependabot-config-conventions.md Outdated

Comment thread specs/OP0xx-dependabot-config-conventions.md Outdated

Comment thread specs/OP0xx-dependabot-config-conventions.md Outdated

tonyandrewmeyer and others added 2 commits June 17, 2026 08:58

Merge branch 'main' into dependabot-config-conventions

8154e8b

tonyandrewmeyer requested a review from dwilding June 16, 2026 21:00

benhoyt approved these changes Jun 16, 2026

View reviewed changes

james-garner-canonical reviewed Jun 17, 2026

View reviewed changes

Apply suggestion from @james-garner-canonical

0116f66

Co-authored-by: James Garner <james.garner@canonical.com>

tromai reviewed Jun 17, 2026

View reviewed changes

Comment thread specs/OP0xx-dependabot-config-conventions.md Outdated

Comment thread specs/OP0xx-dependabot-config-conventions.md Outdated

Comment thread specs/OP0xx-dependabot-config-conventions.md Outdated

Comment thread specs/OP0xx-dependabot-config-conventions.md Outdated

tonyandrewmeyer and others added 3 commits June 17, 2026 19:59

tonyandrewmeyer requested review from james-garner-canonical and tromai June 17, 2026 10:24

tromai approved these changes Jun 17, 2026

View reviewed changes

james-garner-canonical approved these changes Jun 18, 2026

View reviewed changes

tonyandrewmeyer merged commit c0e3a9c into canonical:main Jun 28, 2026

tonyandrewmeyer deleted the dependabot-config-conventions branch June 28, 2026 21:42

tonyandrewmeyer mentioned this pull request Jun 30, 2026

ci: adopt new dependabot conventions canonical/charmhub-listing-review#136

Merged

tonyandrewmeyer mentioned this pull request Jul 7, 2026

ci: adopt Charm Tech dependabot conventions canonical/charm-ubuntu#98

Merged

		@@ -0,0 +1,427 @@
		# OP???: Dependabot config conventions for Charm Tech repos

Uh oh!

Conversation

tonyandrewmeyer commented Jun 16, 2026 • edited by benhoyt Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

benhoyt left a comment

Choose a reason for hiding this comment

Uh oh!

james-garner-canonical left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tromai left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tromai left a comment

Choose a reason for hiding this comment

Uh oh!

james-garner-canonical Jun 17, 2026

Choose a reason for hiding this comment

Uh oh!

tonyandrewmeyer Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

james-garner-canonical Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

tonyandrewmeyer Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

james-garner-canonical Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

tonyandrewmeyer commented Jun 16, 2026 •

edited by benhoyt

Loading