Closed
Bug 497353
Opened 15 years ago
Closed 14 years ago
Thunderbird try server should also run unit tests
Categories
(Mozilla Messaging Graveyard :: Try Server, enhancement, P2)
Mozilla Messaging Graveyard
Try Server
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: gkw, Assigned: standard8)
References
Details
Attachments
(2 files)
438 bytes,
patch
|
Details | Diff | Splinter Review | |
403 bytes,
patch
|
Details | Diff | Splinter Review |
Thunderbird try server should also run unit tests. Cross reference bug 445611 and/or bug 464256.
These unit tests should also have stacks. xref bug 483111
Also note running "packaged unittests on tryserver" at bug 493228
Reporter | ||
Comment 1•15 years ago
|
||
That said, I'm not sure how applicable this is, as TB tryserver stuff is on Amazon S2...
Although, it could offer the download on compile completion, then start (optional?) unit testing after that.
Comment 2•15 years ago
|
||
100% feasible, no reason not to be doing it. I haven't gotten around to porting that part of the try-server logic over to the comm-central way of doing things, that's all.
Updated•15 years ago
|
Severity: normal → enhancement
Assignee | ||
Comment 3•15 years ago
|
||
I'm going to bump this up the priority scale. If we're now requiring tests and we want to avoid landings and backouts due to broken tests (especially MozMill which can be a bit more sensitive to different platforms), we're going to need a try server capable of doing unit tests.
Priority: -- → P2
Comment 4•15 years ago
|
||
Completely agreed that this is important.
Comment 5•14 years ago
|
||
Where in the pantheon of priorities does this dwell? I'm starting to get patch review requests where the patches are not important enough for me to justify the effort of my running mozmill tests locally on all 3 platforms, but where the risk is high enough that I am also unwilling to just have the patch land and potentially require a backout.
I would personally rank this as pretty important because I am going to appear increasingly unresponsive to review requests without this.
Comment 6•14 years ago
|
||
Er, and I want it to run mozmill tests too. Not sure if this bug exactly covers that.
Comment 7•14 years ago
|
||
(In reply to comment #5)
> Where in the pantheon of priorities does this dwell?
The top build engineering priority right now, aside from regular scheduled releases is to get the new tryserver out the door.
We are pretty close to being ready (days, not weeks), and that includes unit tests.
> I'm starting to get patch
> review requests where the patches are not important enough for me to justify
> the effort of my running mozmill tests locally on all 3 platforms, but where
> the risk is high enough that I am also unwilling to just have the patch land
> and potentially require a backout.
Running mozmill tests might be a bit more complicated, but I don't see any significant problems with adding them to the unittest run, maybe some time after the new tryserver is 'out'
> I would personally rank this as pretty important because I am going to appear
> increasingly unresponsive to review requests without this.
Understood.
Assignee | ||
Comment 8•14 years ago
|
||
(In reply to comment #7)
> (In reply to comment #5)
> > I'm starting to get patch
> > review requests where the patches are not important enough for me to justify
> > the effort of my running mozmill tests locally on all 3 platforms, but where
> > the risk is high enough that I am also unwilling to just have the patch land
> > and potentially require a backout.
>
> Running mozmill tests might be a bit more complicated, but I don't see any
> significant problems with adding them to the unittest run, maybe some time
> after the new tryserver is 'out'
gozer, what's the issue with MozMill tests? If it helps, then with a small bit of work we should be able to get those working as packaged tests.
Is there any update or ETA on running MozMill tests on the tryservers?
Keep in mind that many volunteer contributors have just a single platform available for development and testing, so this would provide some relief from
the pain the new test requirements impose, especially as a test may run fine
on one platform but fail on another one.
Assignee | ||
Comment 10•14 years ago
|
||
(In reply to comment #9)
> Is there any update or ETA on running MozMill tests on the tryservers?
As per the weekly status meetings and individual updates, we're working on it.
Current ETA for the new try server is to get it out early this week, hopefully with MozMill tests coming later this week.
> Keep in mind that many volunteer contributors have just a single platform
> available for development and testing, so this would provide some relief from
> the pain the new test requirements impose, especially as a test may run fine
> on one platform but fail on another one.
We know, that is why the new try server has been #1 priority for the build team for the last month or so. It is also why I have been prioritising fixing our MozMill tests for the new try server over switching to libxul for the last couple of weeks, despite the fact the general health of the tree really needs the latter.
Assignee | ||
Updated•14 years ago
|
Component: Release Engineering → Try Server
QA Contact: release → try-server
Assignee | ||
Comment 11•14 years ago
|
||
I've got this running on try server at the moment with a patch to buildbot-custom.
This patch renames the builders "unit" (from "mozmill"), and enables running of both xpcshell-tests and mozmill on those builders.
I'm currently testing the two patches for this bug, with the one for the code from bug 599305 and it is working fine so far...
Assignee | ||
Comment 12•14 years ago
|
||
This previously said "mozmill" in this addition on the local changes you had in buildbotcustom. I'm not proposing we check this in at this stage (unless you want to), just putting it here ftr.
Attachment #478238 -
Flags: review?(gozer)
Comment 13•14 years ago
|
||
Wouldn't it make more sense to have a set of builders doing mozmill only, and another one doing xpcshell tests ?
I just mean that in the current structure of the try stuff, that's the way they are done in Firefox land.
Assignee | ||
Comment 14•14 years ago
|
||
Turning your bit around:
(In reply to comment #13)
> I just mean that in the current structure of the try stuff, that's the way they
> are done in Firefox land.
Generally, although they also have "Other" which has three different sets of tests in it.
> Wouldn't it make more sense to have a set of builders doing mozmill only, and
> another one doing xpcshell tests ?
I think it is a trade off over the amount of time spent downloading and extracting the executable and tests, versus the responsiveness of the results.
As I see you've adjusted try server, I'll push again with the patch so we can get some timing results.
(If you can review bug 599305 as well, then I can push that to c-c as well).
Assignee | ||
Comment 15•14 years ago
|
||
(In reply to comment #14)
> > Wouldn't it make more sense to have a set of builders doing mozmill only, and
> > another one doing xpcshell tests ?
Having looked at the timings, yes I agree it would be better to have one set of builders for mozmill and one for xpcshell.
Assignee | ||
Comment 16•14 years ago
|
||
Comment on attachment 478235 [details] [diff] [review]
Enable xpcshell-tests in package-test builders
This is already live in a slightly modified form and gozer is pushing to the hg repo.
Attachment #478235 -
Flags: review?(gozer)
Assignee | ||
Updated•14 years ago
|
Attachment #478238 -
Flags: review?(gozer)
Comment 17•14 years ago
|
||
changeset: 3024:886cec85dca5
tag: tip
user: Philippe M. Chiasson <gozer@mozillamessaging.com>
date: Mon Sep 27 16:35:02 2010 -0400
summary: Thunderbird Try fixes
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•