Repository navigation
Add a reusable workflow for dependency upgrade analysis and fixes #1287
Description
Build a central agentic workflow that reviews dependency upgrade PRs across our repositories.
Start with Dependabot. When Dependabot opens or updates a PR, the workflow should:
- Check the upgrade against APIs that the repository uses.
- Flag deprecated or removed APIs.
- Suggest replacement APIs and migration steps.
- Identify breaking behavior and relevant new features.
- Link to release notes, changelogs, or migration guides.
- State what it could not verify.
If the upgrade needs clear code changes, the workflow should open a linked draft PR with those changes. It must not approve or merge either PR.
Use the CentralRepoOps pattern. Keep the main workflow in one repository and add a small trigger to each target repository.
Reuse the existing periodic Copilot-assisted tool where practical. Refactor it into a local-authentication bridge if cross-repository changes require one.
Support Dependabot first, but keep the analysis independent of the update tool. Decide whether to use Renovate in separate work.
Repeated runs must update the existing comment or draft PR instead of creating duplicates. Cross-repository access must use the minimum required permissions.
Reference adoptium modernize audit
Activity
michelle-clayton-work commentedon Oct 22, 2026
My understanding of the adoptium reference is that it runs a scheduled audit of the current dependency versions and code, rather than reviewing Dependabot PRs or scanning Git history. That would work with Dependabot, Renovate, or manual updates, and we wouldn't need to track the last checked commit.
The other option is checking Git history since the last successful review, so each run focuses on new dependency changes instead of repeating the full audit. We'd need to save a checkpoint for that. Either way, we'd catch things after they land rather than before merge.
Also, should we follow that setup for results? They create a new tracking issue each audit and close the previous one, then use a separate manual workflow to open draft PRs for selected findings. Or would you rather have one ongoing issue per repo that we keep updated?
Does anyone have any strong feelings?
CC: George Adams (@gdams) Davis Goodin (@dagood) Quim Muntal (@qmuntal)