448937 - Nightly updates from 3.0b1pre not working

Status: VERIFIED FIXED

(AUS Graveyard :: Administration, task)

Description

[Mark Banner (:standard8)]

Since I updated to 3.0b1pre I've not received any nightly updates, I've just done some investigations, it seems the aus server knows about 3.0a2pre to 3.0b1pre, but not about 3.0b1pre to 3.0b1pre.

For instance, this url returns that an update is available:

https://aus2.mozilla.org/update/1/Thunderbird/3.0a2pre/2008080200/Darwin_Universal-gcc3/en-US/nightly/update.xml?force=1

but this one:

https://aus2.mozilla.org/update/1/Thunderbird/3.0b1pre/2008080200/Darwin_Universal-gcc3/en-US/nightly/update.xml?force=1

doesn't.

This seems to be the same with the Linux nightlies (I haven't worked out the windows urls to check them).

Did we miss something on the change when we did the switch over to 3.0b1pre?

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

Uh, yeah. We need to update 
  http://mxr.mozilla.org/mozilla/source/webtools/aus/xml/inc/config-dist.php#80
and get it pushed into production on the AUS server. The shortest path is to remove the 'a' in 
   '3.0a*'   =>  'trunk'

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

It's all platforms
  http://update-watch.localgho.st/nightly/production/latest/
and only depends on the build you currently have (via the version substitution in the update query URL).

Comment 3

[Mark Banner (:standard8)]

Moving to AUS/Administration as that seems the most appropriate place.

Comment 4

[Mark Banner (:standard8)]

Attachment: Drop the "a"

This patch just simply drops the "a" from "3.0a*". I'm not sure if we also want to change trunk to comm-central, I couldn't see what effect that would have, apart from just a name, but maybe http://update-watch.localgho.st/nightly/production/latest/ needs it, so I'll attach an alternative patch in a moment.

Michael, can you choose/approve the appropriate patch and push it forward please?

Comment 5

[Mark Banner (:standard8)]

Attachment: Drop the "a" and change to comm-central

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

Changing to a comm-central dir requires follow-on changes to the buildbot master and to the existing snippets. I can't think of anything we gain from that extra work, given there is to be no further development of Thunderbird on CVS (unlike Firefox).

Comment 7

[Mark Banner (:standard8)]

(In reply to comment #6)
> Changing to a comm-central dir requires follow-on changes to the buildbot
> master and to the existing snippets. I can't think of anything we gain from
> that extra work, given there is to be no further development of Thunderbird on
> CVS (unlike Firefox).
> 
Nick, we've already changed to comm-central hg repository/buildbots, so I believe we may have already picked these up? or would there more to do?

http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/

(latest-trunk is just a symlink to latest-comm-central).

Comment 8

[Mark Banner (:standard8)]

Unless you mean that we need to stay with "trunk" because of the previously built (in cvs) 3.0a* builds.

Comment 9

[Nick Thomas [:nthomas] (UTC+12)]

Not really, the issue here is the directory the update snippets live in, not the actual builds. Hopefully the following will make things clearer.

Buildbot runs a job that creates a nightly, pushing the installer/dmg/tarball and a complete update file (mar) to a dated directory and to latest-comm-central. It also creates an update snippet (which describes the location of that build on the ftp server, buildID, version etc) and pushes the snippet to an AUS server.

Another machine comes along and grabs those snippets, downloads complete mars for consecutive builds and creates a partial mar (bundle of binary diffs) between them. It also creates a (slightly different type of) snippet, which describes that partial update, and uploads it to the AUS server. It uses the same basename it pulled from when it pushes back, but on a different path.

When a request is made to AUS, it looks at the application and version of the request and maps that to a particular directory in its data store. This is the config that we're modifying. (The current problem is simply that AUS has no idea to do with a version that matches 3.0 but not 3.0a*.) The configured directory must be the same as where the snippets got pushed to earlier, otherwise still no updates.

So, attachment 332177 [details] [diff] [review] requires no changes to the nightly creation and upload process. The location of the builds is already correctly handled by the code generating the initial snippet.

Attachment 332178 [details] [diff] requires modifying the buildbot config so that it pushes the initial snippet to the new location (gozer), and for me to reach into the partial update generator to ensure everything migrates over properly. It's significantly more co-ordination to do this, since both must happen after the AUS change goes live. I don't think it's worth it, if the only reason is to describe everything on mercurial as "comm-central" instead of "trunk".

Comment 10

[Mark Banner (:standard8)]

Comment on attachment 332178 [details] [diff] [review]
Drop the "a" and change to comm-central

ok, lets just stick with trunk, I see no issues with that.

Comment 11

[Michael Morgan [:morgamic]]

This is checked in, tagged, ready to go.  Bug 449083 for the IT push bug.