Open iliasnaamane2 opened 8 months ago
Hello! Thank you for filing an issue.
The maintainers will triage your issue shortly.
In the meantime, please take a look at the troubleshooting guide for bug reports.
If this is a feature request, please review our contribution guidelines.
Hey @iliasnaamane2,
This is not an ARC issue, it is related to the service overall. I'd like to point out that this is also a known issue and part of the roadmap.
Hello @nikola-jokic , thanks for your answer. The issue doesn't occur with Github runners, it occur only with self-hosted-runners. Can you please recheck your answer?
I am aware of it :relaxed:. You can see we have few issues in the runner repository that are also closed, since they are related to the service. For example: https://github.com/actions/runner/issues/886
@nikola-jokic ,
Thanks for your answer again, I have been using actions-runner-controller for a while now and I remember that I was able to see logs after refreshing the page. This time it's strange I can no longer access the logs and it doesn't make sense. Are you sure this is normal behavior?
Please check screenshot attached.
Thanks!
No problem! This shouldn't have happened, can you please try to run it now? This might have been a temporary error?
@nikola-jokic I am still facing the same issue. Can you please check on your end please? Thanks!
Can you please download the job log?
Thanks for your answer. Indeed I can view raw logs attached, but I cannot view them using the dropdown icon as you have in your screenshot. As well after downloading log archive the zip file is empty.
Can you please let me know why I can't view the logs through the job UI?
Thanks in advance for your help!
Maybe try to clear cache or pause the ad blocker? Seems like the log is streamed, but it isn't displayed on the UI
Same result, actually the logs are streamed and I can see them in the UI when running the worflow but strangely disappeared once refreshing the UI page and the job is completed. As well, I can see logs forever when I am using Github runners instead of self-hosted runners. Below screenshot of logs using Github runners:
Can you please submit it here? It can help route the problem to the correct team :relaxed:
Thanks for your answer. I have created a discussion over here https://github.com/orgs/community/discussions/118795
@nikola-jokic FYI, when I download the log archive the folder is empty with self-hosted-runners and full of logs with all steps when using Github runners. Should I do something on my side to enable log archive with self-hosted runners?
Let me re-open this one. It seems like something is not streaming the log to the back-end, but I'm not sure why. This is also not gha-runner-scale-set
, and I'm not as familiar with the older scaling mode as I am with the new one.
Hi @nikola-jokic , Thanks for your answer, but I think that logs are correctly streamed when the workflow is running but are not correctly saved so I can check them through the UI whenever I want. As well, the archive logs is empty
👀 We're also seeing this on self-hosted runners - it doesn't occur on every workflow, but always affects all of a workflow.
I did some analysis on my github runners, which are hosted in an AWS VPC, with Network filewall. Looking in the logs, over the previous 12 hours, the following hosts were blocked:
productionresultssa10.blob.core.windows.net productionresultssa11.blob.core.windows.net productionresultssa12.blob.core.windows.net productionresultssa13.blob.core.windows.net productionresultssa14.blob.core.windows.net productionresultssa15.blob.core.windows.net productionresultssa16.blob.core.windows.net productionresultssa17.blob.core.windows.net productionresultssa18.blob.core.windows.net productionresultssa19.blob.core.windows.net
Previously we had allow-listed the following hosts, as described in the docs.
productionresultssa0.blob.core.windows.net productionresultssa1.blob.core.windows.net productionresultssa2.blob.core.windows.net productionresultssa3.blob.core.windows.net productionresultssa4.blob.core.windows.net productionresultssa5.blob.core.windows.net productionresultssa6.blob.core.windows.net productionresultssa7.blob.core.windows.net productionresultssa8.blob.core.windows.net productionresultssa9.blob.core.windows.net
Previously, the docs said to only allow these hosts, but now they say to allow *.blob.core.windows.net
which is not great IMHO. Any-bucket controlled by anyone, for any operation in the whole of Azure, worldwide isn't exactly controlled. Surely it's enterprises paying for github enterprise that want selfhosted runners, and don't want to give fettered access to build agents that this exists for?
Anyhow, allowing those hosts, does so far, seem to fix the logs access issue in the web UI to github, and makes the jobs terminate faster.
This is the commit that changed the docs: https://github.com/github/docs/commit/fa66f2f1bce5a0823177be1cc85c7417192d06d3
I think it should probably be changed back to a finite list of specific hosts.
Hello, I can't move on with this issue, any news please? Thanks
I am seeing the same thing happen on a self-hosted linux action-runnen. A similar task on a windows system is working fine. When looking at view-source i notice that the data-log-url="" of all check-step are empty. On the windows system they contain a valid URL .
The issue can be closed as it has been resolved by deploying the same helm chart in another cluster. Do you have an idea what's the root cause of this issue?
I am experiencing the same exact issue when using runner as a CLI from my locked-down enterprise company network.
No helm install. Just download and run.sh
.
The config.sh --check
command passes. I'm reaching out to my network people to see if I can get access to logs to see if there were blocked URLs.
Will come back with any findings.
In my job logs:
[2024-10-11 13:54:28Z INFO JobServerQueue] Catch exception during file upload to results, keep going since the process is best effort.
[2024-10-11 13:54:28Z ERR JobServerQueue] System.AggregateException: Retry failed after 4 tries. Retry settings can be adjusted in ClientOptions.Retry or by configuring a custom retry policy in ClientOptions.RetryPolicy. (The SSL connection could not be established, see inner exception.) (The SSL connection could not be established, see inner exception.) (The SSL connection could not be established, see inner exception.) (The SSL connection could not be established, see inner exception.)
---> Azure.RequestFailedException: The SSL connection could not be established, see inner exception.
---> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.IO.IOException: Unable to read data from the transport connection: Connection reset by peer.
---> System.Net.Sockets.SocketException (104): Connection reset by peer
--- End of inner exception stack trace ---
Checks
Controller Version
0.23.7
Deployment Method
Helm
Checks
To Reproduce
Describe the bug
Logs disappear from Github Actions UI after refreshing the workflow page
Describe the expected behavior
Logs disappear from Github Actions UI after refreshing the workflow page
Additional Context
Controller Logs
Runner Pod Logs