gh run view limit on output?

[christopher-watanabe-snkeos]

Describe the bug

I am validating that my github workflows accomplish what I expect them to. For this, I run my re-usable workflows over multiple projects. I do this with 6 re-usable workflows and 6 projects in the scope of the same workflow, so ultimately I expect gh run view to return the results for 36 different jobs.

I noticed that there appears to be a limit on the output of the gh run view, as some of the jobs that I expected to run are shown in the Actions tab of the repo, but not listed in the jobs of the gh run view.

I can't seem to find any information about a limit to output of the gh run view, but if I remove one of the projects, limiting the number of jobs to 30, I notice that the jobs that were not listed before are suddenly listed once more. Is there a limit on the output I can expect from gh run view?

Steps to reproduce the behavior

1. Run multiple re-usable workflows multiple times.
2. View the output of the workflow run with gh run view
3. See whether all jobs are listed.

Expected vs actual behavior

I would expect all of my workflows to be listed.

[samcoe]

@christopher-watanabe-snkeos Do you by happen chance mean gh run list? There is a default of 30 runs for run list but that can be modified using the --limit flag to retrieve more runs.

[christopher-watanabe-snkeos]

@samcoe Thanks for the response! Sorry for the confusion, the exact command I am running locally on my git repo is:

gh run view 5714854729 --json databaseId,headBranch,headSha,jobs,name,workflowName,workflowDatabaseId,url,conclusion

What I notice is that there are jobs that I can view in the repo's actions tab for the workflow run, but those jobs are for some reason missing in the output of the above command.

I've also just had a look at the information that is given when I set DEBUG=api environment variable and run gh run view 5714854729 --log. Interestingly, the json output of the total_count of jobs and the list prints "total_count": 36, but a list of only 30 jobs.

[christopher-watanabe-snkeos]

I've run another test by accessing the listed jobs with the listJobsForWorkflowRun and pagination of Octokit.

What I found was that by paging over the results from this call, I was able to list all of the workflows, including the previously missing one.

Could it be that the CLI call is only returning the first list of jobs from the workflow run? Can we adapt this behavior?

[christopher-watanabe-snkeos]

I've found the documentation that points to this default of 30 page size https://docs.github.com/en/free-pro-team@latest/rest/actions/workflow-jobs?apiVersion=2022-11-28#list-jobs-for-a-workflow-run. I don't need the gh run view to be able to show me all the jobs, since I can use gh api and include a greater number of jobs with the pre_page query parameter.

I still think that it would be useful to communicate via the CLI to get all jobs from the run view, however there are certainly workarounds.

[samcoe]

@christopher-watanabe-snkeos Thanks for the clarification and investigation, you are correct that we are only retrieving the first page of results from the jobs url. We should definitely be paginating automatically to retrieve all the jobs for a given run. Going to open this up for contributions.

[harveysanders]

@samcoe I might want to take a stab at this.
Does it make sense to have GetJobs always fetch all the jobs or have the callers (view.runView, watch.renderRun) explicitly specify that they want all the jobs? I would guess the former, but not sure.

Here are the callers for ref:

cli/pkg/cmd/run/watch/watch.go

Line 210 in f777bec

jobs, err := shared.GetJobs(client, repo, run)

cli/pkg/cmd/run/view/view.go

Line 224 in f777bec

jobs, err = shared.GetJobs(client, repo, run)

cli/pkg/cmd/run/view/view.go

Line 224 in f777bec

jobs, err = shared.GetJobs(client, repo, run)

cli/pkg/cmd/run/shared/shared.go

Lines 430 to 440 in f777bec

	func GetJobs(client *api.Client, repo ghrepo.Interface, run *Run) ([]Job, error) {
	if run.Jobs != nil {
	return run.Jobs, nil
	}
	var result JobsPayload
	if err := client.REST(repo.RepoHost(), "GET", run.JobsURL, nil, &result); err != nil {
	return nil, err
	}
	run.Jobs = result.Jobs
	return result.Jobs, nil
	}

[samcoe]

@harveysanders I think it makes sense for GetJobs to always retrieve all the jobs, thanks for asking.

[harveysanders]

@samcoe sounds good. Thanks!