Closed Saviq closed 2 years ago
The
charm-dev
Blueprint is failing quite regularly due to the Testflinger VM having to run the OOM killer and things go bad- https://github.com/canonical/multipass-blueprints/runs/6132071208?check_suite_focus=true#step:7:3643
As discussed, I've added another 512MB, which should account for the extra qemu overhead.
As discussed, I've added another 512MB, which should account for the extra qemu overhead.
With some more tests, I conclude it's not feasible to run the charm-dev
workflow nested, so I've excluded that from the run.
This is ready to go, #17 exercises it, and canonical/multipass#2542 was filed with a bug it exposed.
I've let this drop, but we should get it in. I see the minikube
Blueprint failed only on the macOS x86_64. Is this transient or something we should be concerned about?
Let's try it again. It did time out, so likely a test infrastructure problem. Something to consider before merging this?
So yeah…
Timed out waiting for instance launch.
Let me know what you'd like to do?
So the failing job finished in 44m this time. I'm thinking the networking gets slow on some runs, but the looooong timeout should help with that. I think this is good now unless there is anything else you'd like to change/add.
OK I made output_timeout
the same as --timeout
and reduced the minikube
one to 30 mins (so 60 mins in CI, as it's doubled).
health-check
script to be executed on the main instance as a health check.