1125433 - l10n builds in builds-4hr use a revision and branch combination that does not exist

Status: RESOLVED WORKSFORME

(Release Engineering :: General, defect)

Description

[Ed Morley [:emorley]]

Jobs like:
"Firefox mozilla-aurora linux64 l10n dep"

In builds 4hr have the following properties:

"branch": "mozilla-aurora", 
"buildername": "Firefox mozilla-aurora linux64 l10n dep", 
"en_revision": "default", 
"fx_revision": "79fcabb42355", 
"l10n_revision": "dca8fe9d9425", 
"revision": "dca8fe9d94258eb617529c22107e0e2c7c222025", 
"tree": "fxaurora"

(see bug 1085682 comment 5 for the full blob)

For all other job types, the "branch" matches the "revision". For l10n jobs however, the revision does not exist in that repo.

This causes Treeherder to do unnecessary busy-work trying to backfill revisions that don't exist.

We could blacklist it - but I'd rather fix the bad data in builds-4hr, by either:
a) Changing the branch to something else (eg 'fxaurora')
b) Changing the revision to match fx_revision.
c) Setting the revison to ""

Does anyone have a preference? 
Also where is the code for this?

Thanks :-)

Comment 1

[Rail Aliiev [:rail]]

I think, the revision does exist, but in the corresponding l10n repo, not in the gecko repo.

Maybe we should set the branch to the actual l10n repo path? That may require some changes in the code that handles dep l10n builds.

Comment 2

[Ed Morley [:emorley]]

Yeah sorry I should have explicitly said that it's setting it to the l10n repo revision.

My problem is more that the branch and revision don't match.

If we change the branch to "l10 foo" then Treeherder will be happy, because it ignores branches it does not know about.

Comment 3

[Axel Hecht [:Pike]]

Clearing my needinfo, I can't really help on either of the two systems.

Comment 4

[Chris AtLee [:catlee]]

Yeah, this is because these builds are triggered from changes to the l10n repos, so the revision we're seeing here comes from the hg poller / l10n scheduler.

I'm worried about changing the branch to something else, I have no idea what other code that would break at this point.

Can we wait until bug 740142 is fixed and then look at this again?

Comment 5

[Ed Morley [:emorley]]

(In reply to Chris AtLee [:catlee] from comment #4)
> I'm worried about changing the branch to something else, I have no idea what
> other code that would break at this point.
> 
> Can we wait until bug 740142 is fixed and then look at this again?

Yeah makes sense to wait for that :-)

Comment 6

[Ed Morley [:emorley]]

(In reply to Chris AtLee [:catlee] from comment #4)
> Yeah, this is because these builds are triggered from changes to the l10n
> repos, so the revision we're seeing here comes from the hg poller / l10n
> scheduler.
> 
> I'm worried about changing the branch to something else, I have no idea what
> other code that would break at this point.
> 
> Can we wait until bug 740142 is fixed and then look at this again?

Bug 740142 is fixed, but this is still occurring. I don't suppose you or someone else could take a look? :-)

Comment 7

[Chris AtLee [:catlee]]

I fear that setting the branch to something like 'l10n mozilla-aurora' will break many other things.

Would setting 'revision' to the gecko revision be a reasonable solution?

Comment 8

[Ed Morley [:emorley]]

Yeah that would be fine - the main thing is that then revision the branch match, rather than being a non-existent combo.

Comment 9

[Axel Hecht [:Pike]]

The original culprit were probably l10n depend builds? Those don't run anymore, IIRC?

Comment 10

[Chris AtLee [:catlee]]

You're right! These aren't running any more (bug 1221391).