Resolver workflow: Added support for processing issues/PRs in other repos #5778
Conversation
…processing. Added parameters for issue number, type, target repository owner, and name, along with a comment ID. Updated environment variable handling to accommodate new inputs and ensure proper repository context during execution.
… repository context. Updated pull request and branch creation commands to reference TARGET_REPO_OWNER and TARGET_REPO_NAME, ensuring consistent behavior across different repositories. Improved error handling comments with dynamic links to the created branches and workflow logs.
…eferences. Updated pull request creation commands to streamline the process and enhance flexibility by relying on environment variables for repository context. This change improves the maintainability of the workflow and ensures consistent behavior across different repositories.
…or repository context in error handling. Changed hardcoded references to TARGET_REPO_OWNER and TARGET_REPO_NAME, enhancing flexibility and maintainability of the workflow. This aligns with previous refactoring efforts to streamline repository interactions.
…fy the workflow. This change eliminates unnecessary parameters related to issue processing, streamlining the execution process and enhancing maintainability.
…ent. This addition allows manual triggering of the workflow, improving flexibility in issue resolution processes.
… type via workflow_call Fix comment location Update openhands-resolver workflow to trigger on 'workflow_call' event.
There was a problem hiding this comment.
Thanks a ton for this! I'd like to understand the motivation behind this PR more deeply -
-
Do you envision having a dummy repo where you can invoke the resolver on other repos? We're planning on enabling the resolver to run on forked repos via a Github App, but this PR could be super helpful in providing an alternate option. LMK!
-
It would also be helpful to have an example workflow which calls this one, similar to the example resolver
| @@ -69,7 +89,9 @@ jobs: | |||
| contains(github.event.review.body, inputs.macro || '@openhands-agent') && | |||
| (github.event.review.author_association == 'OWNER' || github.event.review.author_association == 'COLLABORATOR' || github.event.review.author_association == 'MEMBER') | |||
| ) | |||
| ) | |||
| ) || | |||
| github.workflow_ref != '' | |||
There was a problem hiding this comment.
I'm a little uncertain of including this here; for instance on Openhands we only want maintainers to run the resolver (because of LLM API costs)
Will this be behavior be preserved?
There was a problem hiding this comment.
I believe this will only be populated if this workflow is being called by another workflow (and it would be billed to the repo that the calling workflow exists in).
Yes, that's exactly right, I have a queue-manger workflow (because Github only allows you to queue up to 2 workflow runs using the concurrency feature). I need to run the workflows sequentially otherwise I run into rate limits from Anthropic etc.
Sure I'm still polishing that but I can share when it's ready! |
…or issue handling. This change improves the logic for setting environment variables by checking for input parameters before handling pull request events, ensuring more accurate issue tracking.
… Python Command" in UI (All-Hands-AI#5749) Co-authored-by: Graham Neubig <[email protected]>
…ands-AI#5703) Co-authored-by: openhands <[email protected]>
…l group (All-Hands-AI#5820) Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Graham Neubig <[email protected]>
…nds-AI#5828) Co-authored-by: openhands <[email protected]>
…unction calling (All-Hands-AI#5824) Co-authored-by: Engel Nyst <[email protected]>
Co-authored-by: openhands <[email protected]>
End-user friendly description of the problem this fixes or functionality that this introduces
Give a summary of what the PR does, explaining any non-trivial design decisions
Resolver workflow: Added support for processing issues/PRs in other repos. This enables more powerful usage of this workflow. It also allows the workflow to be triggered not directly by the issues or PRs, which enables support for a scheduler.
Link of any specific issues this addresses