Closed Bug 648202 Opened 9 years ago Closed 9 years ago

Fix the polling for comm-2.0, to poll against mozilla-2.0 release branch

Categories

(SeaMonkey :: Release Engineering, defect, critical)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.1final

People

(Reporter: Callek, Assigned: Callek)

Details

The comm-2.0 based pollers seem to be polling against the trunk, and not the release/mozilla-2.0 based setup (Noticed by failures caused from mozilla-revisions in trunk not 2.0)

Also of note in the investigation is that we are generating two changesources that are interesting to our comm-2.0 builder for comm-central, per checkin.

CC-ing catlee incase he has any ideas at hand, especially after my HgPoller changes.

Of note is that I only have reconfigured since applying my change there, have not shutdown/restarted the master.
Severity: normal → critical
Ok actually it is not the HgPoller that is the issue, and sadly this was the case for a while (just didn't catch it because our automation used to always update to default)

http://mxr.mozilla.org/build/source/buildbotcustom/misc.py?mark=1744-1744,1752-1752#1736

This is a problem because for both our comm-2.0 and comm-central-trunk builds, this actually points to the same place.

catlee, how do you feel about s/branch=config['repo_name']/branch=name/ here and in generateBranchObjects. (For poller and Scheduler)

I feel it is more correct, unless there is some trick about the branch format I don't recognize, or some reason that would cause undesirable affects. (It is times like this I wish SeaMonkey had a staging environment I could test these theories/assumptions)
(In reply to comment #1)
> Ok actually it is not the HgPoller that is the issue, and sadly this was the
> case for a while (just didn't catch it because our automation used to always
> update to default)
> 
> http://mxr.mozilla.org/build/source/buildbotcustom/misc.py?mark=1744-1744,1752-1752#1736
> 
> This is a problem because for both our comm-2.0 and comm-central-trunk builds,
> this actually points to the same place.
> 
> catlee, how do you feel about s/branch=config['repo_name']/branch=name/ here
> and in generateBranchObjects. (For poller and Scheduler)

We have some cases where name != repo_name, so this won't work in general.

Why does this help your case here?
well, we have pushlogoverride for HgPoller, which is what we use. But the issue stems from repo_name being used twice for separate |name| branches.

we have config['comm-2.0']            with repo comm-central
we have config['comm-central-trunk']  with repo comm-central

Such that it then notifies the scheduler with |repo_name| and thats where the problem starts, since we also have it with {mozilla-2.0,mozilla-central} for the respective configs.

Which means that a mozilla-central change, gets sent to the scheduler for comm-2.0 due to this. And I wonder if there is a way I can fix this without diverging us from the m-c based generate* here.
Note that you IIRC need to do a buildbot restart to make pollers update for such a branch change (or at least I remember that has been the case some time ago). Did we already have a buildbot restart since we introduced a comm-2.0 that should correctly track mozilla-2.0?
Fixed (worked-around really) by Bug 650552

The issue is that the name='foo' of the poller/scheduler mix is keyed off the repo-name. Which until now was "comm-central" not the name of the buildbot branch we set.

Which meant we had a poller/scheduler combo for

|   repo       |    branch-to-build    |   expected-branch  |
-------------------------------------------------------------
| comm-central |   comm-central-trunk  | comm-central-trunk |
| m-central    |   comm-central-trunk  | comm-central-trunk |
| m-2.0        |   comm-central-trunk  |    <null>          |
| comm-central |   comm-central-trunk  | <duplicate/null>   |
-------------------------------------------------------------
| comm-central |       comm-2.0        |      comm-2.0      |
| m-central    |       comm-2.0        |       <null>       |
| m-2.0        |       comm-2.0        |      comm-2.0      |
| comm-central |       comm-2.0        | <duplicate/null>   |
-------------------------------------------------------------

Which is clearly broken. (the fact that the list is duplicated is due to the two-passes through the generate* stuff with the _same_ repo, so we create them twice, and attach the scheduler each time, with a different set of builders (different branches) while still listening to the one and only poller branch.

(I'm not sure if the above is clear, other than that its worked around for now)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Flags: in-testsuite-
Target Milestone: --- → seamonkey2.1final
You need to log in before you can comment on or make changes to this bug.