How to access github actions log of current run from a later step/job #27097
-
In jenkins it is possible to access the data of the current running job through groovy: access to a pipeline job’s own Jenkins console log | by elhay efrat | Medium My use case is that i have a job which is compiling and running unit tests. I want to take after a failure the console log, parse it and extract the root cause of the failure. I could pipe all output to a log file but then the console log. would remain empty which is not nice. so what would be the best way to accomplish it? I could do it in a job which is triggered after any job run but i would look for an inclusive solution |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments
-
Hi! You can use GitHub CLI or Actions API to do that. CLI is the easiest to start with. Here is an article that can provide more information on how to set up and use GitHub CLI. |
Beta Was this translation helpful? Give feedback.
-
Thanks for your quick reply. I read the article but still don’t understand how the cli solves the problem Let’s assume this hypothetical workflow:
So i want to run gradle build and if it fails i want to take the console output and analyze it with a python script i write we don’t have the JOB_CONSOLE_FILE environment variable. Can you please help me how to use the github cli to get the console output What should be the bash command here ?
|
Beta Was this translation helpful? Give feedback.
-
In theory, https://docs.github.com/en/rest/reference/actions#get-a-workflow-run Will offer:
You can also use outputs in case you need to send data between workflows. Personally, for the basic use case you’re describing, I’d just use tee in the first step (sending the output to a file) and then parse the captured output in the second step. |
Beta Was this translation helpful? Give feedback.
-
Sample (not actually tested; always validate scripts before randomly running them in your own trusted environment; …):
|
Beta Was this translation helpful? Give feedback.
Sample (not actually tested; always validate scripts before randomly running them in your own trusted environment; …):