fix(ci): align ready-for-dev gates with OpenHands pipefail-safe approach - #4607
Draft
neubig wants to merge 1 commit into
Draft
fix(ci): align ready-for-dev gates with OpenHands pipefail-safe approach#4607neubig wants to merge 1 commit into
neubig wants to merge 1 commit into
Conversation
Bring the ready-for-dev readiness gates in line with the current OpenHands/OpenHands approach while keeping the SDK-specific reproduction criteria (python/pytest/uv/pip for bugs, Desired Behavior + Acceptance Criteria for enhancements): - check_issue_readiness.py exits 1 for not-ready issues in both text and --json modes; the workflow absorbs it with `|| true` so `set -euo pipefail` no longer aborts the run before label/comment handling, and JSON output stays machine-readable. - Post the upserted readiness comment when the ready-for-dev label is applied manually (labeled event), not only on open/reopen/transition. - Share a markdown_sections helper that ignores headings and HUMAN:/AGENT: markers inside fenced code blocks in both the issue readiness and PR description checks, so pasted logs or quoted templates cannot create or spoof sections. - Keep the SDK-specific linked-PR gate refresh job and the PR description ready-for-dev enforcement unchanged. Tests cover ready/not-ready JSON execution (exit code + parseable JSON), fenced-heading parsing, and label add/remove transitions refreshing linked PR gates. Fixes #4605 Co-authored-by: openhands <openhands@all-hands.dev>
Contributor
Python API breakage checks — ✅ PASSEDResult: ✅ PASSED |
Contributor
REST API breakage checks (OpenAPI) — ✅ PASSEDResult: ✅ PASSED |
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
HUMAN:
AGENT:
This PR was created by an AI agent (OpenHands) on behalf of the user.
Why
Issue #4605 asks to bring this repository's
ready-for-devprocess in line with the current OpenHands/OpenHands approach while keeping the SDK-specific reproduction guidance. Concretely, the readiness evaluator must not fail the workflow merely because an issue is not ready when the workflow runs underset -euo pipefail, JSON mode must stay machine-readable, readiness comments must remain upserted, linked PR readiness checks must refresh when the label changes, and linked-PR readiness must be enforced in CI via the existing PR description check.Summary
check_issue_readiness.pynow exits1for a not-ready issue in both text and--jsonmodes (uniform exit semantics, matching OpenHands/OpenHands #16514); the workflow step absorbs it with|| truesoset -euo pipefailcannot abort the run before label add/remove and comment handling. JSON output remains machine-readable on stdout.labeledevents forready-for-dev(matching OpenHands/OpenHands #16830), so a manually applied label produces an upserted confirmation/explanation comment..github/scripts/markdown_sections.pyhelper (ported from OpenHands/OpenHands #16595) masks fenced code blocks; bothcheck_issue_readiness.pyandcheck_pr_description.pynow ignore###/##headings andHUMAN:/AGENT:markers inside fences, so pasted logs or quoted templates cannot create or spoof sections.python/pytest/uv/pipcommand in Actual Behavior; enhancements require Desired Behavior; both require an Acceptance Criteria checklist. The SDK-specific linked-PR gate refresh job (refresh-linked-pr-gates+refresh_linked_pr_checks.py) and PR-descriptionready-for-devenforcement (with the pre-rollout grandfathering) are unchanged.Issue Number
Fixes #4605
How to Test
uv run pytest tests/cross/test_check_issue_readiness.py tests/cross/test_check_pr_description.py tests/cross/test_refresh_linked_pr_checks.py -q— 43 passed. New tests cover ready/not-ready--jsonexecution (exit code + parseable JSON), fenced-heading parsing, quoted-template HUMAN/AGENT markers, and label add/remove transitions refreshing linked PR gates.set -euo pipefailwith ready and not-ready event payloads: both complete the step and produceready=true/ready=falseplus the reasons file, so label/comment handling always runs.uv run pre-commit run --files <changed files>— all hooks pass (ruff, pycodestyle, pyright, yamlfmt, import rules).tests/crossrun: 405 passed; the only failures aretest_remote_conversation_live_server.pycases, which fail locally because the sandbox shell itself runs inside the same tmux server those tests tear down — they are unrelated to this change (no SDK code paths touched) and run on isolated CI runners.Video/Screenshots
N/A — CI/workflow-only change.
Design Doc
N/A
Type
Notes
@neubig can click here to continue refining the PR
🐳 Agent Server images for this PR — GHCR package, pull/run commands, and all pushed tags (click to expand)
• 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:d9089a9-pythonRun
All tags pushed for this build
About Multi-Architecture Support
d9089a9-python) is a multi-arch manifest supporting both amd64 and arm64d9089a9-python-amd64) are also available if needed