cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Weingärtner <rafaelweingart...@gmail.com>
Subject Re: How to fix Jenkins git workspace issues
Date Wed, 18 May 2016 18:02:55 GMT
Do any of the PMCs have access to those VMs? Or at least admin access to
Jenkins; with admin access we could check the Jenkins Jobs build configs.

On Wed, May 18, 2016 at 2:02 PM, Will Stevens <wstevens@cloudops.com> wrote:

> I have seen quite a few situations where tests are failing and they are
> referencing files that are not even included in that PR.
>
> I have also seen situations like this, so the git workspace (index) has
> fragments of previous CI runs and is no longer in a mergeable state.
>
> > git checkout -b master origin/master
> FATAL: Could not checkout master with start point
> origin/masterhudson.plugins.git.GitException
> <
> http://stacktrace.jenkins-ci.org/search?query=hudson.plugins.git.GitException
> >:
> Could not checkout master with start point origin/master
>         at
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:1962)
> <
> http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute&entity=method
> >
>         at
> org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.checkoutBranch(AbstractGitAPIImpl.java:82)
> <
> http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.checkoutBranch&entity=method
> >
>         at
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGitAPIImpl.java:62)
> <
> http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch&entity=method
> >
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at
> hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:608)
>         at
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:583)
>         at
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:542)
>         at hudson.remoting.UserRequest.perform(UserRequest.java:120)
>         at hudson.remoting.UserRequest.perform(UserRequest.java:48)
>         at hudson.remoting.Request$2.run(Request.java:326)
>         at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>         at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>         at java.lang.Thread.run(Thread.java:745)
>         at ......remote call to H10(Native Method)
>         at
> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
>         at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
>         at hudson.remoting.Channel.call(Channel.java:781)
>         at
> hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:250)
>         at com.sun.proxy.$Proxy131.checkoutBranch(Unknown Source)
>         at
> org.jenkinsci.plugins.gitclient.RemoteGitImpl.checkoutBranch(RemoteGitImpl.java:327)
>         at
> com.cloudbees.jenkins.plugins.git.vmerge.BuildChooserImpl.getCandidateRevisions(BuildChooserImpl.java:78)
>         at
> hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:951)
>         at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1054)
>         at hudson.scm.SCM.checkout(SCM.java:485)
>         at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
>         at
> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
>         at
> jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
>         at
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
>         at hudson.model.Run.execute(Run.java:1738)
>         at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
>         at
> hudson.model.ResourceController.execute(ResourceController.java:98)
>         at hudson.model.Executor.run(Executor.java:410)
> Caused by: hudson.plugins.git.GitException: Command "git checkout -b
> master origin/master" returned status code 1:
> stdout:
> plugins/hypervisors/simulator/src/com/cloud/api/commands/SimulatorAddSecondaryAgent.java:
> needs merge
>
> plugins/hypervisors/simulator/src/org/apache/cloudstack/storage/resource/SimulatorSecondaryStorageResource.java:
> needs merge
> plugins/hypervisors/ucs/src/com/cloud/ucs/structure/UcsCookie.java: needs
> merge
> vmware-base/src/com/cloud/hypervisor/vmware/mo/FeatureKeyConstants.java:
> needs merge
>
> stderr: error: you need to resolve your current index first
>
>         at
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1693)
>         at
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:62)
>         at
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:1956)
>         at
> org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.checkoutBranch(AbstractGitAPIImpl.java:82)
>         at
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGitAPIImpl.java:62)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at
> hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:608)
>         at
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:583)
>         at
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:542)
>         at hudson.remoting.UserRequest.perform(UserRequest.java:120)
>         at hudson.remoting.UserRequest.perform(UserRequest.java:48)
>         at hudson.remoting.Request$2.run(Request.java:326)
>         at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>         at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>         at java.lang.Thread.run(Thread.java:745)
>
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Wed, May 18, 2016 at 12:26 PM, Rafael Weingärtner <
> rafaelweingartner@gmail.com> wrote:
>
> > Me neither.
> > Do we need to open a ticket to infra to check that? Or do we have someone
> > among the PMCs that have access to those VMs?
> >
> > On Wed, May 18, 2016 at 12:51 PM, Daan Hoogland <daan.hoogland@gmail.com
> >
> > wrote:
> >
> > > I hav no access to the nodes so I wouldn't know about that.
> > >
> > > On Wed, May 18, 2016 at 5:36 PM, Rafael Weingärtner <
> > > rafaelweingartner@gmail.com> wrote:
> > >
> > > > Parallel builds will use different workspace, so that should not be a
> > > > problem.
> > > >
> > > > Maybe the “@” symbol it uses to differentiate the workspace folders?
> > > > I mean, when it runs parallel builds, it will use a “@” and then it
> > will
> > > > append a number to identify the builds.
> > > >
> > > > For instance, if we have workspace called “Test”, when running
> parallel
> > > > builds we would get something like: “Test@2” , “Test@3”  and so
> forth.
> > > > That
> > > > “@” symbol in a folder may break some scripts.
> > > >
> > > > Also, if the scripts that are executed were not prepared to run in
> > > > parallel, they might use the very same temp folder and files, which
> can
> > > > cause problems.
> > > >
> > > > On Wed, May 18, 2016 at 12:26 PM, Daan Hoogland <
> > daan.hoogland@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > It also does a mvn clean so that should not be an issue. I am
> > thinking
> > > > more
> > > > > along the line of parallel builds on the same node.
> > > > >
> > > > > On Wed, May 18, 2016 at 5:04 PM, Rafael Weingärtner <
> > > > > rafaelweingartner@gmail.com> wrote:
> > > > >
> > > > > > Is Jenkins configure to clean the workspace before it starts
a
> new
> > > > build?
> > > > > >
> > > > > > It should have an option such as "Delete workspace before build
> > > > starts".
> > > > > >
> > > > > > On Wed, May 18, 2016 at 12:00 PM, Will Stevens <
> > > > williamstevens@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > If Jenkins has problems with fragments being left over
in it's
> > > > > workspace
> > > > > > > which is causing following runs against other PRs to fail,
how
> do
> > > we
> > > > > fix
> > > > > > > that?
> > > > > > >
> > > > > > > Thanks...
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Rafael Weingärtner
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Daan
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Rafael Weingärtner
> > > >
> > >
> > >
> > >
> > > --
> > > Daan
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>



-- 
Rafael Weingärtner

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message