Bump timeout in machine tests #25058
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Luap99 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
I think two of the jobs still timed out... Unless |
The test pulls a big disk image every time which is slow. I see no good way around that. Let's try to use /dev/null as image as we do not have to run the VM at all and just can pass a NOP file to make the init command happy. That pull of that image seems to take over 2m so we safe quite a lot. Also update the matcher for the slice. BeTrue() produces horrible errors. Signed-off-by: Paul Holzinger <[email protected]>
The regex match would return a horrible error message and is way more complicated then it should be. Simply check that .exe is not part of the output. Signed-off-by: Paul Holzinger <[email protected]>
We see a ton of timeouts in bot the applehv and libkrun machine tests. It seems 35m are no longer enough. I was not able to spot anything that would explain why it increased all of the sudden as such I hope this is enough. Fixes containers#25057 Signed-off-by: Paul Holzinger <[email protected]>
Yeah "Context canceled" is different, maybe even more concerning. This can be if the connecting to the test machine was lost, i.e. reboot/shutdown. Or a new force push would trigger the same thing I think as that cancel already running tasks. No idea why this happen there, let's hope it is a one of. |
|
LGTM, we are seeing timeouts so this will definitely help.
…On Mon, Jan 20, 2025 at 13:52 Paul Holzinger ***@***.***> wrote:
I think two of the jobs still timed out... Unless Context canceled is
something else?
Yeah "Context canceled" is different, maybe even more concerning. This can
be if the connecting to the test machine was lost, i.e. reboot/shutdown. Or
a new force push would trigger the same thing I think as that cancel
already running tasks.
No idea why this happen there, let's hope it is a one of.
—
Reply to this email directly, view it on GitHub
<#25058 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3AOCDMH6HFQRRPTPS76CD2LVAYRAVCNFSM6AAAAABVQ4HJOKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBTGA3TGMBTGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Just as reference the one test passed in 40min we had 35 min timeout so it seems totally valid to say we need a bigger timeout. @baude @l0rd @ashley-cui PTAL |
|
LGTM, in Cirrus, is there a URL with all the runs of a given job? It would be interesting to figure out when the machine on Mac jobs started to last more than 35 minutes. |
please merge this given it is the second LGTM to avoid other PRs from suffering any longer There is no such URL to my knowledge, you need to scrape all tasks from the cirrus API. |
|
/lgtm
Ok thanks |
openshift-merge-bot
bot
merged commit e5b6382
into
containers:main
Does this PR introduce a user-facing change?