Open
Bug 564320
Opened 14 years ago
Updated 2 years ago
For build-on-checkin project branches, no way to tell which HG branch the build came from
Categories
(Firefox Build System :: General, defect)
Firefox Build System
General
Tracking
(Not tracked)
NEW
People
(Reporter: Unfocused, Unassigned)
Details
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•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
Sorry, I missed the part where you want the in-repo branch name as well.
Comment 7•14 years ago
|
||
I think this information should be included in application.ini/platform.ini if anywhere, moving this to Core: Build Config
Component: Release Engineering → Build Config
Product: mozilla.org → Core
QA Contact: release → build-config
Version: other → Trunk
Comment 8•14 years ago
|
||
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.
Reporter | ||
Comment 9•14 years ago
|
||
(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 :)
Updated•6 years ago
|
Product: Core → Firefox Build System
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•