616708 - Nightly builds no longer seem to include current revisions

Status: RESOLVED DUPLICATE of bug 625417

(Release Engineering :: General, defect)

Description

[Bill Gianopoulos [:WG9s]]

The Windows and Linux 20101204 nightly builds, both of which started at ~3AM PST and would therefore logically be assumed to built from revision c282f8597e03.

In actuality, they were both  built from revision cd392793b0c0, which was the last revision before Midnight Pacific time.

I am not sure if this is a bug, or if this was an intentional change, but if this was intentional, then having the buildid reflect a 3AM timestamp seems to be misleading.

Comment 1

[Chris AtLee [:catlee]]

As per dev.tree-management discussions ([1], [2]), the revision chosen for nightly builds is the most recent revision which has successfully compiled on all our major platforms in the past 24 hours.  Builds from c282f8597e03 hadn't completed by the time the nightly builds started, which is why cd392793b0c0 was chosen.

This work was completed as part of bug 570814.

[1] http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/98d2431051edc7bd/13589ae247a22e79?#13589ae247a22e79

[2] http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/578d0eeaf0286c0f/65887c7805a6f535?#65887c7805a6f535

Comment 2

[Bill Gianopoulos [:WG9s]]

(In reply to comment #1)
> As per dev.tree-management discussions ([1], [2]), the revision chosen for
> nightly builds is the most recent revision which has successfully compiled on
> all our major platforms in the past 24 hours.  Builds from c282f8597e03 hadn't
> completed by the time the nightly builds started, which is why cd392793b0c0 was
> chosen.
> 
> This work was completed as part of bug 570814.
> 
> [1]
> http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/98d2431051edc7bd/13589ae247a22e79?#13589ae247a22e79
> 
> [2]
> http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/578d0eeaf0286c0f/65887c7805a6f535?#65887c7805a6f535

Well, then the problem I have is that I have always started my builds at 3AM pacific and expected them to include the same revisions as nightlies plus the extra patches I am including.  So, how do i ascertain what the correct revision is to check out to get the same build as the nightlies?

Comment 3

[Bill Gianopoulos [:WG9s]]

Oh and I still also think that the buildid timestamp needs to be adjusted to be the time related to the last revision include in the build.

Comment 4

[Bill Gianopoulos [:WG9s]]

I wasted an entire hour this morning trying to figure out why the check-in for bug 616461 was not working in today's nightly.  This new system whatever issue it was trying to solve is just completely confusing.

Comment 5

[Bill Gianopoulos [:WG9s]]

I am making this a regression bug on bug 616461 on the basis that the buildid timestamp is no longer representative of what code is included.  We either need to completely abandon the buildid timestamp, or make it be the time of the last revision included in the build.  No other implementation makes any logical sense here.

Comment 6

[Bill Gianopoulos [:WG9s]]

(In reply to comment #5)
> I am making this a regression bug on bug 616461 on the basis that the buildid
> timestamp is no longer representative of what code is included.  We either need
> to completely abandon the buildid timestamp, or make it be the time of the last
> revision included in the build.  No other implementation makes any logical
> sense here.

Oops I meant bug 570814.

Comment 7

[Chris AtLee [:catlee]]

buildid has never been a good indication of what source was used.  any relationship is purely accidental.

Comment 8

[Chris AtLee [:catlee]]

If you want to know what revision is being used, you can also check the .txt file here:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-4.0b8pre.en-US.linux-i686.txt.

If you want to make buildid represent the time of the latest change, that requires more discussion.  Please start a new thread in the newsgroups, and we can work on the details there.

Comment 9

[Bill Gianopoulos [:WG9s]]

OK.  Great, the way to get the revision used will at least be able to get me to reproduce what I used to do on my daily builds.  I think having the buildid represent the time of the last included change would be less confusing so I will pursue that as well.  Thanks for the pointer to what I needed.

Comment 10

[Chris AtLee [:catlee]]

Do you have an automated system for doing your nightly builds?  You may also be interested in bug 487036, which is about different ways we can expose which revision is used by the nightly builds.

Comment 11

[Bill Gianopoulos [:WG9s]]

Hmm this is trickier than I thought .  If we change to using the time of the last check-in as the buildid timestamp, then if a day goes by, because the tree is closed with no check-ins, 2 nightlies in a row will have the same buildid.

Comment 12

[Bill Gianopoulos [:WG9s]]

Actually there is still an issue here. I need to have a filename that can be used to find the buildid and revision that is the latest mozilla-central build that is NOT dependent on the version like the one pointed out in comment 8 is.

Comment 13

[Chris Cooper [:coop] (he/him)]

(In reply to comment #12)
> Actually there is still an issue here. I need to have a filename that can be
> used to find the buildid and revision that is the latest mozilla-central build
> that is NOT dependent on the version like the one pointed out in comment 8 is.

Just making sure I understand: essentially you want a symlink latest.txt that points to firefox-XXX.en-US.linux-i686.txt ?

Comment 14

[Bill Gianopoulos [:WG9s]]

(In reply to comment #13)
> (In reply to comment #12)
> > Actually there is still an issue here. I need to have a filename that can be
> > used to find the buildid and revision that is the latest mozilla-central build
> > that is NOT dependent on the version like the one pointed out in comment 8 is.
> 
> Just making sure I understand: essentially you want a symlink latest.txt that
> points to firefox-XXX.en-US.linux-i686.txt ?

Something like that would help.  What would actually be even better would be for a file with a name like that could be created when the nightly builds are kicked off.  That way this information would be available at around 3:02 AM, instead of when the first nightly build completes.

However, I am not sure anyone except me actually uses these files, so I would not go out of your way to do anything that is too complicated.

The problem that I have now, however is kind of a chicken and egg thing.  This way can not be used in an automated process because you can't really find out what the name of the file is that you want until after you checkout the source and extract the version information, but you can't do the checkout until you read this file to get the correct changeset.

Comment 15

[Chris AtLee [:catlee]]

I think what you want will probably be served by bug 625417.