fix: expose run_attempt field (as attempt) when getting a workflow run
#8905
Conversation
cliAutomation
added
the
external
|
Hi! Thanks for the pull request. Please ensure that this change is linked to an issue by mentioning an issue number in the description of the pull request. If this pull request would close the issue, please put the word 'Fixes' before the issue number somewhere in the pull request body. If this is a tiny change like fixing a typo, feel free to ignore this message. |
|
@cawfeecake : While we appreciate contributors improving the GitHub CLI, could you create an issue that we might discuss this need outside of the PR? |
| @@ -97,7 +98,7 @@ type Run struct { | |||
| workflowName string // cache column | |||
| WorkflowID int64 `json:"workflow_id"` | |||
| Number int64 `json:"run_number"` | |||
| Attempts uint64 `json:"run_attempt"` | |||
There was a problem hiding this comment.
I'm genuinely surprised there is no other code that uses this field since it was added in #5945 🤯
That said, how should test cases within the following be updated to ensure this is being exported?
cli/pkg/cmd/run/shared/shared_test.go
Line 111 in ed5690c
There was a problem hiding this comment.
I'm genuinely surprised there is no other code that uses this field since it was added in #5945 🤯
I also went down this rabbit hole like gahhh. It's funny because it was even updated to use uint64 instead of 8 bits because it was causing an unmarshal error even tho it was never useeeeeed.
|
@cawfeecake please create an issue that describes your use case for this field to help us understand the motivation. It's very useful for us and the rest of the community to see what outcomes people are using the CLI for. |
the
run_attemptfield is not exposed in therun viewandrun lscommands, so the only why to get them via the cli is to usegh apithis change exposes it, but also renames the current field that wasn't being used as the data the field contains is not "how many attempts" rather "which attempt this info is for"