Revert "fix(ci): stop re-labeling unrelated PRs for old Field defaults"#3406
Revert "fix(ci): stop re-labeling unrelated PRs for old Field defaults"#3406enyst wants to merge 2 commits into
Conversation
|
✅ Review complete. This review was performed through OpenHands Cloud Automation. You can log in and view the conversation here. |
all-hands-bot
left a comment
There was a problem hiding this comment.
Review: Revert "fix(ci): stop re-labeling unrelated PRs for old Field defaults"
This is a clean, surgical revert of PR #3329. The motivation is clear and well-documented: the field_default_changes_since_base logic introduced a merge conflict on the release PR #3401, and the fastest safe path to unblock the release is to revert.
What was reverted
PR #3329 added a "two-view" comparison to the API breakage workflow:
- View 1 (vs PyPI baseline): for compatibility reporting
- View 2 (vs PR base ref via
git archive): for deciding whether to add/remove therelease-note-requiredlabel, so unrelated follow-up PRs wouldn't be re-labeled for defaults that were already changed onmain
This revert removes that entire mechanism — the _get_base_ref, _git_archive_directory, _load_from_git_ref, _collect_field_default_changes_since_ref helpers; the field_defaults_only/emit_diagnostics parameters throughout; and the corresponding YAML workflow sections and tests.
Assessment
✅ Correctness — all additions from #3329 are properly removed. The inlined (f"origin/{ref}", ref) tuple that replaces the now-deleted _git_ref_candidates() helper is functionally identical. No orphaned callsites or references remain.
✅ Test coverage — the four tests that exercised _collect_field_default_changes_since_ref and the updated _write_field_default_change_report signature are correctly removed along with the functions they tested. No tests for live code were dropped.
✅ AGENTS.md — the guidance line for the two-view approach is cleanly removed, keeping the doc consistent with the code.
Field(default=...) value themselves may again be re-labeled release-note-required if they branch off a main that already contains an unreleased default change. This was the problem #3329 fixed. It is an acceptable short-term regression to unblock the release; a re-implementation after the release cycle is recommended.
Verdict
Approved. The revert is correct, complete, and well-scoped. Merge when CI is green.
This review was generated by an AI agent (OpenHands) on behalf of the user through OpenHands Automation. View conversation
all-hands-bot
left a comment
There was a problem hiding this comment.
🟢 Good taste — surgical revert, no new blocking issues found.
[RISK ASSESSMENT]
- [Overall PR]
⚠️ Risk Assessment: 🟡 MEDIUM — CI automation behavior is intentionally rolled back, but SDK/runtime behavior is untouched and the release-unblock trade-off is clearly documented.
VERDICT: ✅ Worth merging
This review was created by an AI agent (OpenHands) on behalf of the user.
Was this automated review useful? React with 👍 or 👎 to this review to help us measure review quality.
Workflow run: https://github.com/OpenHands/software-agent-sdk/actions/runs/26520252889
Summary
38e698b6799faf0449a2bfaa7da0024dc03026ffmain, the release PR can merge cleanly againValidation
uv run pre-commit run --files .github/scripts/check_sdk_api_breakage.py .github/workflows/api-breakage.yml AGENTS.md tests/cross/test_check_sdk_api_breakage.pygit merge-tree --write-tree --name-only --messages HEAD origin/rel-1.24.0exits cleanlyThis PR was created by an AI agent (OpenHands) on behalf of the user.
@enyst can click here to continue refining the PR
Agent Server images for this PR
• GHCR package: https://github.com/OpenHands/agent-sdk/pkgs/container/agent-server
Variants & Base Images
eclipse-temurin:17-jdknikolaik/python-nodejs:python3.13-nodejs22-slimgolang:1.21-bookwormPull (multi-arch manifest)
# Each variant is a multi-arch manifest supporting both amd64 and arm64 docker pull ghcr.io/openhands/agent-server:d9f8a55-pythonRun
All tags pushed for this build
About Multi-Architecture Support
d9f8a55-python) is a multi-arch manifest supporting both amd64 and arm64d9f8a55-python-amd64) are also available if needed