Your browser was unable to load all of the resources. They may
have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.
Please make sure both servers are running the same QB version if they need to talk to each other.
Hi Robin,
I updated the second server to version 4.0.41.
After that the HTTP response code became 403. I am accessing the second server with the user that has ACCESS_STORAGE, BATCH_DOWNLOAD_ARTIFACTS, RUN_BUILD permissions. What permission is necessary for accessing the second server?
I assume that it is not needed to install second server user agents on the first server machines, right?
Thank you,
Irina
No it does not need to install agents. When this error happens, please open console log of the second build server to paste the error stack trace here.
Robin,
Today I upgraded the first server to exactly the same version, however the result is the same: response status 403.
Thanks much,
Irina
2012-06-06 17:43:37,173 [206582827@qtp-228776471-8384] ERROR com.pmease.quickbuild.rest.providers.AccessDeniedExceptionMapper - Access denied when accessing restful service.
com.pmease.quickbuild.AccessDeniedException: Access denied.
at com.pmease.quickbuild.rest.resources.BuildRequestResource.save(BuildRequestResource.java:87)
at sun.reflect.GeneratedMethodAccessor347.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:149)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:259)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:83)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:71)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:990)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:941)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:932)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:384)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:451)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:632)
at com.pmease.quickbuild.rest.RestServlet.service(RestServlet.java:48)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at com.pmease.quickbuild.web.HttpServiceProvider$1$1.service(HttpServiceProvider.java:87)
at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:126)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.service(HttpServerManager.java:317)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:939)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
This stack trace indicates that the user does not have permission RUN_BUILD on the second server for requested configuration. Can you please double check this?
Robin,
After I included the QuickBuild user into administrators group, the build on another server kicked off. It seems that requesting build via REST requires admin privilege/permission. Thanks much for your help!
I have another question. It s related to this thread in some way. I can create another thread if that's necessary - let me know.
After the build on the second server is kicked off, it is necessary to pass proof workspace so that the second server got the base source control revision as well as the 'local changes'. What is the right way to implement this? Of course, the second server can just grab the entire workspace from the first server without making correspondence to the particular source control repo. But it is not desirable because I want the second server to do both functions: fulfill the build request from the first server and be able to run the build itself without first server involved. If I set proof workspace to ${configuration.getWorkspaceDir()}, then this error appears:
INFO - Getting local change...
13:20:15,056 [master>CheckOutSource@server1:8821] INFO - Updating working copies...
13:20:15,057 [master>CheckOutSource@server1:8821] INFO - Updating working copy: /opt/useragent/bin/D:\<project_dir>\proof/BVT
13:20:15,109 [master>CheckOutSource@server1:8821] DEBUG - Executing command: svn update --non-interactive --username <username> --password ******
13:20:15,109 [master>CheckOutSource@server1:8821] DEBUG - Command working directory: /opt/useragent/bin/D:\<project_dir>\proof/BVT
13:20:15,196 [master>CheckOutSource@cbBVTx86Svr8:8811] INFO - Executing post-execute action...
13:20:15,196 [master>CheckOutSource@cbBVTx86Svr8:8811] ERROR - Step 'master>CheckOutSource' is failed.
...
Caused by: com.pmease.quickbuild.QuickbuildException: Cannot run program "svn" (in directory "D:\<project_dir>\proof/BVT"): java.io.IOException: error=2, No such file or directory
at com.pmease.quickbuild.execution.Commandline.execute(Commandline.java:268)
BTW: Server1 also has user agent installed. Is this correct? Or it should be removed? I guessed it is necessary to grab 'local changes' to the project.
Thank you!
Irina
Hi Irina,
QB does not support this mode of proof build. Files in workspace of the first server has to be passed to second server to work around this.
Regards
Robin
Robin,
Hopefully the last question.
Thank you,
Irina
Up till now I failed to copy files from server1 to server2. I run TriggerBuild step with 'fetch input files' specified as 'Files to Transfer'=**. The files do not appear in the server2 build. Here is the stack:
09:33:58,790 [master>DistributeBuildTargets>ForEachPlatformConfig?BUILD_CONFIG=Release&BUILD_PLATFORM=Win32&BUILD_TYPE=distributed>SelectBuildSystem>RunBuildSteps>IfSyncSuccessful-Build>TriggerBVTRun@CBx64Build8:8811] ERROR - Step 'master>DistributeBuildTargets>ForEachPlatformConfig?BUILD_CONFIG=Release&BUILD_PLATFORM=Win32&BUILD_TYPE=distributed>SelectBuildSystem>RunBuildSteps>IfSyncSuccessful-Build>TriggerBVTRun' is failed.
com.pmease.quickbuild.QuickbuildException: Step is failed since the triggered build is failed, cancelled, or timed out.
at com.pmease.quickbuild.plugin.basis.TriggerBuildStep.run(TriggerBuildStep.java:205)
at com.pmease.quickbuild.plugin.basis.TriggerBuildStep$$EnhancerByCGLIB$$1120c096.CGLIB$run$0(<generated>)
at com.pmease.quickbuild.plugin.basis.TriggerBuildStep$$EnhancerByCGLIB$$1120c096$$FastClassByCGLIB$$62cac4d8.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:215)
at com.pmease.quickbuild.DefaultScriptEngine$Interpolator.intercept(DefaultScriptEngine.java:270)
at com.pmease.quickbuild.plugin.basis.TriggerBuildStep$$EnhancerByCGLIB$$1120c096.run(<generated>)
at com.pmease.quickbuild.stepsupport.Step.execute(Step.java:479)
at com.pmease.quickbuild.stepsupport.StepExecutionJob.executeStepAwareJob(StepExecutionJob.java:29)
at com.pmease.quickbuild.stepsupport.StepAwareJob.executeBuildAwareJob(StepAwareJob.java:47)
at com.pmease.quickbuild.BuildAwareJob.execute(BuildAwareJob.java:61)
at com.pmease.quickbuild.grid.GridJob.run(GridJob.java:78)
at java.lang.Thread.run(Unknown Source)
Sorry the "input files" option will not work between servers. It is used to transfer files from the agent running parent step to the node running current step. The "trigger build" step will run on first server (or an agent belongs to the first server), and it will trigger another build on second server.
To transfer files from one server to another, you need to have files published as artifacts on first server, and then define a QuickBuild repository on second server to point to those artifacts, and finally checkout that repository on build second server.
So transferring files between two standalone QB servers is a bit tedious. I am curious why you want to set up two QB servers and have one server triggering build on another. It will be a lot easier if you only maintain a single QB server, and install a QB build agent on second server to have it connected to first server.
The build on server2 is already implemented, i just want to use it.
Exporting configurations from server2 and importing them into server1 is not supported, so i imagine it would take considerable time to implement it either copying manually or via REST.
QB does have the ability to transfer part of the configuration tree from one server to another. To do so, please set up a configuration and add a step of type "maintenance/sync configurations".
Yes, indeed! Sync step was successful. It is much easier to deal with just one QB server.
Your help is very appreciated, Robin.
