Python: consolidate dependency maintenance workflow

[eavanvalkenburg]

Motivation & Context

Python dependency updates need to be coordinated across the uv workspace because dependency declarations can appear in multiple pyproject.toml files while the workspace has one shared python/uv.lock. Separate automation PRs for dev dependency updates and dependency range updates can conflict with each other and require unnecessary rebasing.

This change consolidates Python dependency maintenance into one scheduled/manual workflow that updates and validates the generated dependency state together. Python Dependabot stays as a temporary Thursday fallback until the new workflow has proven reliable.

Description & Review Guide

• What are the major changes? Add a single Python - Dependency Maintenance workflow that runs Mondays at 04:00 UTC, folds in dev dependency repinning and dependency upper-bound validation, applies a 7-day dependency release cutoff, and opens/updates one automation PR.
• What is the impact of these changes? The weekly Python automation produces at most one dependency PR and avoids newly published packages by using UV_EXCLUDE_NEWER plus matching PyPI upload-time filtering. If upper-bound validation fails, the workflow keeps only dev dependency updates that still pass final checks and creates issues for failed range candidates.
• What do you want reviewers to focus on? Review the fallback behavior for failed range validation, the schedule/Dependabot overlap, and whether the generated PR body follows the repository template closely enough for automation.

Related Issue

Fixes #6569

No other open PR was found for this issue.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

[github-actions]

Automated Code Review

Reviewers: 5 | Confidence: 92%

✓ Correctness

This PR consolidates two Python dependency maintenance workflows into one scheduled workflow that runs Mondays at 04:00 UTC, with Dependabot shifted to Thursday as a temporary fallback. The workflow logic is well-structured: it repins dev dependencies first, saves them as a patch, runs bounds validation, falls back to dev-only changes if validation fails, and runs final checks before committing. All referenced poe tasks (upgrade-dev-dependency-pins, validate-dependency-bounds-test, validate-dependency-bounds-project) exist in pyproject.toml. The conditional logic using steps.*.outcome correctly distinguishes actual failure from continue-on-error conclusion. The heredoc indentation is correctly handled by YAML block scalar stripping. No correctness bugs found.

✓ Security Reliability

This PR consolidates Python dependency maintenance into a single scheduled workflow. From a security and reliability perspective, the workflow is well-structured: it uses pinned action SHAs, GITHUB_TOKEN (not a PAT), hardcoded branch/title strings (no injection surfaces), proper concurrency controls, and --force-with-lease for pushes. The fallback logic correctly handles skipped/failed validation steps, the github-script step gracefully handles missing report files, and the final checks gate PR creation. No significant security or reliability issues found.

✓ Test Coverage

This PR consolidates two GitHub Actions workflows (python-dev-dependency-upgrade.yml and python-dependency-range-validation.yml) into a single python-dependency-maintenance.yml workflow, and shifts Dependabot to Thursday as a fallback. No application or library code is modified. The underlying dependency scripts (upgrade_dev_dependencies.py, validate_dependency_bounds.py) are pre-existing and unchanged. While those scripts lack dedicated unit tests, that is a pre-existing condition unrelated to this PR. The workflow itself includes integration-level validation gates (install, check, typing) that run before committing, which is appropriate for CI workflow changes. No new testable behavior is introduced that lacks coverage.

✓ Failure Modes

The consolidated dependency maintenance workflow is logically sound. Step conditions correctly handle all combinations of validation outcomes (success, failure, skipped). The patch save/restore pattern works because the dev patch is always relative to HEAD, and git restore without --source defaults to the index which matches HEAD (nothing is staged). Final checks (install, check, typing) run unconditionally without continue-on-error, ensuring broken state is never committed. No silent failure paths, swallowed exceptions, or partial-write scenarios were identified.

✗ Design Approach

The consolidation mostly hangs together, but the new workflow adds a second fallback path that is not wired into the existing diagnostics flow. If the new repo-wide bounds smoke test fails, the workflow now skips upper-bound probing, reverts to dev-only changes, and can still open a PR — yet the issue-creation step only reads the upper-bound report, so that failure mode is left untracked.

Flagged Issues

• The new validate_bounds_test fallback path is not surfaced to issue creation: when the smoke gate fails (line 70), upper-bound validation is skipped, and the workflow falls back to a dev-only PR (lines 199-208), but the issue-creation step (lines 91-95) returns early unless dependency-range-results.json exists. A real Monday failure can silently degrade into a dev-only PR with no actionable issue explaining why range maintenance stopped.

Suggestions

• Either create issues from dependency-bounds-test-results.json when validate_bounds_test fails, or do not take the dev-only fallback on that path. As written, lines 62-72, 85-95, and 199-208 introduce a new failure mode without any tracking artifact.

---

Automated review by eavanvalkenburg's agents

[github-actions]

Flagged issue

The new validate_bounds_test fallback path is not surfaced to issue creation: when the smoke gate fails (line 70), upper-bound validation is skipped, and the workflow falls back to a dev-only PR (lines 199-208), but the issue-creation step (lines 91-95) returns early unless dependency-range-results.json exists. A real Monday failure can silently degrade into a dev-only PR with no actionable issue explaining why range maintenance stopped.

---

Source: automated DevFlow PR review

[Copilot]

Pull request overview

This PR consolidates Python dependency maintenance for the uv workspace into a single scheduled/manual GitHub Actions workflow, reducing conflicting automation PRs while keeping Dependabot as a temporary fallback.

Changes:

• Reworks the existing dependency-range validation workflow into Python - Dependency Maintenance (scheduled Mondays 04:00 UTC + manual), combining dev pin repinning, bounds test scenarios, upper-bound validation, reporting, issue creation, and PR updates.
• Removes the standalone Python - Dev Dependency Upgrade workflow in favor of the consolidated workflow.
• Moves Python Dependabot runs to Thursdays to avoid overlapping with the new Monday workflow, while retaining Dependabot as a fallback.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
.github/workflows/python-dev-dependency-upgrade.yml	Removes the dedicated dev-dependency upgrade workflow now covered by the consolidated maintenance workflow.
.github/workflows/python-dependency-maintenance.yml	Implements the consolidated scheduled/manual dependency maintenance workflow, including fallback behavior and PR/issue automation.
.github/dependabot.yml	Shifts Python Dependabot schedules to Thursday as a temporary fallback alongside the new workflow.

Comments suppressed due to low confidence (3)

.github/workflows/python-dependency-maintenance.yml:54

• The quoted glob in this git diff relies on Git pathspec globbing being enabled; if core.globPathspec is ever disabled, this can fail (or silently omit package pyproject.toml changes). Using explicit :(glob) pathspec magic makes the intent unambiguous and consistent with the other git commands below.
  .github/workflows/python-dependency-maintenance.yml:207
• This glob is expanded by the shell. If python/packages/*/pyproject.toml ever matches nothing, Bash will pass the literal pattern to git restore, which then errors with "pathspec did not match" and fails the workflow. Consider using Git's :(glob) pathspec magic to avoid shell expansion and make the behavior deterministic.
  .github/workflows/python-dependency-maintenance.yml:237
• Same shell-glob expansion risk as the git restore step: if the glob ever matches nothing, git add will fail. Using :(glob) keeps this stable and aligned with the diff/restore pathspecs.

[moonbox3]

From a security perspective, should we avoid exposing the write-capable GITHUB_TOKEN to the dependency resolution and validation steps? This job installs and executes newly selected PyPI versions, and those subprocesses inherit GH_TOKEN while it has contents/issues/PR write permissions. Could we scope the token only to the issue, push, and PR publishing steps instead of at this current level?