Can't push a b2g18 revision to try without creating tons of orange

RESOLVED WONTFIX

Status

Release Engineering
General
RESOLVED WONTFIX
5 years ago
a month ago

People

(Reporter: Justin Lebar (not reading bugmail), Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
RyanVM tells me that this is a passing try push of b2g18, but you wouldn't know it by looking: It's a wall of orange.

https://tbpl.mozilla.org/?tree=Try&rev=fe21d7cfe568

RyanVM explained on IRC that part of the problem is that try uses Ubuntu testers, while b2g18 uses Fedora testers.  But he wasn't able to explain the rest of the differences here.

I don't know how many of us are running into this problem, but it seems like a pretty big deal to me that tryserver is at best very difficult to use for b2g.  I expect the b2g18 branch to live for a long time yet.

I'd be happy to flag commits as "b2g18-specific" when pushing, either with a trychooser flag, or by pushing to a special try-b2g18 repo, if that would let us solve this problem.

Since my try push above had non-trivial patches applied, I've pushed a cleaner demonstration, with no files modified.  Once the results come in, we can compare

  https://tbpl.mozilla.org/?tree=Try&rev=bf90b3ff5aa5

against the test results from the same code run on the b2g18 tree:

  https://tbpl.mozilla.org/?tree=Mozilla-B2g18&rev=19ac7ebfd057.

Comment 1

5 years ago
There are two main problems:

1) Try's config for buildbot mirrors mozilla-central et al, which has since diverged from the config used for release trees such as b2g18/esr17. eg: The move from real hardware fedora slaves to ubuntu amazon EC2 machines has occurred for trunk (and thus try) and will work it's way through the trains - however b2g18 doesn't have the in-tree reftest tweaks that greened them up on VMs (bit of disabling, bit of marking fuzzy-if and a few other changes iirc).

2) TBPL manages job visibility per tree. Try's job visibility needs to match that of the trunk trees - which means even if buildbot configs weren't an issue, pushing b2g18 to Try will display jobs that are always orange on b2g18 as they hadn't been greened up back at the time of gecko18 (eg jetpack, Bg, OS X debug M1+3, B2G reftests etc).

I think the easiest solution here would be to just take over one of the twig repos, and set it up like Try (ie multiple heads, no coalescing, ...) but use the rest of the buildbot config from b2g18. We could then set the TBPL job visibility for that tree to mirror that of b2g18.
(In reply to Ed Morley [:edmorley UTC+1] from comment #1)
> There are two main problems:
> 
> 1) Try's config for buildbot mirrors mozilla-central et al, which has since
> diverged from the config used for release trees such as b2g18/esr17. eg: The
> move from real hardware fedora slaves to ubuntu amazon EC2 machines has
> occurred for trunk (and thus try) and will work it's way through the trains
> - however b2g18 doesn't have the in-tree reftest tweaks that greened them up
> on VMs (bit of disabling, bit of marking fuzzy-if and a few other changes
> iirc).
> 
> 2) TBPL manages job visibility per tree. Try's job visibility needs to match
> that of the trunk trees - which means even if buildbot configs weren't an
> issue, pushing b2g18 to Try will display jobs that are always orange on
> b2g18 as they hadn't been greened up back at the time of gecko18 (eg
> jetpack, Bg, OS X debug M1+3, B2G reftests etc).
> 
> I think the easiest solution here would be to just take over one of the twig
> repos, and set it up like Try (ie multiple heads, no coalescing, ...) but
> use the rest of the buildbot config from b2g18. We could then set the TBPL
> job visibility for that tree to mirror that of b2g18.

If we really want to be try-like, we should consider making the repo level 1 access, and running builds in the try pool, too.
Component: Release Engineering → Release Engineering: Automation (General)
QA Contact: catlee
(Assignee)

Updated

5 years ago
Product: mozilla.org → Release Engineering

Comment 3

4 years ago
Given bug 875164, this is wontfix.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

a month ago
Component: General Automation → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.