You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment if one arch fails, we continue to build the other 3 even though we're then going to fail the job and throw them away. We could cancel the others and save some worker CPU cycles.
The text was updated successfully, but these errors were encountered:
The benefit of current behavior is that built modules are cached anyway, so even if the architecture that failed to build is being disabled by the next commit, it's just a cache hit for others.
I think disabling a broken architecture isn't the "normal" fix - a build failure is more likely to cross all architectures and need some patch to the JSON which could invalidate a lot of the caches anyway.
We've had >1 worker per arch on the new infra this week, so this assumption that a build always helps your cache isn't true unless we set up some kind of affinity to workers that tried the same exact JSON before. But I don't think this is the most common case we should be optimising for, and you can get starvation (blocking on a long-running build for ages) if you "mess" with the scheduler like this.
The problem is the Scaleway builders are just pretty slow and I'm worried about falling behind even with a relatively modest change request traffic.
It certainly makes sense to cancel scheduled builds (that aren't even started) however.
At the moment if one arch fails, we continue to build the other 3 even though we're then going to fail the job and throw them away. We could cancel the others and save some worker CPU cycles.
The text was updated successfully, but these errors were encountered: