Bugzilla – Full Text Bug Listing
| Summary: | Don't produce and publish bits of bundles with compile errors | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Kim Moir <kim.moir> |
| Component: | Build | Assignee: | pde-build-inbox <pde-build-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | aniefer, daniel_megert, dj.houghton, markus.kell.r, Olivier_Thomann, pwebster |
| Version: | 3.5 | ||
| Target Milestone: | 3.5 M7 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Kim Moir
I agree that such bundles should not end up in the repo but do we have to stop the whole build? In the recent case it was just PDE which was broken. All other downloads (rcp, jdt, etc) are still good. It wouldn't be nice if a compile error in a test plug-in would stop the whole build. Best would be if only bundles with compile errors and bundles that depend on erroneous bundles could be blocked from entering the p2 repository. Andrew, is it possible to configure PDE/Build so it skips a particular bundle if there is a compile error? From my understanding the problems arise in the following scenario: - compile error in pde.core - we still produce a pde.core.jar - other people build against pde.core.jar - other people have bogus content If we detected that there was a compile error in pde.core and if we didn't produce that JAR I think we would be in a better situation. Downstream bundles wouldn't be able to compile but that IMHO is better than allowing them to compile and have broken content. I believe this would help us so the downstream bundles would not have to retag for any rebuilds. (In reply to comment #1) > I agree that such bundles should not end up in the repo but do we have to stop > the whole build? In the recent case it was just PDE which was broken. All other > downloads (rcp, jdt, etc) are still good. Do we have a lot of consumers of "just RCP" from an I build? For me, if the entire thing isn't built, then it may as well have not happened. I could certainly understand for nightly builds, as much incremental content that compiled might be useful (or might make your eclipse non-functional), but the I build is a failure if you don't get the entire SDK + test results out of it. PW > but
>the I build is a failure if you don't get the entire SDK + test results out of
>it.
Not really. Just look back and you'll see that very often people say: "does not affect the quality of the build" i.e. we can start to use the build without waiting for a rebuild which will get us the sdk many hours later.
(In reply to comment #5) > > but > >the I build is a failure if you don't get the entire SDK + test results out of > >it. > Not really. For the tests running, perhaps it's not worth stopping the build ... but that's a convenience for us, not a statement of policy. The integration build is tagged and reflects an effort to show the health of eclipse as this point in time ... tests not running are arguably not worth killing the build for (although they are often will cause a rebuild) but a compile error renders that build a failure. I'm not going to guess which parts are OK and which parts are hooped, if I was going to do that I'd just use a nightly build :-) PW (In reply to comment #3) > If we detected that there was a compile error in pde.core and if we didn't > produce that JAR I think we would be in a better situation. Downstream bundles > wouldn't be able to compile but that IMHO is better than allowing them to > compile and have broken content. I believe this would help us so the downstream > bundles would not have to retag for any rebuilds. > Basically the idea would be that if a particular bundle had compile errors, then delete whatever class files did get produced, which will in turn cause compile errors for depending bundles. Looking at the ant manual, there is an attribute on the javac task (in ant 1.7.1) called "errorProperty" which sets a property when the compile fails. We could use this to determine when the compile failed. I've renamed the summary: basically we don't want to produce and push the bits of a bundle that has compile errors but we should not abort the whole build. If a build has compile errors, none of the bundles that contain the compile errors must be pushed to p2 repos. If this happens the repo is definitely toasted till that bundle recontributes (version change). This should not happen. So not only we should not push the rotten parts to p2 repos, but we should provide a list of bundles affected by the problem if this happens (on the next build, same version but different contents). That check is done with the jar comparator. It should also detect constant changes. The result of that check should be clearly exposed with each build. At least we could notice potential problems before doing an update. The build failed automated message should also go out ASAP so that when the maps are updated a new build can be started immediately ... there's not point in letting the tests run to completion. PW If a bundle fails compilation and we don't publish it to the repository, installation of the SDK zips would fail with unsatisfied dependencies (unless the bundle wasn't actually included in the sdk ide) and we wouldn't actually have anything to run the tests on. This is better implemented in the build side rather than the releng side. This is done. If there is a compile error, then the bundle won't get published unless "p2.publishonerror" is set to true. (Default value is false). This requires the build to be running using "p2.gathering=true". See bug 266488. Generally this will cause the build to fail at assemble time when trying to mirror the results out of the build repository to the final archive. Setting "skipMirroring=true" will bypass this error. (Also using a context containing the same version should succeed, see bug 271848) Similarly, this may cause a build failure for products if the bundle was required by the product. Setting "skipDirector=true" will bypass this error. |