986523 - https://git.mozilla.org/?p=releases/gecko.git;a=summary is not up-to-date

Status: RESOLVED INVALID

(Infrastructure & Operations Graveyard :: CIDuty, task)

Description

[Armen [:armenzg]]

If I load the WebUI I can see that the most recent change was from 17 hours ago:
http://people.mozilla.org/~armenzg/sattap/09f67f24.png
https://git.mozilla.org/?p=releases/gecko.git;a=commit;h=97b94e3bc08b47f73ad72c401bcbfd64c48559bb

It is currently missing 4 pushes.

I see a lot of vcs2vcs emails with deceiving subjects, however, none of them talk about mozilla-central in their body.


Old similar bug (bug 813720)

Comment 1

[Armen [:armenzg]]

It just updated. We're out of the woods.

aki, hwine: what can be done to investigate what happened?

Should we have a nagios check of some sort?

Comment 2

[Armen [:armenzg]]

I assume this could affect the b2g builds as they would be cloning older repos.
Unless we clone from hg for the b2g builds.

Comment 3

[hwine]

The repository has been quite busy this morning with commits on other branches. The merge prior to trunk merge took ~45min to convert.

This can not affect the b2g builds as:
 a) for gecko, the pull is from the RoR on hg, and
 b) no manifest can know of a git sha until _after_ the conversion completes. :)

Since there are fewer commits directly to m-c these days, conversion time is more "bursty" as the merges from inbound arrive in large chunks.

If this is an ongoing issue, we can look at tuning legacy or expediting the cutover to the new system.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

(In reply to Hal Wine [:hwine] (use needinfo) from comment #3)
> This can not affect the b2g builds as:
>  a) for gecko, the pull is from the RoR on hg, and
>  b) no manifest can know of a git sha until _after_ the conversion
> completes. :)

I don't know if it affects the automated builds, but it does affect local developer builds, since they pull from git.m.o - that's how I discovered this problem to begin with; a change that landed yesterday wasn't showing up when I pulled.

Comment 5

[hwine]

Can you provide details on your commit, please?

What's is the commit ID?
Which repository did you commit it to?
When did you do that commit?

Remember, if you push to one of the inbound branches, it won't arrive in gecko.git until after the sherriffs merge that inbound to mozilla-central.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

The commit I was interested in was the one that landed at https://hg.mozilla.org/integration/mozilla-inbound/rev/b10649cebf55 - I am following the bug and was aware that it had merged to central. So earlier today when I updated my B2G repo I expected it to be there but it wasn't. That's when I went looking at git.m.o and noticed that the master branch hadn't updated since yesterday.

Comment 7

[hwine]

Let's follow that timeline -- all times converted to UTC:
 2014-03-20 18:36 committed to dev's repository per
                  https://hg.mozilla.org/integration/mozilla-inbound/rev/b10649cebf55
1h 36m pass
 2014-03-20 20:12 pushed to mozilla-inbound per
                  https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=b10649cebf55
18h 03m pass
 2014-03-21 14:15 merged to mozilla-central per
                  http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=b10649cebf55
0h 15m pass
 2014-03-21 14:30 started conversion to gecko.git (internal logs)
0h 41m pass
 2014-03-21 15:11 finished conversion to gecko.git (internal logs)
                     To git+ssh://git.m.o/releases/gecko.git
                     97b94e3..bdd8e0a  master -> master
                     17b29bf..9680cfc  aurora -> v1.4
 
So, the changeset was available on git.m.o about 1 hour after it landed on mozilla-central. Given the size of the mozilla-inbound to mozilla-central merge, that is as expected.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Ah, I didn't expect it to take 1 hour for the conversion.

I was also surprised when it said that the last update to master was "17 hours ago" even though I could see a merge to m-c on tbpl yesterday evening (~12 hours ago). I missed the fact the timestamp on cset c148f0b0c8b4 is from 17 hours ago and so that's what git.m.o reported - my mistake.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

So then this is invalid?