gh run view --log does not display logs when job names are beyond a certain length
#7642
Comments
samcoe
added
p2
williammartin
added
gh-run
|
This is reproducing for me as well. Any plans to apply a fix? Any good workarounds in the meanwhile? Thanks |
|
Hey @shayn-orca, Hadn't prioritised anything around this because it was just theoretical and no one had actually run into it yet. No workaround comes to mind other than reducing the length of your job names. I don't think a fix for this would be particularly complicated, just truncating some names based on length. Would you be interested in opening a PR if I pointed you in the right direction? |
|
Sure @williammartin - please send me some directions, I'd love to contribute to |
|
Well, the code I believe we're interested in starts about here: Lines 516 to 528 in 5a0f892 This function is is looping over files in the downloaded Lines 495 to 497 in 5a0f892 This looks at the name of the job in the workflow, replaces any Below you will find an example output of the run log after The regex is kind of confusing so let's look closer: This is going to produce a regex that looks like: This doesn't seem to match anything right? Well, inside a zip there is just a flat file structure and Ok so anyway, I would bet that if you added a line: func logFilenameRegexp(job shared.Job, step shared.Step) *regexp.Regexp {
sanitizedJobName := strings.ReplaceAll(job.Name, "/", "")
// sanitizedJobName = truncateString(sanitizedJobName, 89)
re := fmt.Sprintf(`%s\/%d_.*\.txt`, regexp.QuoteMeta(sanitizedJobName), step.Number)
return regexp.MustCompile(re)
}That things would start working for you again. The question is, does the server do truncation before or after Finally, we'll need to add a test for this. It looks like we have a test that opens up a fixture and checks how cli/pkg/cmd/run/view/view_test.go Line 1471 in 201842d Hope that makes sense and if not please let me know! |
williammartin
added
help wanted
|
Hey @williammartin, check out #8684 please :) We've tested manually and added a UT and it seems to work OK. |
|
Using the same workflow definition as above, we now get logs from the long job name: |
and others
Describe the bug
This is a spinoff from #5011
Given a job in a workflow with a long name,
gh run view --logwill not display logs for that name.Steps to reproduce the behavior
Here is a workflow definition that includes a job with a long name. Note that I accidentally left the step name as
duplicatebut it's not relevant.Running
gh run view 5415184943 --logproduces only the logs for theshortjob:Expected vs actual behavior
I would expect to see logs as in the Web UI for the job with the long name.
Why does this happen?
As described in my comment when the
.zipfile is produced, file paths are truncated due to intrinsic length limitations of.zipfiles. Our regexp matching logic does not apply the same behaviour, resulting in us not matching file names to their jobs.See the truncated
Loreum Ipsumdir name below:Notes
Related issues: #7640, #7641
The text was updated successfully, but these errors were encountered: