cli: `gh run view`: `--log` returns empty
Describe the bug
The --log parameter (and --log-failed) returns nothing.
gh run view --job 4749057122 --log gives and empty response for any job id.
Everything else works fine.
Steps to reproduce the behavior
- Type this
gh run view --job 4749057122 --log - View the output ``
- See error
Expected vs actual behavior
I would expect to see the logs that I can see in the web view.
Logs
> mollerhoj > gh run view --job 4749057122 --log
> mollerhoj >
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 9
- Comments: 38 (13 by maintainers)
Commits related to this issue
- https://github.com/cli/cli/issues/5011 — committed to py-cov-action/python-coverage-comment-action by ewjoachim a year ago
- https://github.com/cli/cli/issues/5011 — committed to py-cov-action/python-coverage-comment-action by ewjoachim a year ago
- rm explicit channels from deps cf. GHA bug https://github.com/cli/cli/issues/5011#issuecomment-1606275312 — committed to ryan-williams/libmamba-install-test by ryan-williams a year ago
Investigation
❤️ to @nmasur who I think has busted this thing wide open!
The shared workflow makes use of a composite action. When we look at the name of this job in the JSON output we can see that GitHub has separated the job name in the workflow (
test-log) and the name of the action (test) with a/resulting in a name oftest-log / test:When the CLI collects these job names, it inserts them into a regex to match against the contents of the downloaded zip file that contains the logs. However, when GitHub packages up this zip file, it removes the slash from the directory name presumably because that would indicate a path separator.
See this screen shot showing the difference between the
Test Logand theTest Shared Logand note that the slash has been removed on the right:It would seem that the CLI needs to apply whatever path transformations occur on the server, and ideally be a bit less generous in what we accept because presumably if logs are requested and we don’t match anything in the zip file, something is wrong and we should provide more useful debug information.
Request for Help
If you’ve experienced this issue, it would be a great help if you could check the names of your jobs in the API output to see whether they also contain slashes (or other characters) and compare them to the names of directories in the downloaded artifacts.
URL to get the job names:
URL to get logs (you will likely need a token with admin rights for this):
Alternatively, after running
gh run view --log <RUN_ID>you can find the zip file in the CLI cache under at$TMPDIR/gh-cli-cacheas in this terminal snippet:Oh ok - yeah, doing some more testing I can’t seem to get this command to work for any job id’s I pass it - even when they are under 10kb. To double check, I downloaded the logs from several runs. Checked which Job was under 10kb (just to rule that out - found one that was 2kb). Then ran the following:
gh run list -b stage- copy the ID of the run I just downloadedgh run view [RUN_ID]- copy the ID of the job that was 2kbgh run view --log --job=[JOB_ID]- blank outputResults
gh run view --log --job=[JOB_ID]- blank outputgh run view --job=[JOB_ID]- works as expectedDEBUG=1 gh run view --log --job=[JOB_ID]- returns status 200 along with the json that shows the step details in the job but not the raw job logsIt looks like this command just doesn’t work at all
Actually, I went ahead and made an example here:
This one works fine (no sharing).
This one shows no logs (shared workflow).
Logs
Hello, I’m experiencing the same issue. Running the following:
Results in no output. This job viewed in the web UI works just fine.
Seems like jobs’ logs are not printed when they are part of a
matrixand one of the parameters contains a colon (:).Here’s an example with four jobs, two of which have a
:in theirmatrixparameter, and two which don’t:gh run -R ryan-williams/libmamba-install-test view --log 5371942339only shows logs from the two jobs without a:in their matrix paramI ran into this because I had other runs where all the jobs had
:s in their matrix params.gh run view --log …was exiting with code 0, as if it had succeeded, but printing nothing:Example:
Thanks, @williammartin, I can confirm it’s working for me (using composite actions)!
I pinned the commit and compiled using a nixpkgs overlay:
Overlay
Hey folks, I’ve just merged #7526 which should address this issue for composite actions or user provided
names that include/. It does not address other known issues as outlined in the comment above.Until this makes it into a release, if you’d like to try this out to see if solves your issue you can follow the instructions to build from source. I’d love to know if:
/in aname)Cheers.
Nice work @pcolby, that’s super neat of you.
Investigation
I just wanted to give an update based on the investigations that I did today. I had a look at the process that produces the downloadable
.zipfile and I believe the following statements are true. Each of these statements applies to bothjobs(folders) andsteps(files)./zipfiles have a path length limitjobsandsteps, sometimes a number is added to the path to deduplicateIn all of these cases, the CLIs naive approach to match
jobnames to file paths inside thezipwill fail to work.I feel relatively confident in this assessment with the caveat that:
What you can do
I suspect that since you’re here in this “
--logreturns empty” issue, you probably are experiencing something relating tojobnames rather thanstepnames (as I think the latter would probably only show missing step logs rather than an entirely blank log) unless perhaps you only have one step in a job.Nevertheless, on your end you can:
jobnames in a workflowWhat you can’t do
Since the server seems to concatenate
jobnames and composite action names with a/, it seems you’re out of luck without a CLI fix, which leads me to…What we can do
There’s lots of things we might want to do here with regards to the disallowed characters, the truncation and the duplication. I’m hesitant to repeat all the server side logic in the client because that’s fraught with risks being out of sync, so perhaps in the long run we can find another mechanism, such as a manifest. I’ll need to think about this.
In the meantime however, the very obvious and unsolvable (by you) issue is the server side concatenated
/for composite actions. I’m inclined to push a fix solely for that and see how far that gets everyone here. I will need to run that by the team though as I only recently joined this project so please don’t take that as a commitment.✌️ Cheers everyone.
Thanks @williammartin!
I threw together a near-trivial Bash script to make that a bit easier for people (including myself):
You just need to set the
SLUGandRUN_IDvariables, and run it. It will output something like:The diff at the end shows what’s different between the job names, vs the log directories. In my case, it was always the
/being striped out.Cheers.
@ewjoachim A reproduction case in an open-source repo would be great (@orensbruli shared one but we didn’t see it in time and now the run is outdated, sorry!).
Or, if in a private repo, it would be helpful if someone could run the
gh run view --logcommand withGH_DEBUG=1, take a note of the zipball API endpoint, then hit that endpoint and save it to a file withgh api URL > myfile.zip. If the data is not secret, you could share the file with us, or at minimum you can tell us the folder structure of the file.What’s preventing us from fixing this bug is that we haven’t been able to confirm it in any of our repositories. My hunch is that either the zipball is generated corrupt on the server, or that the gh logic to extract the zipball is mismatching step names somewhere. https://github.com/cli/cli/blob/71ec2c4e2305ba6ac17962f0805aee5fe8415584/pkg/cmd/run/view/view.go#L482-L510 https://github.com/cli/cli/blob/71ec2c4e2305ba6ac17962f0805aee5fe8415584/pkg/cmd/run/view/view.go#L523-L530
On the latest stable version, it seems to still not work. Trying a workaround with
gh apiand it also doesn’t work so I guess it fails in the underlying layerWith DEBUG=api
@mrpatrick The 10kB limit only affects verbose GH_DEBUG logging, not the normal output of
gh run view --log. The output of that command is not limited in any way, and will print logs of any size. I do not know why some logs come out empty and I suspect it’s a bug with the internal logic ofgh run view, but the bug is most likely unrelated to the 10kB limit.@mrpatrick The verbose mode will avoid printing HTTP bodies over 10kB to avoid spamming your stderr stream too much and causing you to lose sight of the rest of the log. Rest assured that if the server responded with 10kB of JSON, that means the request was successful, so it’s not likely that it had caused the bug.
Would anyone have a way of reproducing this on an open source repo, or has found something in logs that indicates that might have been the origin of the failure? I’m afraid I didn’t have success tracking this down based on the reports so far.
I’m also having the same issue - however, when I enable debug I see the following at the end of the debug message:
Maybe this is why it’s empty? I would assume it could handle more than 10,000bytes as build logs in general are quite long. Should at least display this message as an error up front so the user knows
Hello,
I am having the same issue:
Here is the output of the command:
I hope it could help.
Kind regards, JM