If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

make buildbot play nice with l10n repackaging

RESOLVED INCOMPLETE

Status

()

Core
Build Config
RESOLVED INCOMPLETE
11 years ago
9 years ago

People

(Reporter: Pike, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
To make a long story short:

I prefer 

* one source-checkout per slave
* ability to kick in more slaves per builder category, i.e., making windows installers
* failing slaves shouldn't make the build fail

That means:

We have to lock down the source for all builds on one slave for all repacks.
Checking out the source needs to be optional, and not all slaves need to succeed.

That basically rules out Dependent schedulers and slave locks, given that with l10n repacks, we need a builder per language and platform to get some scheduling freedom.

I am currently hacking up a solution to this:

A scheduler that blocks new builds from starting until all builds have completed.
A OneSlaveLock, which actually triggers a callback on all but the first owner to take that lock, enabling us to switch off check-out on following steps.

Code coming up as soon as it passes self-review.
(Reporter)

Comment 1

11 years ago
First of trac issues blocking this would be http://buildbot.net/trac/ticket/36.
(Reporter)

Comment 2

10 years ago
(In reply to comment #1)
> First of trac issues blocking this would be http://buildbot.net/trac/ticket/36.
> 

That's closed.
(Reporter)

Comment 3

9 years ago
Let's resolve this in one way or another, picking INCOMPLETE as the initial comment in this bug doesn't map reality anymore.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.