chore(deps): bump lewagon/wait-on-check-action from 1.6.0 to 1.7.0

[dependabot]

Bumps lewagon/wait-on-check-action from 1.6.0 to 1.7.0.

Release notes

Sourced from lewagon/wait-on-check-action's releases.

v1.7.0

Fixed

• Fix the failure exit codes (#147)

v1.6.1

Added

• Pin the ruby/setup-ruby version (#143)

Changelog

Sourced from lewagon/wait-on-check-action's changelog.

v1.7.0 - 2026-04-14

Fixed

• Fix the failure exit codes

v1.6.1 - 2026-04-06

Added

• Pin the ruby/setup-ruby version

Commits

• 9312864 Bump version: 1.6.1 → 1.7.0
• 51f09d0 Add v1.7.0 changelog notes (#148)
• be22c84 fix: exit with non-zero status when check conclusions are disallowed (#147)
• 78dd4dd Bump version: 1.6.0 → 1.6.1
• 0b3a86b Add v1.6.1 changelog notes (#144)
• b6990d0 Pin ruby/setup-ruby to the v1.299.0 sha (#143)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

--- **Agent Server images for this PR**

• GHCR package: https://github.com/OpenHands/agent-sdk/pkgs/container/agent-server

Variants & Base Images

Variant	Architectures	Base Image	Docs / Tags
java	amd64, arm64	eclipse-temurin:17-jdk	Link
python	amd64, arm64	nikolaik/python-nodejs:python3.13-nodejs22-slim	Link
golang	amd64, arm64	golang:1.21-bookworm	Link

Pull (multi-arch manifest)

# Each variant is a multi-arch manifest supporting both amd64 and arm64
docker pull ghcr.io/openhands/agent-server:46791e5-python

Run

docker run -it --rm \
  -p 8000:8000 \
  --name agent-server-46791e5-python \
  ghcr.io/openhands/agent-server:46791e5-python

All tags pushed for this build

ghcr.io/openhands/agent-server:46791e5-golang-amd64
ghcr.io/openhands/agent-server:46791e5-golang_tag_1.21-bookworm-amd64
ghcr.io/openhands/agent-server:46791e5-golang-arm64
ghcr.io/openhands/agent-server:46791e5-golang_tag_1.21-bookworm-arm64
ghcr.io/openhands/agent-server:46791e5-java-amd64
ghcr.io/openhands/agent-server:46791e5-eclipse-temurin_tag_17-jdk-amd64
ghcr.io/openhands/agent-server:46791e5-java-arm64
ghcr.io/openhands/agent-server:46791e5-eclipse-temurin_tag_17-jdk-arm64
ghcr.io/openhands/agent-server:46791e5-python-amd64
ghcr.io/openhands/agent-server:46791e5-nikolaik_s_python-nodejs_tag_python3.13-nodejs22-slim-amd64
ghcr.io/openhands/agent-server:46791e5-python-arm64
ghcr.io/openhands/agent-server:46791e5-nikolaik_s_python-nodejs_tag_python3.13-nodejs22-slim-arm64
ghcr.io/openhands/agent-server:46791e5-golang
ghcr.io/openhands/agent-server:46791e5-java
ghcr.io/openhands/agent-server:46791e5-python

About Multi-Architecture Support

• Each variant tag (e.g., 46791e5-python) is a multi-arch manifest supporting both amd64 and arm64
• Docker automatically pulls the correct architecture for your platform
• Individual architecture tags (e.g., 46791e5-python-amd64) are also available if needed

[github-actions]

Python API breakage checks — ✅ PASSED

Result: ✅ PASSED

Action log

[github-actions]

REST API breakage checks (OpenAPI) — ✅ PASSED

Result: ✅ PASSED

Action log

[all-hands-bot]

[Automatic Post]: I have assigned @DevinVinson as a reviewer based on git blame information. Thanks in advance for the help!

[enyst]

@OpenHands I need you to do two things:

1. make a review of this PR, check CI, check upstream, with an eye for supply chain attacks. Use review with gh api and event. If you approve it, merge it, if you don't, ok just summarize. /codereview
2. find the workflow that created this comment: chore(deps): bump lewagon/wait-on-check-action from 1.6.0 to 1.7.0 #2842 (comment) and explain to us what reviewers was it supposed to assign. We're a bit surprised that it assigned a reviewer who has never committed on this repo so it's not in git blame, wdyt? What perms do they have on the repo? Link the prompt to me in a comment you make on github.

[openhands-ai]

I'm on it! enyst can track my progress at all-hands.dev

[enyst]

@enyst I traced the reviewer-assignment comment to the scheduled Assign Reviews workflow run from 2026-04-18 12:22 UTC.

Prompt permalink used by that run:

• software-agent-sdk/.github/workflows/assign-reviews.yml

  Lines 36 to 135 in 390584d

  	PROMPT_STRING: >
  	Use GITHUB_TOKEN and the github API to organize open pull requests and issues in the repo.
  	Read the sections below in order, and perform each in order. Do NOT take action
  	on the same issue or PR twice.
  	# Issues with needs-info - Check for OP Response
  	Find all open issues that have the "needs-info" label. For each issue:
  	1. Identify the original poster (issue author)
  	2. Check if there are any comments from the original poster AFTER the "needs-info" label was added
  	3. To determine when the label was added, use: GET /repos/{owner}/{repo}/issues/{issue_number}/timeline
  	and look for "labeled" events with the label "needs-info"
  	4. If the original poster has commented after the label was added:
  	- Remove the "needs-info" label
  	- Add the "needs-triage" label
  	# Issues with needs-triage
  	Find all open issues that have the "needs-triage" label. For each issue that has been in this state for more than 2 days:
  	1. First, check if the issue has already been triaged by verifying it does NOT have:
  	- The "enhancement" label
  	- Any "priority" label (priority:low, priority:medium, priority:high, etc.)
  	2. If the issue has already been triaged (has enhancement or priority label), remove the "needs-triage" label
  	3. For issues that have NOT been triaged yet:
  	- Read the issue description and comments
  	- Check if it is a bug report, feature request, or question and add the appropriate label
  	- If it is a bug report and it does not have a priority label
  	* Read the MAINTAINERS file in the repository root to get the list of maintainers
  	* Extract all usernames from lines starting with "- @" and join them with spaces, each prefixed with @
  	(e.g., if the file contains "- @user1" and "- @user2", format as "@user1 @user2")
  	* Tag ALL maintainers with: "[Automatic Post]: This issue has been waiting for triage. <maintainers>, could you
  	please take a look and add the appropriate priority label when you have a chance?"
  	(Replace <maintainers> with the formatted list from the previous step)
  	# Need Reviewer Action
  	Find all open PRs where:
  	1. The PR is waiting for review (there are no open review comments or change requests)
  	2. The PR is in a "clean" state (CI passing, no merge conflicts)
  	3. The PR is not marked as draft (draft: false)
  	4. The PR has had no activity (comments, commits, reviews) for more than 3 days.
  	In this case, send a message to the reviewers:
  	[Automatic Post]: This PR seems to be currently waiting for review.
  	{reviewer_names}, could you please take a look when you have a chance?
  	# Need Author Action
  	Find all open PRs where the most recent change or comment was made on the pull
  	request more than 5 days ago (use 14 days if the PR is marked as draft).
  	And send a message to the author:
  	[Automatic Post]: It has been a while since there was any activity on this PR.
  	{author}, are you still working on it? If so, please go ahead, if not then
  	please request review, close it, or request that someone else follow up.
  	# Need Reviewers
  	Find all open pull requests that TRULY have NO reviewers assigned. To do this correctly:
  	1. Use the GitHub API to fetch PR details: GET /repos/{owner}/{repo}/pulls/{pull_number}
  	2. Check the "requested_reviewers" and "requested_teams" arrays
  	3. ALSO check for submitted reviews: GET /repos/{owner}/{repo}/pulls/{pull_number}/reviews
  	4. A PR needs reviewers ONLY if ALL of these are true:
  	- The "requested_reviewers" array is empty (no pending review requests)
  	- The "requested_teams" array is empty (no pending team review requests)
  	- The reviews array is empty (no reviews have been submitted yet)
  	5. IMPORTANT: If ANY of these has entries, SKIP this PR - it already has or had reviewers!
  	Example API responses showing a PR that DOES NOT need reviewers (skip this):
  	Case 1 - Has requested reviewers:
  	GET /pulls/{number}: {"requested_reviewers": [{"login": "someuser"}], "requested_teams": []}
  	Case 2 - Has submitted reviews (even if requested_reviewers is empty):
  	GET /pulls/{number}: {"requested_reviewers": [], "requested_teams": []}
  	GET /pulls/{number}/reviews: [{"user": {"login": "someuser"}, "state": "COMMENTED"}]
  	Example API response showing a PR that DOES need reviewers (process this):
  	GET /pulls/{number}: {"requested_reviewers": [], "requested_teams": []}
  	GET /pulls/{number}/reviews: []
  	Additional criteria for PRs that need reviewers:
  	1. Are not marked as draft (draft: false)
  	2. Were created more than 1 day ago
  	3. CI is passing and there are no merge conflicts
  	For each PR that truly has NO reviewers:
  	1) Read git blame for changed files to identify recent, active contributors.
  	2) From those candidates, ONLY consider maintainers — repository collaborators with write access or higher. Verify via the GitHub API before
  	requesting review:
  	- Preferred: GET /repos/{owner}/{repo}/collaborators (no permission filter). Filter client-side using either:
  	role_name in ["write", "maintain", "admin"] OR permissions.push || permissions.admin. Note: paginate if > 30 collaborators.
  	- Alternative: GET /repos/{owner}/{repo}/collaborators/{username}/permission and accept if permission in {push, maintain, admin}.
  	3) If multiple maintainers qualify, avoid assigning too many reviews to any single one.
  	4) Request review from exactly one maintainer and add this message:
  	[Automatic Post]: I have assigned {reviewer} as a reviewer based on git blame information.
  	Thanks in advance for the help!

What that prompt was supposed to do for reviewer assignment:

• only process PRs with no requested reviewers, no requested teams, and no submitted reviews
• use git blame on changed files to find recent contributors
• keep only contributors who are repo collaborators with write+ access
• request review from exactly one such maintainer

What the workflow actually did on PR #2842 according to the run logs:

• git blame on the changed workflow file only surfaced Graham Neubig
• after collaborator filtering, maintainer_contributors was empty
• the generated script then took an extra fallback path: "No maintainer contributors found - using least loaded maintainer"
• it had just assigned @saurya to PR chore(deps): bump actions/github-script from 8 to 9 #2843, then picked @DevinVinson for PR chore(deps): bump lewagon/wait-on-check-action from 1.6.0 to 1.7.0 #2842 as the next least-loaded maintainer

So I think your surprise is justified: for this PR, the final assignment was not really blame-driven. It was a fallback/load-balancing decision once no blame-derived maintainer survived filtering. That fallback is visible in the execution logs, but it is not explicitly stated in the prompt above.

On permissions: @DevinVinson currently has repo role write (push=true, triage=true, pull=true, maintain=false, admin=false). I also could not find any authored commits from that username in this repo history, which lines up with your observation.

If we want this workflow to behave more predictably, I’d tighten it so that when no blame-derived maintainer can be resolved, it either (a) assigns nobody, or (b) clearly says it is falling back to a load-balanced maintainer pool.

AI note: this comment was generated by OpenHands on behalf of @enyst.

[enyst]

🟢 Good taste

I checked the PR diff, the full CI matrix, and the upstream lewagon/wait-on-check-action changes from v1.6.0...v1.7.0 with a supply-chain lens.

• Repo diff is exactly one-line: .github/workflows/run-examples.yml bumps the action tag from v1.6.0 to v1.7.0.
• CI is green: all checks completed successfully on this PR.
• Upstream diff is small and unsurprising: the main functional change is fixing non-zero exit behavior when disallowed check conclusions are seen; the intermediate v1.6.1 also improves supply-chain posture by pinning ruby/setup-ruby to a commit SHA inside the action.
• I inspected action.yml, entrypoint.rb, and the verifier patch and did not see new exfiltration behavior or privilege expansion beyond the existing GitHub-token-based check polling.
• Remaining supply-chain caveat: this repo still consumes the action by mutable tag (@v1.7.0) rather than a full commit SHA, but that risk predates this PR and is not worsened here.

[RISK ASSESSMENT]

• [Overall PR] ⚠️ Risk Assessment: 🟡 MEDIUM
  Third-party CI action bumps always carry some supply-chain risk, but this delta is narrow, CI is fully green, and the upstream change actually tightens one internal dependency pin.

VERDICT:
✅ Worth merging

KEY INSIGHT:
This bump is a small CI-only update that mainly fixes upstream failure signaling and slightly improves the action's own dependency pinning.

AI note: this review was generated by OpenHands on behalf of @enyst.

[openhands-ai]

Final summary:

• Reviewed PR chore(deps): bump lewagon/wait-on-check-action from 1.6.0 to 1.7.0 #2842 with a supply-chain/security lens.
• Verified the repo diff was minimal: only .github/workflows/run-examples.yml changed, bumping lewagon/wait-on-check-action from v1.6.0 to v1.7.0.
• Checked upstream v1.6.0...v1.7.0: the meaningful change was the exit-code fix, and v1.6.1 also improved upstream pinning by locking ruby/setup-ruby to a commit SHA.
• Waited for and confirmed full CI passed.
• Submitted an APPROVE review on GitHub.
• Added a GitHub comment linking the exact workflow prompt and explaining the reviewer assignment behavior.
• Investigated the reviewer assignment comment source and confirmed it came from the scheduled Assign Reviews workflow run 24604578646.
• Determined the assignment was not truly blame-driven for this PR: git blame found Graham Neubig, but no blame-derived maintainer qualified, so the generated script fell back to a least-loaded maintainer path and selected @DevinVinson.
• Checked @DevinVinson's repo permissions: they have write access (push=true, triage=true, pull=true, not maintain/admin).
• Merged the PR after approval via squash merge.

Conciseness:

• Yes — no repository code changes were made beyond merging the existing Dependabot PR.
• The only new external actions were the GitHub review and explanatory comment, both directly requested and relevant.