| << Back to previous view |
|
[QB-44] re-labeling of QuickBuild repository results in a RuntimeException
|
|
| Status: | Resolved |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical |
| Reporter: | Michael King | Assigned To: | Robin Shen |
| Resolution: | Incomplete | Votes: | 0 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| Environment: | Linux OS | ||
| Description |
|
When I perform a second build where a QuickBuild Repository is defined and a label step is called I get the following build failiure. Not sure if this is the expected result or not. If it is, what would be the correct way of handling labeling from a QuickBuild repository? 2006-03-06 23:12:35,334 [Thread-9403] INFO - Step "eureac batch build" run successfully. 2006-03-06 23:12:35,334 [Thread-9403] INFO - Triggering step "eureca label". 2006-03-06 23:12:35,334 [Thread-9403] INFO - Checking necessary condition of step "eureca label". 2006-03-06 23:12:35,334 [Thread-9403] INFO - Condition satisfied, running step "eureca label". 2006-03-06 23:12:35,335 [Thread-9403] INFO - Labeling repository: eureca trunk repository 2006-03-06 23:12:35,336 [Thread-9403] INFO - Label source path: / 2006-03-06 23:12:35,337 [Thread-9403] INFO - Label url: https://xxxxxxxxxxxxxxxxxxxx/svn/fares-service-tier/eureca/trunk/ 2006-03-06 23:12:48,109 [Thread-9403] INFO - Labeling repository: cougar repostiry CI 2006-03-06 23:12:48,110 [Thread-9403] INFO - Attaching label "eureca-5_9_0-(build-43_0)" on remote build "cougar 1.4.4 (build 264.5)" of configuration "root.Web_Apps.cougar.Continuous_build" at server "http://xxxxxxxxxxxxxxxxxx:7080/app.do". 2006-03-06 23:12:48,160 [Thread-9403] ERROR - Build failed. com.pmease.quickbuild.QuickBuildRemoteException: java.lang.RuntimeException(Label "eureca-5_9_0-(build-43_0)"already exist in configuration "root.Web_Apps.cougar.Continuous_build".) at com.pmease.quickbuild.interceptor.RemoteExceptionConverter.invoke(RemoteExceptionConverter.java:23) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174) at $Proxy2.createLabelOnBuild(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkeleton.java:141) at com.pmease.quickbuild.web.service.HessianService.service(HessianService.java:43) |
| Comments |
| Comment by Robin Shen [ 07/Mar/06 05:11 PM ] |
| Does the first build and second build uses the same build version? If yes, then this is expected behavior of QuickBuild. When label happens for dependent build (remote build), not only the source will be labeled, but also the configuration your project depends on will be labeled to identify which dependent build has been used to construct current build, and this error simply means that this label has already used by a previous build. In order to get around this, for the second build, you need to use another build version (if your "next build version" increases automatically, the build version should change upon every build). |