How to enable build permission for only single item from muliple job
Hi Team, Let me know how i can enable build permission for specific job restricting the other Regards, Archana Srichandan -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BU8sbVSgRC%3D8ERw4k4T3v4RZ4bs4j11qvojkuvWbsG3GGgXHQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Jenkins JUnit Plugin - Unstable issues
Yes: the plugin sets the status to UNSTABLE or SUCCESS. But never to FAILED. > Am 06.05.2019 um 22:17 schrieb cliffhanger...@gmail.com: > > Yes: it sets the status to UNSTABLE or SUCCESS. But never to FAILED. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/F749CAB6-9308-44CF-89F9-A5294FE1EDE0%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Jenkins JUnit Plugin - Unstable issues
You can use my shared library for this:
https://github.com/roel0/jenkins-util-scripts
Example usage:
if (get_junit_results().failed.size()) {
error "some tests have failed" // <- Will set build result to FAILED
}
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/521622e7-c6cf-4543-82af-9cbc8860c1c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Figuring out what is causing a job failure
I set up a freestyle job which has a single "Execute shell" build step, and is run on a remote node. The shell script starts some jobs in the background, then waits for one of them to exit, then kills them all with "killall -9 jobName || echo dead", then at the end it "exit 0" to signal success. There are no post build steps. Despite "exit 0", the job fails. It would be useful if the "FATAL: Remote call on instance-1 failed" message includes the failure reason. There are some "Also:" stacktraces printed, see below, which don't appear when the script contains only "exit 0". Do you think these are related to the failure? How can I find what's causing this failure? --- Console output below --- Started by remote host 1.1.1.1 Building remotely on instance-1 (sim) in workspace /path/to/JobName [JobName] $ /bin/sh -xe /tmp/jenkins6599300392607514127.sh [...] + date Mon May 6 13:38:06 UTC 2019 + echo Done Done + exit 0 FATAL: Remote call on instance-1 failed Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to channel at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1737) at hudson.remoting.Request.call(Request.java:197) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:281) at com.sun.proxy.$Proxy6.fetch3(Unknown Source) at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:209) at java.lang.ClassLoader.loadClass(ClassLoader.java:588) at java.lang.ClassLoader.loadClass(ClassLoader.java:521) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:315) at hudson.util.ProcessTree$UnixReflection.(ProcessTree.java:778) at hudson.util.ProcessTree$UnixProcess.kill(ProcessTree.java:726) at hudson.util.ProcessTree$UnixProcess.killRecursively(ProcessTree.java:747) at hudson.util.ProcessTree$Unix.killAll(ProcessTree.java:666) at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:1096) at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:1087) at hudson.remoting.UserRequest.perform(UserRequest.java:210) at hudson.remoting.UserRequest.perform(UserRequest.java:53) at hudson.remoting.Request$2.run(Request.java:364) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:834) java.lang.ClassNotFoundException: Classloading from system classloader disabled at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch4(RemoteClassLoader.java:854) at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch3(RemoteClassLoader.java:889) at sun.reflect.GeneratedMethodAccessor9164.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:929) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at org.jenkinsci.remoting.CallableDecorator.call(CallableDecorator.java:19) at hudson.remoting.CallableDecoratorList$1.call(CallableDecoratorList.java:21) at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46) at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:71) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to instance-1 at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) at hudson.remoting.UserResponse.retrieve(UserRequest.java:389) at hudson.remoting.Channel.call(Channel.java:955) at hudson.Launcher$RemoteLauncher.kill(Launcher.java:1084) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:510) at hudson.model.Run.execute(Run.java:1819) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.Res
Re: Run pipeline flyweight executors off of master
I have a similar issue. Among running pipelines we have also some matrix jobs. And allowing pipelines to even trigger requires allowing matrix parents on master. Matrix parents happen to clone SCM first and then they run sub-jobs. This can easily end up consuming all space on jenkins master. In my oppinion it is a bad approach forcing pipelines flyweight executor run on master. I am not sure if this is bad approach of jenkins pipelines or matrix project plugin. On Tuesday, January 24, 2017 at 11:46:12 PM UTC+1, Spencer Malone wrote: > > We just encountered this very thing. Large repo with lots of PRs, threw in > a very simple Jenkinsfile and there was an organization folder set up. It > cloned a copy of the repo for each PR, since they all got triggered > together, and very quickly ran out of space. We had kept the disk space > relatively small on the master, since we didn't let it have any executors, > but now we know. Has anyone figured out a long term fix for this? > > On Wednesday, August 10, 2016 at 2:31:45 PM UTC-4, Kevin Phillips wrote: >> >> In my opinion, even more problematic than possibly running unsafe code in >> a flyweight executor on the master is the fact that these flyweight >> pipeline threads perform a full checkout of the target repository - at >> least when using Git as the SCM. So if one has a relatively large code >> repository containing product code - say several gigabytes - and they want >> to store their Jenkinsfile with the code so they can leverage the >> MultiBranch options in Jenkins Pipeline, they end up with many copies of >> their entire codebase being checked out on the master, possibly causing the >> master to run out of disk space. Add to this the fact that these >> "temporary" workspaces created on the master by the flyweight tasks are not >> automatically deleted when not in use and there is no way to purge them >> from the Jenkins dashboard and you are just asking for problems. This isn't >> a case of whether this will become a problem as much as it is an issue of >> when it will become a problem. >> >> In my opinion, Jenkinsfile's stored in SCM should be checked out on an >> agent as a typical freestyle job would do, and a default "node" allocated >> by the executor that launches the script contained therein for the node on >> which it is already running on. Then the rest of the Jenkinsfile could be >> processed in place without requiring any sort of flyweight executor at all, >> and avoiding the issues with having multiple checkouts of the same code >> spread across a build farm. Also, I think this would be inline with how >> some other more modern continuous integration servers work like travis-ci, >> so it's not without precidence. >> >> On Monday, June 13, 2016 at 6:03:20 PM UTC-3, Eli White wrote: >>> >>> We follow the Jenkins configuration best practices and have no executors >>> on our master node and force everything to run on our agents. >>> >>> We are starting to work with pipeline jobs and are worried that bad >>> Jenkinsfiles could cause problems on our master. >>> How can we force the flyweight jobs to run on a designated machine >>> *other* than master? >>> >>> How do other people handle this? >>> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/86678208-2048-4d85-af89-21ae4dd9d0c2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
ERROR : Unable to find build script
Hi When I am trying to build the code in Jenkins with SVN by invoking ANT, I am facing the below error ERROR : Unable to find build script at C:\Program Files\Jenkins\workspace\sampleproject\trunk\build.xml Finished: FAILURE Please do the needful. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8ab03199-f646-4664-8d71-355b5a3e04dc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Figuring out what is causing a job failure
If I remember correctly, the non 0 status of the command is enough to exit. Your exit 0, will not be executed. There is a workaround for that. On Tue, May 7, 2019 at 3:28 PM Alexandru Băluț wrote: > I set up a freestyle job which has a single "Execute shell" build step, > and is run on a remote node. The shell script starts some jobs in the > background, then waits for one of them to exit, then kills them all with > "killall -9 jobName || echo dead", then at the end it "exit 0" to signal > success. There are no post build steps. > > Despite "exit 0", the job fails. It would be useful if the "FATAL: Remote > call on instance-1 failed" message includes the failure reason. > > There are some "Also:" stacktraces printed, see below, which don't appear > when the script contains only "exit 0". Do you think these are related to > the failure? > > How can I find what's causing this failure? > > --- Console output below --- > > Started by remote host 1.1.1.1 > Building remotely on instance-1 (sim) in workspace /path/to/JobName > [JobName] $ /bin/sh -xe /tmp/jenkins6599300392607514127.sh > > [...] > > + date > Mon May 6 13:38:06 UTC 2019 > + echo Done > Done > + exit 0 > FATAL: Remote call on instance-1 failed > Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to channel > at > hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1737) > at hudson.remoting.Request.call(Request.java:197) > at > hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:281) > at com.sun.proxy.$Proxy6.fetch3(Unknown Source) > at > hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:209) > at java.lang.ClassLoader.loadClass(ClassLoader.java:588) > at java.lang.ClassLoader.loadClass(ClassLoader.java:521) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:315) > at > hudson.util.ProcessTree$UnixReflection.(ProcessTree.java:778) > at > hudson.util.ProcessTree$UnixProcess.kill(ProcessTree.java:726) > at > hudson.util.ProcessTree$UnixProcess.killRecursively(ProcessTree.java:747) > at hudson.util.ProcessTree$Unix.killAll(ProcessTree.java:666) > at > hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:1096) > at > hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:1087) > at hudson.remoting.UserRequest.perform(UserRequest.java:210) > at hudson.remoting.UserRequest.perform(UserRequest.java:53) > at hudson.remoting.Request$2.run(Request.java:364) > at > hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) > at java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:834) > java.lang.ClassNotFoundException: Classloading from system classloader > disabled > at > hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch4(RemoteClassLoader.java:854) > at > hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch3(RemoteClassLoader.java:889) > at sun.reflect.GeneratedMethodAccessor9164.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:929) > at hudson.remoting.Request$2.run(Request.java:369) > at > hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) > at > org.jenkinsci.remoting.CallableDecorator.call(CallableDecorator.java:19) > at > hudson.remoting.CallableDecoratorList$1.call(CallableDecoratorList.java:21) > at > jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46) > at > jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:71) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to instance-1 > at > hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) > at hudson.remoting.UserResponse.retrieve(UserRequest.java:389) > at hudson.remoting.Channel.call(Channel.java:955) > at hudson.Launcher$Re
