-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Undocumented behaviour of the -w
flag for gh run list
#9038
Comments
Thanks for reporting this issue! ❤ Let's dig into this a little bit and figure out what all can be done. 🙇 How does this code work?Let's dig into how Lines 90 to 122 in 4896546
I think the salient point in the block above is that Line 113 in 4896546
Switching gears to how cli/pkg/cmd/workflow/list/list.go Lines 89 to 97 in 4896546
What to do?
Absolutely makes sense, which I think is an easy Option 1. Thinking about how
@joshuajtward : what do you think? could you share your use case for retrieving and working with inactive workflows? |
Hi @andyfeller! Thanks for the reply, that all makes sense. One thing to add to your Option 1 -
This would mean this nuance of the CLI is documented without the need for code changes. Obviously if you prefer adding the In terms of our use cases, we have some pipeline observability tooling which fetches data using |
Just to be clear, I would like to do both: improve documentation and provide the same level of data for those who want it. 👍 Marking this as |
@andyfeller while digging into this I think I have stumbled upon the root issue. In // FindWorkflow looks up a workflow either by numeric database ID, file name, or its Name field
func FindWorkflow(client *api.Client, repo ghrepo.Interface, workflowSelector string, states []WorkflowState) ([]Workflow, error) {
if workflowSelector == "" {
return nil, errors.New("empty workflow selector")
}
if _, err := strconv.Atoi(workflowSelector); err == nil || isWorkflowFile(workflowSelector) {
workflow, err := getWorkflowByID(client, repo, workflowSelector)
if err != nil {
return nil, err
}
return []Workflow{*workflow}, nil
}
return getWorkflowsByName(client, repo, workflowSelector, states)
} This would explain why I was only seeing the disabled workflows excluded when using the Name field of the workflow. Given that it would potentially have a wider impact across the CLI, do you think we could explore adding a |
My knee jerk is to say "Yeah, totally!" though I have hesitation because of how GitHub Actions handles versioning of workflows on the server side. Basically, GitHub will create a new version of the workflow on the server side with different ID if you rename a workflow file, causing all of the previous workflow runs to "disappear" from the newly renamed workflow in the UI. This is where looking up workflows by ID needs to ignore state. |
@andyfeller will this do the job? #9162 |
Describe the bug
The
-w
flag forgh run list
behaves differently depending on whether a workflow name or a workflow filename is passed to it. Specifically, if a workflow has been manually disabled then thegh run list -w
will only return values with the filename as input, and nothing is returned for the workflow name (assuming no duplicate workflow names...).Versions checked:
2.44.1
,2.48.0
Steps to reproduce the behavior
gh run list -w my-workflow-name
and observe that no runs are foundgh run list -w my-workflow-name.yml
and observe that previous runs are listed (potentially as expected?)Expected vs actual behavior
Given the nature of workflow naming I can see reasonable grounds for this being a desirable feature of the CLI, so the scope of this issue is just to get the behaviour included in the documentation. If it turns out to be undesirable behaviour then I am happy to raise that as another issue!
Logs
The text was updated successfully, but these errors were encountered: