Automatically release plugins affected by production dependency updates

Start with tools/plugin_catalog.py, .github/dependabot.yml, and the existing version-bump and release workflow; trace how CI currently selects plugins and creates tags. Run the current release validation checks before changing them, then add focused coverage for dependency-impact selection and idempotency. Done means correct stable plugin selection, consistent version sources, safe reruns, documented policy, and unchanged release validation and publication flow.

Summary

Add dependency-impact automation so an approved production dependency update results in patch releases for every plugin whose shipped dependency graph changed, and no others.

Reuse the existing version-bump-driven release pipeline. A shared Cargo.lock or uv.lock change must not release every plugin indiscriminately; selection must be based on actual dependency impact.

Current behavior

• Dependabot checks Cargo and uv dependencies weekly via .github/dependabot.yml.
• CI selects and tests plugins affected by shared dependency files.
• Release tags are created only when a plugin's own Cargo.toml version changes.

As a result, merging a dependency update does not publish rebuilt plugin wheels unless a maintainer also determines the affected plugins and manually bumps each plugin's Cargo.toml, plugin-manifest.yaml, and Cargo.lock entry.

Dependabot's role

Dependabot should continue to discover dependency updates, update manifests/lockfiles, group updates, and open PRs. It can filter and group many dependency updates, but it does not implement this repository's per-plugin versioning or release-tag policy.

There is also an ecosystem difference to account for: Dependabot supports production/development dependency classification for uv, but Cargo supports only direct/indirect/all filtering, not production/development filtering. Selective Cargo release impact therefore needs repository-owned dependency-graph analysis rather than Dependabot configuration alone.

References:

• Dependabot options reference
• Automating Dependabot with GitHub Actions
• Multi-ecosystem dependency groups

Desired behavior

1. Treat every managed plugin as eligible for automatic dependency releases. There is no per-plugin allowlist: whether a plugin is updated depends only on whether the dependency update changes its production dependency closure.

2. For each dependency PR, compare the base and head dependency graphs and identify every plugin with a changed production dependency closure:

   • Cargo: normal dependencies used by the published feature set, including reachable transitive dependencies;
   • Python: [project.dependencies] and reachable transitive dependencies from the applicable uv lockfile;
   • exclude Rust dev-dependencies, Python development dependency groups, benchmarks/tests, build tooling, and GitHub Actions;
   • do not treat unrelated lockfile churn as a production impact.

3. Report the selected plugins and the reason for each selection, including ecosystem, dependency name, and direct/transitive relationship.

4. Apply one patch-version bump to each selected plugin and keep all required version sources consistent:

   • plugins/rust/python-package/<slug>/Cargo.toml;
   • plugins/rust/python-package/<slug>/cpex_<slug>/plugin-manifest.yaml;
   • Cargo.lock.

5. Feed those bumps through the existing CI flow. Its release validation, tag creation, and PyPI publication should remain the only release path.

6. Make the automation idempotent: a Dependabot rebase, force-push, or workflow rerun must not increment a plugin version more than once for the same dependency PR.

The version-bump commit may be added to the verified Dependabot PR, or a follow-up release PR may be generated and set to auto-merge after required checks. The implementation must not execute untrusted PR-head code with elevated pull_request_target permissions or bypass branch protection.

Suggested implementation

• Extend tools/plugin_catalog.py with a dependency-impact command that emits stable JSON, for example:

  {
    "plugins": [
      {
        "slug": "rate_limiter",
        "changes": [
          {"ecosystem": "cargo", "dependency": "redis", "relationship": "direct"}
        ]
      }
    ]
  }
  

• Base Cargo selection on resolved metadata/graph edges instead of changed-file paths. Map workspace dependencies only to plugins that consume them in their production graph.

• Base uv selection on each plugin's published project dependencies and the correct root or standalone lockfile.

• Add a reusable version-bump command so the workflow and maintainers use the same consistency rules.

• Trigger automatically for verified dependabot[bot] PRs, with a manual workflow input or label available for non-Dependabot dependency PRs.

Acceptance criteria

• Every managed plugin is automatically eligible; no per-plugin allowlist is required.
• A production dependency used only by one plugin bumps and releases only that plugin.
• A shared production dependency bumps every plugin that actually consumes it, and no others.
• Direct and transitive production dependency updates are detected for Cargo and uv.
• Dev/test/benchmark/build-tooling/GitHub Actions-only updates do not bump plugin versions.
• Grouped Dependabot PRs affecting multiple dependencies/ecosystems produce one correct, deduplicated plugin set.
• Version bumps are patch bumps by default and update Cargo.toml, plugin-manifest.yaml, and Cargo.lock consistently.
• Workflow reruns and Dependabot rebases do not double-bump versions.
• Required CI and release validation pass before any tag or PyPI publication occurs.
• After merge to main, the existing workflow creates one release tag and publishes one new package version per affected plugin.
• Focused tests cover single-plugin, shared-dependency, transitive-dependency, dev-only, unrelated-lockfile, and idempotency cases.
• DEVELOPING.md and MAINTENANCE.md document the automatic release policy.