Skip to content
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

cancel other arch builds if one fails #3

Open
ramcq opened this issue Jul 27, 2017 · 2 comments
Open

cancel other arch builds if one fails #3

ramcq opened this issue Jul 27, 2017 · 2 comments

Comments

@ramcq
Copy link
Contributor

ramcq commented Jul 27, 2017

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.

@barthalion
Copy link
Member

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.

@ramcq
Copy link
Contributor Author

ramcq commented Jul 27, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants