Respect --exit-status with --log and --log-failed in run view#12679
Merged
williammartin merged 1 commit intotrunkcli/cli:trunkfrom Feb 13, 2026
wm-run-view-exit-status-not-respectedcli/cli:wm-run-view-exit-status-not-respectedCopy head branch name to clipboard
Merged
Respect --exit-status with --log and --log-failed in run view#12679williammartin merged 1 commit intotrunkcli/cli:trunkfrom wm-run-view-exit-status-not-respectedcli/cli:wm-run-view-exit-status-not-respectedCopy head branch name to clipboard
--exit-status with --log and --log-failed in run view#12679williammartin merged 1 commit intotrunkcli/cli:trunkfrom
wm-run-view-exit-status-not-respectedcli/cli:wm-run-view-exit-status-not-respectedCopy head branch name to clipboard
Conversation
3f51da0 to
2496468
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a bug where the --exit-status flag was not respected when used with --log or --log-failed flags in the gh run view command. The command would always exit with status code 0 even for failed runs when displaying logs, whereas it should exit with a non-zero status for failed runs when --exit-status is specified.
Changes:
- Modified the log display code path to check
opts.ExitStatusand returncmdutil.SilentErrorfor failed runs after displaying logs - Added two test cases to verify that exit status is now properly respected with both
--log-failedand--logflags
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| pkg/cmd/run/view/view.go | Added exit status check after displaying log segments to match non-log code path behavior |
| pkg/cmd/run/view/view_test.go | Added test cases verifying exit status is respected with --log-failed and --log flags for failed runs |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
run view--exit-status with --log and --log-failed in run view
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
2 participants
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.
Description
Fixes #12674
When
--exit-statuswas passed alongside--logor--log-failed, the command always exited 0 because the log display code path returned early without checking the run's conclusion.This adds the exit-status check after displaying logs, matching the behavior of the non-log code paths.
Acceptance Criteria
Given I have a failing job
When I run
gh run viewwith--exit-statusand either--logor--log-failedThen the exit status of
ghis non-zeroBefore, with no log flag
Before, with log flag
After, with log flag
Reviewer Notes
I have not extended this to
--jsonflags, which feels like a much bigger conceptual lift.