| Re: [wtp-releng] More on build and tests issues ... |
> Does the N-build do any tagging of what
it builds? This would be
> nice as then we could simply release to that tag (if successful) on
> a weekly basis and the only way we should have problem is if
> something truly unusual happens.
No, We never do any automatic tagging of cvs components,
except for maps. Normally, I don't think cvs modules should be tagged,
especially if there has been no changes.
So ... this avenue would be a lot of work for someone
to do (since fairly different from what we do now) and, I'm not sure how
successful it would be. There's a lot of assumptions in there that I don't
think are always true. Plus, the way you describe it seems to work counter
to the principle of continuous integration --- slowly progressing nearer
and nearer to the weekly declared build.
This does remind me, though, of another 'tip' I don't
think we've been doing well .... most of the time, if one of your releases
causes problems, you should be able to immediately revert to the previous
released code fairly easily, until it's understood what the problem is,
and how to solve it, and then re-release it, with fixes .... there's no
reason to "leave it breaking" or "leave JUnits failing"
build after build.
> Also, is there any way to get e-mail when
a build finishes and
> especially if it fails?
Your specific name and address is in the cvs users
file, so you should get a "success" notice, for any build you
have committed to. If you don't get any, maybe this only works for those
who commit the map files?
Everyone in cvs users list is supposed to get an email
if it fails ... if that doesn't seem to be working, let me know and I'll
investigate. There is a problem though, that sometimes the "failure"
isn't a full "BUILD FAILED" event. I will be investigating, though,
detecting JUnit failures and then generating a "BUILD FAILED",
since I think part of the problem is no one looks at the build page on
a regular basis after they release something.
If you want to know about every build, whether you
have committed to it or not, then subscribe to one of the RSS feeds on
the dashboard page. And, if anyone wants to do the work, there's even ways
to set CC up to send IM messages or even change an icon on your system
tray, and many more notification methods!
I can see the FAQ is starting already :)
Thanks for asking.
| From: | CAMERON.BATEMAN@xxxxxxxxxx |
| To: | Webtools releng discussion list <wtp-releng@xxxxxxxxxxx> |
| Date: | 01/28/2008 02:44 AM |
| Subject: | Re: [wtp-releng] More on build and tests issues ... |
I guess this is fine as a start, assuming it works. Does the N-build do any tagging of what it builds? This would be nice as then we could simply release to that tag (if successful) on a weekly basis and the only way we should have problem is if something truly unusual happens.
Also, is there any way to get e-mail when a build finishes and especially if it fails? I used to get this sort of notifications but they have long since stopped.
--Cam
--- Original Message ---
Thanks Cam, these are good constructive comments. 1. On the matter of HEAD builds: These are possible now. We do them on request only, since they have limited value unless someone has made "big changes". (And, since I think all the project's should be able to do this locally ... which is your number 2 point, and also since you should be able to do in a pure development environment -- for example, when I run your tests in org.eclipse.jst.jsf.designtime.tests in my development environment, I get 1 error and 2 failures. You don't? I've opened bug 216704. if it helps provide more data.) So, how do you make a request for a HEAD build? Well, you could post here to wtp-releng. Or, better you could kick one off yourself. Just go to http://build.eclipse.org:7777/dashboard/dashboard?s=1 or http://build.eclipse.org:7777/dashboard/dashboard?s=1 and press "build" on the project called wtp-R3.0-N (n is for the archaic "nightly" build). If you did one now, for example, you'd see there are 23 compile failures in HEAD ... the same thing you'd see if you loaded up head in a special workspace on your machine. (I know, people always says that takes a long time ... but, it's no longer than to do a local build ... the trick is to really have a special workspace, just for this purpose, not necessarily the one you use day-to-day). Of course, Wednesday afternoon, while we are trying to produce a weekly Integration build is not the time to request a HEAD build ... as it could get in the queue in front of an I-build teams were waiting for .... but today would be good :) Well, it would be good, except I was forced to remove your org.eclipse.jst.jsf.designtime.tests from the master list, so those still won't run. So, apologies ... it appears I have not communicating this "on request" feature well enough. 2. On the matter of doing local builds, I suspect it's easier than you think, and its just not documented well. So, will work on that. But, it's a LOT easier than it was 18 months ago! Well, I think. But, in the mean time, ask if questions come up, or open bugs ... I've always found that's the best way to produce a "FAQ" on a topic. And, "ask fast" before frustration sits in. Perhaps we should schedule a "live demo" for some status meeting? Hmm, I wonder if our web-conference software works on Linux :) Also, don't forget you can open bugs (and supply patches :) on things you'd like to see changed. It's definitely a "help wanted" item! You might query for bugs from tran.le ... he's apparently had some success building on oracle's infrastructure (though I'm sure not perfect, since it does pretty much require linux-like systems to build (window's has trouble with some path lengths, and other tasks). Hope this helps, ... thanks for your helpful comments.
Leaving aside the recent issue for which I apologize, and which I think resulted from a combination of miscommunication (Oracle's web e-mail system has been very flaky over the past 72 hours) and tactical problems with our JUnit framework with which we are struggling to address... It seems to me, that the root problem here is that the build system cannot be easily reproduced outside the build servers (at least not at Oracle, by me). The result is that while we make our best effort to ensure that everything builds and tests correctly before committing and releasing, we never really know what's going to happen until we formally release. I suggest one short term and one long term remedy: Short term, re-enable regular HEAD builds. HEAD builds should run at least once per day. Every commericial development shop I've worked in over the past 10 years uses this practice. In this way, we will know as soon as possible if a change we've made is not going to fly. Many of the recent problems coming from JSF have resulted from configuration issues that would have been picked up early by such a mechanism and could have been addressed before an I-build was halted. Long term, let's endeavour to make it simple and easy for any one who wants to, to download and reproduce the build system. I tried about 18 months ago to create a local instance at Oracle and threw my hands up after about a week of trying. If there have been improvements since, that will make it easy, I'm game to give it another kick. If not, let's work on it, starting with the biggest obstacle for us: we don't all live behind transparent web proxies (this is a problem with some WTP frameworks too by the way). To even get the build to download Eclipse dependencies I had to hack the ant scripts extensively to support CVS proxying through the Oracle firewall. --Cam --- Original Message ---
_______________________________________________ wtp-releng mailing list wtp-releng@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/wtp-releng |