Route run artifact listing through api.Client - #14078
Merged
williammartin merged 2 commits intoAug 6, 2026
Merged
Conversation
Co-authored-by: Copilot App <[email protected]> Copilot-Session: 476e1749-e4c0-4476-878b-6b47eae09eed
Co-authored-by: Copilot App <[email protected]> Copilot-Session: 476e1749-e4c0-4476-878b-6b47eae09eed
6 tasks
williammartin
marked this pull request as ready for review
August 5, 2026 14:45
williammartin
requested review from
sergiou87
and
a lite review from Copilot
and removed request for
a team
August 5, 2026 14:45
Contributor
There was a problem hiding this comment.
Pull request overview
This pull request continues the API client consolidation work by routing workflow run artifact listing in gh run through api.Client.RESTWithNext, removing duplicate pagination and Link-header parsing logic from the run command’s shared artifacts helper.
Changes:
- Refactors
shared.ListArtifactsto useapi.Client.RESTWithNextfor pagination instead of a package-localapiGet+ Link parsing. - Adds a regression test to ensure error paths still surface as
api.HTTPErrorwith the expected status and message. - Adds
TODO(api-client-rollout)breadcrumbs on remaining rawhttp.Clientcall sites that must stream ZIP/log bodies.
Show a summary per file
| File | Description |
|---|---|
pkg/cmd/run/shared/artifacts.go |
Switches artifact listing to api.Client.RESTWithNext and removes duplicate HTTP + pagination helpers. |
pkg/cmd/run/shared/artifacts_test.go |
Adds coverage asserting RESTWithNext error behavior and preserves multi-page behavior coverage. |
pkg/cmd/run/view/view.go |
Documents why run-log ZIP streaming still uses raw http.Client. |
pkg/cmd/run/view/logs.go |
Documents why job log fetching still returns an io.ReadCloser via raw http.Client. |
pkg/cmd/run/download/http.go |
Documents why artifact ZIP download/streaming still uses raw http.Client. |
Review details
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Files reviewed: 5/5 changed files
- Comments generated: 1
- Review effort level: Lite
babakks
approved these changes
Aug 5, 2026
glslang
added a commit
to glslang/agent-skills
that referenced
this pull request
Aug 5, 2026
Round 4 review on #9: one Codex P2, applied structurally. A human judge who was asked and has not answered has no row in §2's fold, so "their verdict isn't CHANGES_REQUESTED" was true of them, and §9 reported the PR clear — potentially merging past a required reviewer who had not looked at it. Verified the mechanism on cli/cli#14078: a reviewer sits in reviewRequests while others have already approved, and GitHub drops them from that list only once they submit. Rounds 3 and 4 both found a missing case in the same bullet (DISMISSED, then never-answered), so patching a third one invites a fourth. The two overlapping judge bullets are now a single table that enumerates every state a judge can be in — pending request, CHANGES_REQUESTED, DISMISSED, APPROVED, COMMENTED-only, and the four bot states from §6. The section is shorter than what it replaces, and a missing case is now visible as a missing row rather than as an unstated assumption. The underlying rule, stated once: pending and absent are different, in both directions. Treat pending as satisfied and you merge past a review that was coming; treat absent as pending and you wait for one that isn't. "Not CHANGES_REQUESTED" distinguishes neither. §2 now collects reviewRequests alongside the fold, since the fold covers only people who actually reviewed. Co-Authored-By: Claude Opus 5 <[email protected]>
williammartin
merged commit Aug 6, 2026
28ebaf1
into
williammartin-wp-05-release-api-client
44 checks passed
glslang
added a commit
to glslang/agent-skills
that referenced
this pull request
Aug 6, 2026
Round 4 review on #9: one Codex P2, applied structurally. A human judge who was asked and has not answered has no row in §2's fold, so "their verdict isn't CHANGES_REQUESTED" was true of them, and §9 reported the PR clear — potentially merging past a required reviewer who had not looked at it. Verified the mechanism on cli/cli#14078: a reviewer sits in reviewRequests while others have already approved, and GitHub drops them from that list only once they submit. Rounds 3 and 4 both found a missing case in the same bullet (DISMISSED, then never-answered), so patching a third one invites a fourth. The two overlapping judge bullets are now a single table that enumerates every state a judge can be in — pending request, CHANGES_REQUESTED, DISMISSED, APPROVED, COMMENTED-only, and the four bot states from §6. The section is shorter than what it replaces, and a missing case is now visible as a missing row rather than as an unstated assumption. The underlying rule, stated once: pending and absent are different, in both directions. Treat pending as satisfied and you merge past a review that was coming; treat absent as pending and you wait for one that isn't. "Not CHANGES_REQUESTED" distinguishes neither. §2 now collects reviewRequests alongside the fold, since the fold covers only people who actually reviewed. Co-Authored-By: Claude Opus 5 <[email protected]>
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.
Part of #13991
Description
This stacked PR routes artifact listing in
gh runthroughapi.Client.RESTWithNext.ListArtifactspreviously issued requests through a privateapiGethelper, decoded responses itself, and parsedLinkheaders with a package-local regular expression andfindNextPage. The API client already provides that pagination behavior, so this removes the duplicate request and link-parsing implementation while preservingper_page=100andrel="next"traversal.The initial endpoint is now built as a safe relative URL and passed to
RESTWithNext; subsequent absolute URLs returned by the API are passed through unchanged. The existing multi-page test continues to exercise that path. The error-path test also verifies that failures remain CLIapi.HTTPErrorvalues with the expected status and byte-identical message. This relies on #13988, which is below this PR in the stack.Three raw
http.Clientsites remain intentionally and carryTODO(api-client-rollout)comments with their blockers:downloadArtifactstreams an artifact ZIP response body to disk.apiLogFetcher.GetLogreturns the job log response body as anio.ReadCloser.getLogstreams a run log ZIP for archive processing.api.Client.RESTcannot express those operations because it decodes successful responses as JSON rather than exposing the raw response body.Merged with the PRs below it in the stack, this is a consolidation with no intended user-visible behavior change.
How did you test this change?
Full acceptance test output
Key points
None
Notes for reviewers
None.
Authorship and follow-up
Who wrote this:
Who answers review comments: