Re: Jenkins nullpointer exception - git checkout branch / tag
I fill a bug report: https://issues.jenkins-ci.org/browse/JENKINS-26350 Le lundi 5 janvier 2015 16:58:23 UTC+1, ycollet a écrit : Hello, I upgraded to last version of jenkins (1.592) and updated to last version of plugins. I've got a project which checkout a tag from a git repo and compiled java code using ant. The project use a string parameter and this string parameters is sent to the git plugin to checkout a branch or a tag. If I put a branch name as a parameter for the checkout, compilation is running fine. If I put a tag as a parameter for the checkout, a stack trace is displayed: javax.servlet.ServletException: java.lang.NullPointerException at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:796) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:391) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:391) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at
How to configure Maven Installation via Groovy
I am trying to build a chef recipe to deploy/manage our Jenkins instances.
Things are going reasonably well but the ops-code Jenkin cookbook only
provides some basic configuration recipes. It does give you a resource by
which to run groovy scripts though and with that and the help of a few
blogs I have gotten some basic stuff set up. However, now now I am trying
to do something quite simple in the UI but am stumped about how to do this
with a groovy script: Set up a Maven installation that installs a specific
version automatically.
Here is what I think I have figured out so far:
*import jenkins.model.**
*def inst = Jenkins.getInstance()*
*def desc = inst.getDescriptor('hudson.tasks.Maven')*
*def installs = desc.getInstallations()*
installs in this case seems to have the list of existing installs, but I
cannot figure out how to programatically add an install to it, for instance
I would like to add an installation that is named 'mvn-3-0-5' that
automatically installs maven v 3.0.5.
Any idea on how I can do this? Any help will be much appreciated. Thanks.
--Ken
--
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/563f2849-f165-434d-8f04-83a793c87fcd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Test description set from a Groovy Postbuild script disappears
I finally did it by using these 2 lines for setting and saving (to build.xml) the failed test's description: testResultAction.setDescription(failedTest, description); testResultAction.owner.save(); Thank you very much for your initial help, Daniel! It certainly sent me in the right general direction. Hope this helps others having the same problem. Thanks, Eduard On Wed, Jan 7, 2015 at 6:25 PM, Eduard Moraru enygma2...@gmail.com wrote: The full code progress I mentioned is here: http://hastebin.com/paruraheze.xml Thanks, Eduard On Wed, Jan 7, 2015 at 6:24 PM, Eduard Moraru enygma2...@gmail.com wrote: Hi, I`ve tried a different approach after finding this method: http://javadoc.jenkins-ci.org/hudson/tasks/test/AbstractTestResultAction.html#setDescription%28hudson.tasks.test.TestObject,%20java.lang.String%29 So it seems that TestObjects are not persisted so I would have to use that protected method instead. AFAIK that works in Groovy, even if the method is persisted, so I tried the following, going from bottom-up this time: testResultAction = failedTest.getParentAction() testResult = testResultAction.getResult() testResultAction.setDescription(failedTest, Some description); manager.build.save(); However, no luck! For some reason, even if the setDescription menthod is supposed to set the description in the list of descriptions of the SurefireReport action (subclass of TestResultAction), the save method is not persisting the description in the build.xml file. From setting the description manually, I can confirm that that is the place where it is supposed to be saved and that the SurefireReport action is the right one to use. Maybe I am not calling save() on the right instance? I would really appreciate some help on this one since I am so close to finishing it and I have spent a lot of time going back and forward with it. This is the full code of the progress I`ve done with my script. Just need to save the failed test's description... Thanks, Eduard P.S.: I have stopped pursuing the setResults() method since I am almost sure that even if it saves stuff, it saves it to junitResult.xml and that does not hold descriptions. Again, from manual testing, it seems that build.xml stores the test descriptions inside the SurefireReport action. On Wed, Jan 7, 2015 at 1:30 PM, Eduard Moraru enygma2...@gmail.com wrote: Hi, It seems to make sense what you are saying, however, I can not get to an instance of TestResultAction. I have tried many things and did a lot of printing to see what I am working with. Here is what I get for the following: manager.build.getClass() -- class hudson.maven.MavenModuleSetBuild manager.build.testResultAction.getClass() -- class hudson.maven.reporters.SurefireAggregatedReport manager.build.aggregatedTestResultAction.getClass() -- class hudson.maven.reporters.SurefireAggregatedReport manager.build.getAction(hudson.tasks.junit.TestResultAction.class) -- null manager.build.getAction(hudson.tasks.test.AbstractTestResultAction.class) -- hudson.maven.reporters.SurefireAggregatedReport@bb1453 manager.build.testResultAction.result.getClass() -- class hudson.tasks.test.AggregatedTestResultAction$1 (assuming this one is ChildReport) manager.build.testResultAction.getResult().getClass() -- class hudson.tasks.test.AggregatedTestResultAction$1 (assuming this one is ChildReport) I`m a bit stuck at this point. Any idea? Thanks, Eduard On Wed, Jan 7, 2015 at 1:19 AM, Daniel Beck m...@beckweb.net wrote: Test results are stored in weak references to be discarded in case memory is required for something else. Builds themselves aren't kept in memory either. And the code you have does not persist test results to disk. https://github.com/jenkinsci/junit-plugin/blob/master/src/main/java/hudson/tasks/junit/TestResultAction.java#L123...L142 Something like the following should work (untested): def result = manager.build.testResultAction.result failedTests = result.getFailedTests() // changes to tests in the result here manager.build.testResultAction.setResult(result, manager.listener) You can check whether it works by looking at the junitResult.xml file's modification date and contents and/or restarting Jenkins. On 06.01.2015, at 23:46, Eduard Moraru enygma2...@gmail.com wrote: Hi, I have recently written a pretty nice along the lines of this blogpost http://brknthmb.com/post/76243353208/jenkins-adding-selenium-screenshots-to-test (with some modifications). It is working great... however only for about 1 hour. After that, any descriptions set by the postbuild script (e.g. someCaseResult.description = Some Description) on a failed test vanish like they were never there. When I come back later I only see the option Add description instead of the previously set description. There is even an example in the plugin's documentation (
Re: Jenkins nullpointer exception - git checkout branch / tag
It looks like this is a git plugin bug ... A regression in the behavior of the git plugin. -- 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/1dea681b-72fc-4606-9966-e8da0640c7c5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Open file handles becoming an issue
its not really per job - connections to the http(s) interface also use file descriptors so you need to factor in how many clients you will have connecting and if they use persistent connections and the slaves and type of slaves, how many plugins you have installed - which version of the JDK you have and how its tuned (storing the compiled machine code). The upper burst limit may also depend on what your job does and what type it is - e.g. archiving files will create some FDs whilst the file is being copied across (they should be closed afterwards). I used 10k for several thousand jobs with a few hundred users. I was monitoring it for a while (several years ago) and it did stabalize - I can't recall the exact number. That's not to say there isn't a leak somewhere - but if you up the limit and track it with 'lsof' over a period of days/weeks I think you may see that it is relativley stable, if not you should at least see a common trend of something that is constantly increasing. (a combination of awk sort and uniq should be able to show any upward trends - if you have an executor on the same OS as the master you could also do this through jenkins and use the plot plugin to visualize :-) /James On 07/01/2015 22:05, Sean Last wrote: Ok, i'll up the limit, but is there any metric I can use for what's reasonable versus what's worrisome in an average case/per job? On Wednesday, January 7, 2015 5:00:55 PM UTC-5, James Nord wrote: The default max file handles in most Linux installs (1024) for Jenkins is woefully inadequate. Java itself will have many open files to libs and jars, jenkins will then have the for jobs, users and slaves. I recall also that the lib used by the fd plugin doesn't count all for descriptors and I think I submitted a patch. It certainly will only get descriptors opened after it is hooked up which is after java itself has got may handles which can give you a significant difference. I would up the limit and then run a periodic check on the file handles to check that there are no leaks over time. On 7 January 2015 20:21:50 GMT+00:00, Sean Last qkt...@gmail.com javascript: wrote: Yes, restarting jenkins completely clears the open files for the jenkins user, even though the jenkins application is unaware of the open files. On Wednesday, January 7, 2015 3:06:39 PM UTC-5, LesMikesell wrote: On Wed, Jan 7, 2015 at 1:55 PM, Sean Last qkt...@gmail.com wrote: And I know I could just up the open files limit for the jenkins user, but I'd really like to know why this is happening so it doesn't just keep growing until it's full regardless of where I put the limit. Off the top of my head, a bug in the JVM you are using sounds likely. Have you tried different versions or checked its issues? And does a jenkins restart drop the number significantly compared to after running a long time? -- Les Mikesell lesmi...@gmail.com -- 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/54AE4746.5040504%40teilo.net. For more options, visit https://groups.google.com/d/optout.
Re: [workflow-plugin] Sharing the workspace between nodes in a workflow
On Thursday, December 11, 2014 10:12:23 PM UTC-5, Sean Flanigan wrote: Alternatively, if I clone the same git repo to both nodes, how can I ensure that they both check out the same git revision? https://issues.jenkins-ci.org/browse/JENKINS-26100 -- 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/1b04926c-3488-4e1d-b142-56255798e97b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Workflow and ArtifactArchiver?
On Thu, Jan 8, 2015 at 9:43 AM, Jesse Glick jgl...@cloudbees.com wrote: On Wednesday, January 7, 2015 7:16:10 PM UTC-5, LesMikesell wrote: A likely scenario would be to trigger a build from polling svn, then building that same svn revision on several types of nodes - even if subsequent commits are done to the repository Covered by: https://issues.jenkins-ci.org/browse/JENKINS-26100 Does this have to be different from build-flow where you could pick up SVN_REVISION and pass it into subsequent builds and picking up those build numbers from the respective build objects for the eventual aggregation of the artifacts into the layout you want? I was sort-of hoping that workflow would have the same capabilities but maintain the master job workspace to track scm polling and collect artifacts, and permit more arbitrary groovy operations. -- Les Mikesell lesmikes...@gmail.com -- 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/CAOAgVpzgFkSk1YfYp6o%3D2qjv5xfEyyPXsQmcgsaRTSKzr3AXtA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [workflow plugin] is there a way to get workflow node steps to show in node history?
On Tuesday, December 16, 2014 10:39:22 PM UTC-5, Kevin wrote: Seems like swapping my RunListener out for an ExecutorListener would work fine for this use case. That would help, though it does not handle flows crossing Jenkins restarts. You are advised to use OnceRetentionStrategy from durable-task-plugin for this purpose, or otherwise check for ContinuableExecutable from an existing retention strategy. Out of curiosity, which cloud is this? It would be nice to update workflow-plugin/COMPATIBILITY.md with a link to any related issue marked with the ‘workflow’ label. -- 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/b569b52e-62cb-4806-b7d3-dcb3b381d5e7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [workflow-plugin] build job gets triggered on any node irrespective of seletion using node
On Tuesday, December 9, 2014 8:50:57 AM UTC-5, Rupali wrote:
node('master') {
build 'test-build'
}
Though I have selected node as 'master' for this step, the build job
test-build gets triggered on some other slave node.
Is this expected behavior?
Yes. The contextual node (if any) is ignored by the ‘build’ step. Whatever
test-build specifies as its assigned label is where it will build.
(If you really need the workflow to decide where the downstream project
should run, you could probably do this somehow with the node label
parameter plugin. But I cannot think of any use case for that.)
--
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/aa7063d7-27d2-4476-b7af-f02ddf4adb9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [workflow-plugin]Reading variables in batch script
On Monday, December 8, 2014 4:09:34 AM UTC-5, Rupali wrote:
But below produces output as *Current directory is: ${myDir}*
node('windows') {
def myDir = pwd()
bat '''echo Current directory is:
echo ${myDir}'''
}
Am I missing some syntax in multiple line batch script?
Groovy question. Use
bat echo Current directory is:
echo ${myDir}
or
bat(/
echo Current directory is:
echo ${myDir}
/)
etc.
--
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/96cad274-43c6-4cff-a43f-7b2928eeb055%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [workflow-plugin] Determine current directory
On Monday, December 8, 2014 3:08:12 AM UTC-5, Rupali wrote: That worked. https://github.com/jenkinsci/workflow-plugin/pull/31 -- 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/ed660872-049d-4ee2-be60-3d99ae008c22%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [workflow-plugin] Error script.sh: command not found when running shell script
On Friday, December 5, 2014 6:35:33 AM UTC-5, Rupali wrote: So I am concluding that Shell script in in *workflow step* is not working on Windows slave. Or more precisely, that shell scripts run via durable-task-plugin (this also includes the CloudBees Long-Running Build plugin) do not work on at least some Cygwin setups. Not surprising, since no one is testing this that I know of (only use of the ‘bat’ step), so pull requests are welcome. The current assumption is that ‘sh’ is available somewhere in the path, which apparently is not true in your case. -- 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/c9e1917d-abcc-40e6-bb75-9f15c1391513%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Workflow and ArtifactArchiver?
On Wednesday, January 7, 2015 7:16:10 PM UTC-5, LesMikesell wrote: A likely scenario would be to trigger a build from polling svn, then building that same svn revision on several types of nodes - even if subsequent commits are done to the repository Covered by: https://issues.jenkins-ci.org/browse/JENKINS-26100 -- 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/ca42315a-36b7-42fd-84d4-158841127173%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Gerrit trigger result for each job - NOT joint result
I answered your question on the dev list [1] but I should have answered it here first. https://groups.google.com/forum/#!topic/jenkinsci-dev/KjsYLD8dzxE /B On Sunday, January 4, 2015 3:50:44 PM UTC+1, Alex wrote: Hi, The Gerrit Trigger plugin allows you to create multiple jobs with the same criteria, and it will automatically join the results together before publishing results into Gerrit. How I can cancel the automatic join of the results so I will have result per job for the same trigger ? Thanks -- 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/ada823ad-8b56-4f13-96ce-7479a6aaaf41%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Open file handles becoming an issue
Awesome, thanks so much. That's very good information. I really appreciate the response! Thanks everyone! On Thursday, January 8, 2015 4:00:36 AM UTC-5, James Nord wrote: its not really per job - connections to the http(s) interface also use file descriptors so you need to factor in how many clients you will have connecting and if they use persistent connections and the slaves and type of slaves, how many plugins you have installed - which version of the JDK you have and how its tuned (storing the compiled machine code). The upper burst limit may also depend on what your job does and what type it is - e.g. archiving files will create some FDs whilst the file is being copied across (they should be closed afterwards). I used 10k for several thousand jobs with a few hundred users. I was monitoring it for a while (several years ago) and it did stabalize - I can't recall the exact number. That's not to say there isn't a leak somewhere - but if you up the limit and track it with 'lsof' over a period of days/weeks I think you may see that it is relativley stable, if not you should at least see a common trend of something that is constantly increasing. (a combination of awk sort and uniq should be able to show any upward trends - if you have an executor on the same OS as the master you could also do this through jenkins and use the plot plugin to visualize :-) /James On 07/01/2015 22:05, Sean Last wrote: Ok, i'll up the limit, but is there any metric I can use for what's reasonable versus what's worrisome in an average case/per job? On Wednesday, January 7, 2015 5:00:55 PM UTC-5, James Nord wrote: The default max file handles in most Linux installs (1024) for Jenkins is woefully inadequate. Java itself will have many open files to libs and jars, jenkins will then have the for jobs, users and slaves. I recall also that the lib used by the fd plugin doesn't count all for descriptors and I think I submitted a patch. It certainly will only get descriptors opened after it is hooked up which is after java itself has got may handles which can give you a significant difference. I would up the limit and then run a periodic check on the file handles to check that there are no leaks over time. On 7 January 2015 20:21:50 GMT+00:00, Sean Last qkt...@gmail.com wrote: Yes, restarting jenkins completely clears the open files for the jenkins user, even though the jenkins application is unaware of the open files. On Wednesday, January 7, 2015 3:06:39 PM UTC-5, LesMikesell wrote: On Wed, Jan 7, 2015 at 1:55 PM, Sean Last qkt...@gmail.com wrote: And I know I could just up the open files limit for the jenkins user, but I'd really like to know why this is happening so it doesn't just keep growing until it's full regardless of where I put the limit. Off the top of my head, a bug in the JVM you are using sounds likely. Have you tried different versions or checked its issues? And does a jenkins restart drop the number significantly compared to after running a long time? -- Les Mikesell lesmi...@gmail.com -- 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/0b37a44a-c40f-47e9-9565-1258e46cf425%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [workflow-plugin] remote node on docker. settings.xml missing
On Monday, December 15, 2014 7:34:05 AM UTC-5, Stefan Lorenz wrote: in my build jobs I use the Config File Provider Plugin https://wiki.jenkins-ci.org/display/JENKINS/Config+File+Provider+Plugin for sharing files like settings.xml with the remote docker jenkins nodes. How do I use it in workflow-plugin? I filed: https://issues.jenkins-ci.org/browse/JENKINS-26339 -- 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/1db3eb30-d143-4063-b94f-995c62d4ec5a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Centralized credential for Windows slave configuration
Can anyone help me find a plugin that allows the sharing of a centrally set login-Id/password credential for use in the configuration of a Windows slave? Specifically: Launch Method: “Let Jenkins control this Windows slave as a Windows service” The field names: “Administrator user name” and “Password” The Credentials plugin does not seem to work in that context. I’m using Jenkins 1.580.2 on a Windows server. Richard -- 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/f4c487c5-1ac4-490b-bacd-ae1d2ce6ae0a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Solutions for embedding jenkins status info in external tools?
I've seen github pages like https://github.com/jaredhanson/oauth2orize , which embeds several pieces of info from its related CI system. The simplest piece is the latest build status. I'm aware of https://wiki.jenkins-ci.org/display/JENKINS/Embeddable+Build+Status+Plugin , but that's just the build status. Are there other plugins that can provide other views, like code coverage or other aspects? -- 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/B8D164BED956C5439875951895CB4B2226B0CB8C%40CAFRFD1MSGUSRIA.ITServices.sbc.com. For more options, visit https://groups.google.com/d/optout.
Re: Workflow and ArtifactArchiver?
On Thu, Jan 8, 2015 at 2:37 PM, Jesse Glick jgl...@cloudbees.com wrote: Does this have to be different from build-flow where you could pick up SVN_REVISION and pass it into subsequent builds I am not very familiar with the build-flow plugin and have not heard of such an idiom. subversion-plugin *sets* $SVN_REVISION on the current build but does not automatically check out that revision if such a variable is set ahead of time. With build-flow you pretty much have to create separate jenkins jobs for each step which is klunky in some ways but it lets you pass parameters and subsequently access data from other build objects: b1=build( some_job) b2=build( some_other_job, REVISION: b1.build.properties.envVars[SVN_REVISION] ) (where REVISION is a job parameter, expanded in the svn URL) and then you could run yet another job, passing those build numbers to b3=build( my_artcollector_job, REVISION: b1.build.properties.envVars[SVN_REVISION], BUILD_SELECTOR1: b1.build.number, BUILD_SELECTOR2: b2.build.number ) And those parameters are expanded for the copy artifact plugin to assemble the layout you want, with the final job archiving the include tree from its own svn checkout and the binaries copied from the previous build jobs. In the meantime, as a workaround you could run ‘svn info’ on the master workspace to determine the current revision, keep this in a Groovy variable, and update slave workspaces to that. I think the big picture is that if we want to eliminate the klunky separate job definitions for every step we need a generic mechanism to replace what you can pass into parameterized jobs and get back from the build objects. Or does that already exist? In this scenario I'm looking for something like a matrix build but more programatically controlled and with a different final layout for the build artifacts. -- Les Mikesell lesmikes...@gmail.com -- 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/CAOAgVpzaa-%3DCKD3NmN3ZLJO6bZpS3ymzK9hUdm7CKXOz9TgcVA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [workflow-plugin] no workspace for parallel steps
On Wednesday, November 19, 2014 at 2:16:52 PM UTC-5, Stefan Lorenz wrote: Isn't it possible to get the results from inside a build step? https://issues.jenkins-ci.org/browse/JENKINS-25851 -- 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/afebe14d-886f-4fb4-9276-0e07e87a9f9d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Workflow and ArtifactArchiver?
On Thursday, January 8, 2015 at 12:38:30 PM UTC-5, LesMikesell wrote: Does this have to be different from build-flow where you could pick up SVN_REVISION and pass it into subsequent builds I am not very familiar with the build-flow plugin and have not heard of such an idiom. subversion-plugin *sets* $SVN_REVISION on the current build but does not automatically check out that revision if such a variable is set ahead of time. https://issues.jenkins-ci.org/browse/JENKINS-24141 notes that the current Jenkins core API does not permit an SCM to define environment variables (such as $SVN_REVISION) in a workflow. If that were changed, it would be one possible solution to JENKINS-26100 (for example you could access env.SVN_REVISION after checkout). But there is another possible solution that I think may be more attractive, using scm-api. Still TBD. In the meantime, as a workaround you could run ‘svn info’ on the master workspace to determine the current revision, keep this in a Groovy variable, and update slave workspaces to that. -- 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/4962dca7-143a-4c76-98e3-f4d72bb25919%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [workflow-plugin] publish report on workflow build
On Friday, November 28, 2014 at 9:06:10 AM UTC-5, Arek Skalski wrote: Is there any way to publish html report within workflow build? I filed https://issues.jenkins-ci.org/browse/JENKINS-26343 as the most straightforward approach. -- 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/65c2ad5d-52fa-4095-8f3d-d151426f5a52%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [workflow-plugin] Passing parameters to triggered jobs
On Monday, November 24, 2014 at 6:19:15 AM UTC-5, James Nord wrote:
build job: 'yourJobNameToBuild', parameters: [new hudson.model.
StringParameterValue('PARAM1','123'), new hudson.model.
StringParameterValue('PARAM2','345')]
Though this should be replaced with a more idiomatic form requiring no
direct access to Jenkins
APIs: https://issues.jenkins-ci.org/browse/JENKINS-26093
--
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/a0ff018f-554a-4d13-b5f8-c88cb5baf284%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
