-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timeout getting IP address from DHCP leases with macOS GitHub actions runner #1331
Comments
Not completely sure what is happening, but understand that the macOS version has not been tested to run as a headless version. if the github actions runner is using a different account, and therefore less permissive, I could understand why this fails:
sounds like a VM bring up issue; the driver waits, but the VM is never started? Can you start the VM in the regular way without the github runner? If so, please check the permission granted. To test a CI-like environment consider using the Linux version instead as this has been tested to run headless. |
Unfortunately, nested virtualisation is not supported by the GitHub actions Linux hosted runner, so the pre-flight check for virtualisation enabled fails. It is surprising that it works with the macOS runner around 20% of the time. I haven't identified any differences in the environment, so I wonder whether this could be the number of attempts in the retry loop that's not enough given the limited resources (2 vCPUs, 8Gb): |
preflight checks can be disabled, but eventually this would still fail. but why would it needed nested... I would expect it would run on the host directly? resources could surely be an issue, as the default is now 9GB and it is suggested to even assign more. |
GitHub actions hosted runners are virtual machines: https://help.github.com/en/actions/reference/virtual-environments-for-github-hosted-runners#cloud-hosts-for-github-hosted-runners. If I understand it correctly, the Standard_DS2_v2 machines lack the instructions that are required for nested virtualisation. I agree resources will ultimately be an issue. I haven't found CI hosted environments that provide 16GB of memory :( The fact that it sometimes works was giving me little hope. But I'll trust you if you tell me there is no change this is ever going to work reliably on that kind of environment. |
For information, |
Hmmm... I think I know. IIRC we initially ran into the same issues when spiking on using Github Actions. We ultimately decided that this woud not work for us due to the lack of Nested Virtualization to run tests... and yes, the resource usage (and storage) where of similar concern. The use of GitLab Runners seemed more managebale but meant to maintain our own infra, which would in that case not preovide any benefits for a public CI. So, yes... this sounds all of a sudden very familiar. this was all part of our search to find a replacement CI for public use, to replace CentOS CI. Eventually we moved to OpenShift CI as that would also make more sense... but that won't help you. So... there is no real public option. |
@praveenkumar You might have an idea? |
As per https://help.github.com/en/actions/reference/virtual-environments-for-github-hosted-runners#supported-runners-and-hardware-resources this is really a kind of resource issue but |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Running CRC within the macOS GitHub actions runner leads to inconsistent results. While it works from time to time, it often fails with the error:
It seems the following retry loop is not long enough:
https://github.com/code-ready/machine-driver-hyperkit/blob/c592b26d73624e85e1bdb7d962c6f0cea99740e1/pkg/hyperkit/driver.go#L259
It may be due to the 8GB memory constraint that's set on GH actions environment. It may lead to Hyperkit being slow to start.
General information
crc setup
before starting it (Yes/No)? YesCRC version
1.11.0
Host Operating System
Steps to reproduce
Run the following workflow:
Expected
Actual
The text was updated successfully, but these errors were encountered: