fix(winapp-pr): paginate the artifacts query so a busy run's package is findable - #705
Merged
Merged
Conversation
…is findable
winapp-pr walks recent runs looking for a downloadable msix-packages artifact. The
query asked GitHub for a run's artifacts without --paginate, so it only ever saw the
first 30. A run that uploads more than that pushes msix-packages onto page 2, where the
query cannot see it -- and the failure is silent in the worst way: it is
indistinguishable from a run that genuinely never produced a package, so the walk-back
to an older run looks like it is working correctly and hands back a stale build.
Observed on a run with 47 artifacts:
without --paginate 30 returned msix-packages NOT present
with --paginate 47 returned msix-packages present, non-expired
The tool reported "no usable msix-packages artifact" for four consecutive good runs and
resolved to a build from before the change under test. Nothing in the output suggested
the query was the problem.
This is a threshold bug, not a regression: the tool worked until a repo's per-run
artifact count crossed 30. Any workflow that adds per-shard artifacts (logs,
diagnostics, per-job uploads) will trip it, and it will look like the builds are broken.
Also widens the diagnostic to report how many artifacts were actually examined --
"has no msix-packages artifact among its 30" makes a truncated page obvious, where the
previous wording ("no usable ... artifact") reads as a fact about the run.
Verified both directions against a real run:
with the fix -> FOUND: msix-packages bytes=61019727
--paginate out -> NOT FOUND, "among its 30" (bug reproduced)
The other gh api calls in this script pass an explicit per_page and are "most recent N"
queries where truncation is the intent. This was the only "find this named item" query
relying on the default page size.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 70dbd3fe-4b72-4e07-a1c8-ac6a8758c4d5
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes artifact discovery for workflow runs with more than 30 artifacts.
Changes:
- Adds pagination to the artifacts query.
- Reports the number of examined artifacts.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
624
to
+625
| $artifacts = Invoke-Gh @('api', "repos/$RepoName/actions/runs/$($run.id)/artifacts", | ||
| '--jq', '.artifacts') | ||
| '--paginate', '--jq', '.artifacts') |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
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.
The bug
winapp-prwalks recent runs looking for a downloadablemsix-packagesartifact. The query asked GitHub for a run's artifacts without--paginate, so it only ever saw the first 30. A run that uploads more than that pushesmsix-packagesonto page 2, where the query cannot see it.Observed on a run with 47 artifacts:
Why it is worse than it looks
The failure is silent in the worst possible way: it is indistinguishable from a run that genuinely never produced a package. So the walk-back to an older run — which is correct, useful behaviour — looks like it is working, and quietly hands back a stale build.
In the case that surfaced this, the tool reported
no usable msix-packages artifactfor four consecutive good runs and resolved to a build from before the change under test. Nothing in the output suggested the query was at fault. The person testing then draws conclusions from a binary that does not contain their fix.This is a threshold bug, not a regression. The tool worked fine until a repo's per-run artifact count crossed 30. Any workflow that adds per-shard artifacts — logs, diagnostics, per-job uploads — will trip it, and the symptom will look like the builds are broken rather than the query.
The fix
Add
--paginateto that one call, with a comment explaining why it is load-bearing so it does not get "cleaned up" later.Also widens the diagnostic to report how many artifacts were actually examined:
among its 30makes a truncated page obvious at a glance. The previous wording reads as a fact about the run rather than a fact about what the query could see — which is why nobody suspected the query.Verification
Both directions, against a real run, driving the actual
Get-MsixArtifactfunction rather than a copy of it:The negative control reproduces the original bug exactly, so the fix is doing the work rather than something else having changed.
Scope
The other
gh apicalls in this script pass an explicitper_pageand are "most recent N" queries, where truncation is the intent. This was the only "find this named item" query relying on the default page size, so it is the only one that can fail this way.