I must be missing something huge here, or maybe it's the wine -- how is the code in PR 3157 (referenced in a later comment) a proper fix?

https://github.com/actions/runner/pull/3157/files

Is : doing something unusual in GH actions?

▲

Veserv 6 hours ago | parent [-]

The original loop is:

while (time() != timeout) {;}

The fixed loop is:

while (time() < timeout) {;}

▲

dpkirchner 5 hours ago | parent [-]

I see. I did not realize SECONDS was a built in bash variable.

▲

nh2 5 hours ago | parent | next [-]

It is still not a proper fix. It is still busy-looping 100% CPU.

Given that Github Actions is quite popular, probably wasting large amount of energy.

But probably good at generating billable Actions minutes.

One can only hope that not many people use sleeps to handle their CI race conditions, as that itself is also not a proper fix.

▲

magicalhippo 4 hours ago | parent [-]

Clearly the job for a microservice. Accept number of seconds to wait as url, return content after that many seconds. Then just use curl in runner.

▲

xp84 3 hours ago | parent | next [-]

Brb founding a SaaS startup. I’ll call it cloudsleep dot io of course. After our Series B I’ll buy the .com.

Only task to do before lining up investors is how can I weave AI into our product?

	▲	debugnik 2 hours ago \| parent [-]
		Describe the task you're waiting for as text, and let an LLM pick the number of seconds for each request. More expensive the better model you clearly need for this. There, your AI pitch.

▲

wmanley 3 hours ago | parent | prev [-]

Retries won’t work in that case. Would be better to have two endpoints: get the time in x seconds and wait until time passed. That way retrying the wait endpoint will work fine and if time hasn’t elapsed it can just curl itself with the same arguments.

▲

xp84 3 hours ago | parent | prev [-]

Me neither. I am over 40 and did not know this. Feels good to learn something today, in an unexpected place!