564320 - For build-on-checkin project branches, no way to tell which HG branch the build came from

Status: NEW

(Firefox Build System :: General, defect)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

For the addonsmgr project repo, some work has been done in a new HG branch ("perf", instead of "default"). That repo is set to build whenever there's a checkin, so we get builds from that perf branch too (this is good).

However, there's been no way to tell which resulting builds come from which branch (default or perf), without actually running them and trying to spot any subtle differences. I'm more concerned about the filenames of the builds (and/or the directories they get put in), although it may be useful to have them show up separately when getting performance numbers too.

Comment 1

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

To date we haven't supported using more than the default branch, and it would require a bit of work to add that.

You can tell where a build came from by going to about:buildconfig and following the link to hg.m.o, which will then tell you which branch the changeset is on. Obviously this is not ideal.

Comment 2

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

Where I mean 'branch' to be 'named branch' within the addonsmgr repo. That we say 'project branch' when meaning a separate repo is unfortunate in this situation.

Comment 3

[Dave Townsend [:mossop]]

Could we include the hg branch in the txt file that is uploaded along with the builds. That'd probably be a good start.

Comment 4

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

Looks like we don't keep the branch in application/platform.ini, so it'd be a call to hg instead of what's done in bug 529937. Wouldn't be hard though.

Comment 5

[Chris AtLee [:catlee]]

application.ini for http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/addonsmgr-linux/1273189026/firefox-3.7a5pre.en-US.linux-i686.tar.bz2:

[App]
Vendor=Mozilla
Name=Firefox
Version=3.7a5pre
BuildID=20100506163706
SourceRepository=http://hg.mozilla.org/projects/addonsmgr
SourceStamp=a8ef9131036b
ID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}

[Gecko]
MinVersion=1.9.3a5pre
MaxVersion=1.9.3a5pre

[XRE]
EnableProfileMigrator=1
EnableExtensionManager=1

[Crash Reporter]
Enabled=1
ServerURL=https://crash-reports.mozilla.com/submit

Comment 6

[Chris AtLee [:catlee]]

Sorry, I missed the part where you want the in-repo branch name as well.

Comment 7

[[e-mail] (:bhearsum)]

I think this information should be included in application.ini/platform.ini if anywhere, moving this to Core: Build Config

Comment 8

[(not currently active) Ted Mielczarek]

bug 549958 has a patch that will change the format of the .txt files, if you want to discuss adding something there.

Personally I don't think it's worth it, given that almost nobody else is using named branches (also, if you put that in there, all of our Firefox release builds will list the relbranch, which is kind of weird). Plus, if you know the repository and the changeset, you can find the branch just by looking at hgweb or at your local clone, so it's redundant information.

Comment 9

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #8)
> Personally I don't think it's worth it, given that almost nobody else is using
> named branches (also, if you put that in there, all of our Firefox release
> builds will list the relbranch, which is kind of weird). Plus, if you know the
> repository and the changeset, you can find the branch just by looking at hgweb
> or at your local clone, so it's redundant information.

The scenario that prompted this bug was getting someone outside of the project's development team to test a build for us. It's useful to be able to tell them to go to given directory and grab the most recent build. In this case, they ended up with a build from a named branch - which was quite unexpected. So it'd be really useful to have a quick and simple way to tell named-branch builds apart. Looking up a specific changeset is neither of those :)