Rafael, I think I can access jenkins and download the config. Will, files not included in a PR sticking around "kinda" makes sense as these will not be cleaned by mvn clean on another job????
On Wed, May 18, 2016 at 8:02 PM, Rafael Weingärtner < rafaelweingart...@gmail.com> wrote: > 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 <wstev...@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 < > > rafaelweingart...@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.hoogl...@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 < > > > > rafaelweingart...@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.hoogl...@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 < > > > > > > rafaelweingart...@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 < > > > > > williamstev...@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 > -- Daan
