fix(scripts): query workflow runs by branch name instead of pull_requests field#3794
fix(scripts): query workflow runs by branch name instead of pull_requests field#3794
Conversation
…ests field The pull_requests field in the GitHub API's workflow runs endpoint is often empty for recent runs, causing deploy-pr-to-beta to fail to locate the workflow run. Query by the PR's head branch name instead, which is reliably populated. Fixes: deploy-pr-to-beta script unable to find canister-tests.yml runs for PRs
There was a problem hiding this comment.
Pull request overview
Updates deploy-pr-to-beta to locate the relevant GitHub Actions workflow run by PR head branch name instead of relying on the pull_requests field (often empty for recent runs), improving reliability when selecting runs to deploy from.
Changes:
- Fetch PR head branch name via
gh pr viewand use it to filter workflow runs. - Adjust workflow runs API query and
jqfiltering to match runs byhead_branchand workflow file path.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| | jq -r --arg BRANCH "$BRANCH" --arg WF "$WORKFLOW_FILE" ' | ||
| [.workflow_runs[] | ||
| | select(.pull_requests[]?.number == ($PR|tonumber)) | ||
| | select(.head_branch == $BRANCH) | ||
| | select(.path == (".github/workflows/" + $WF)) |
There was a problem hiding this comment.
Filtering workflow runs only by .head_branch == $BRANCH can select the wrong run when multiple PRs (especially from forks) use the same branch name (e.g. main, feature/foo). That can lead to deploying artifacts from an unrelated PR. To uniquely identify the run, also match the PR’s head SHA (via gh pr view --json headRefOid) and/or the PR’s head repository (e.g. headRepository.nameWithOwner) against the run’s head_sha / head_repository fields.
|
|
||
| # Fetch the most recent workflow run for this PR (regardless of overall conclusion) | ||
| # Get the branch name for this PR | ||
| BRANCH=$(gh pr view "$PR_NUMBER" --json headRefName -q '.headRefName') |
There was a problem hiding this comment.
gh pr view here relies on the current directory’s repo context, but the script’s API calls are hard-coded to $REPO. If someone runs this from a fork/other checkout, gh may fetch the wrong PR (or fail), producing an incorrect BRANCH. Pass --repo "$REPO" and add a small guard that BRANCH is non-empty/non-null before continuing.
| BRANCH=$(gh pr view "$PR_NUMBER" --json headRefName -q '.headRefName') | |
| BRANCH=$(gh pr view "$PR_NUMBER" --repo "$REPO" --json headRefName -q '.headRefName') | |
| if [ -z "$BRANCH" ] || [ "$BRANCH" = "null" ]; then | |
| echo "Error: Could not determine branch name for PR #$PR_NUMBER in repository $REPO" | |
| exit 1 | |
| fi |
| RUN_ID=$(curl -sf -H "$AUTH_HEADER" \ | ||
| "https://api.github.com/repos/$REPO/actions/runs?event=push&per_page=100" \ | ||
| | jq -r --arg PR "$PR_NUMBER" --arg WF "$WORKFLOW_FILE" ' | ||
| "https://api.github.com/repos/$REPO/actions/runs?per_page=100" \ | ||
| | jq -r --arg BRANCH "$BRANCH" --arg WF "$WORKFLOW_FILE" ' |
There was a problem hiding this comment.
The repo runs API supports server-side filtering by branch (and you can also query runs for a specific workflow file). Right now you fetch the last 100 runs across all branches and then filter in jq, which can miss the PR’s run if it’s not in that first page on a busy repo. Consider adding branch=$BRANCH (and ideally using the workflow-specific runs endpoint for $WORKFLOW_FILE) to make this robust.
The
pull_requestsfield in the GitHub API's workflow runs endpoint is often empty for recent runs, causingdeploy-pr-to-betato fail to locate the workflow run.Query by the PR's head branch name instead, which is reliably populated.
Test plan