| Re: [wtp-releng] More on build and tests issues ... |
I went to the site suggested. I see no button for "build". I see a button for "Force Build". I clicked this. An overlay says "your build is scheduled". However, nothing seems to be happening. There is no indication that I can find whether it is queued, building or what.
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 |