Re: Activity with the covcomplplot-plugin
The best thing would be to write an email to the developer of the plug-in. If you don't get an answer we would encourage you to take over the ownership of the plug-in and apply the changes… Ulli Am 05.05.2013 um 17:34 schrieb Stanton Sievers siever...@gmail.com: Hi, I recently started using the covcomplplot-plugin in some of my Jenkins jobs as a supplement to the Cobertura code coverage metrics currently being produced. I found an issue with the plugin and have submitted a pull request on GitHub [1]. However, the plugin doesn't seem to have active development (last commit was 5 months ago) and I'm wondering how to go about getting my fix reviewed, (hopefully) into this plugin, and a new release generated with my changes. Any guidance would be appreciated. Thanks, -Stanton [1] https://github.com/jenkinsci/covcomplplot-plugin/pull/1 -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: LTS 1.509.???
Hi, yes, 1.509.2 was intended to be release soon after 1.509.1, so IMHO no problem to go on with 1.509.2 once the fixes are backported. Any other proposals for backports? If so, please mark them with lts-candidate label [1]. Vojta [1] https://wiki.jenkins-ci.org/display/JENKINS/LTS+Release+Line#LTSReleaseLine-Backportingprocess On Monday 06 May 2013 07:18:58 domi wrote: Hi all, I wonder whether we could already talk about the next minor update of the LTS Release… There are quite some bigger bugs fixed which are really harmful - specially in big company installations which typically use the LTS: https://issues.jenkins-ci.org/browse/JENKINS-17508 (this one is relay harming big installations) https://issues.jenkins-ci.org/browse/JENKINS-17775 https://issues.jenkins-ci.org/browse/JENKINS-17402 https://issues.jenkins-ci.org/browse/JENKINS-16845 There might be others, but I just wanted to start the discussion. regards imod/domi signature.asc Description: This is a digitally signed message part.
Plugin for Android tests
Hi Dev's, I am running android automation tests through Robotium. Right now i dont see an appropriate plugin for running tests. I added a batch command to run adb shell command. What happens is, even if there are assertion failures, jenkins makes the build unstable. Please suggest a better approach to achieve this or an appropriate plugin for the same. -- - Thanks and regards, Karthik.SK -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Plugin for Android tests
not totally sure about adb shell launching but did you try https://wiki.jenkins-ci.org/display/JENKINS/Android+Emulator+Plugin ? On Mon, May 6, 2013 at 7:44 AM, SK Karthik karthik.krishnag...@gmail.comwrote: Hi Dev's, I am running android automation tests through Robotium. Right now i dont see an appropriate plugin for running tests. I added a batch command to run adb shell command. What happens is, even if there are assertion failures, jenkins makes the build unstable. Please suggest a better approach to achieve this or an appropriate plugin for the same. -- - Thanks and regards, Karthik.SK -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How do I publish a pre-release plugin for others to smoke test?
Hi Slide, On second read of your email I realized I'd misread what you suggested and I'd added the user/pass for server repo.jenkins-ci.org to my settings.xml. That didn't help, but once I added the user/pass for maven.jenkins-ci.orgas you'd suggested, I was away to the races. I've successfully built my second release now of the Team Concert Plugin. http://maven.jenkins-ci.org:8081/content/repositories/releases/org/jenkins-ci/plugins/teamconcert/1.0.4/ Thanks so much for your help! Scott On Friday, May 3, 2013 3:39:56 PM UTC-4, Scott Cowan wrote: I'm not sure how I would do this from my job. I don't have access to a .m2/settings.xml there and I don't want to put my user/password on the command line. Maybe it's not correct to think my build should deploy to the repo snapshots? https://buildhive.cloudbees.com/job/jenkinsci/job/teamconcert-plugin/configure Oddly enough, this is now also failing with the same reason phrase, Unauthorized when I run, mvn -X -U -B release:prepare release:perform -Dusername=scowan -Dpassword=password locally, yet I can log in to http://repo.jenkins-ci.org with the same credentials. Can anyone suggest a test I can run? Do I need to be given authorization to upload? If so, why my the teamconcert 1.0.1 release pass? Thanks a bunch! Scott [INFO] Uploading: http://maven.jenkins-ci.org:8081/content/repositories/releases/org/jenkins-ci/plugins/teamconcert/1.0.3/teamconcert-1.0.3.hpi [INFO] Uploading: http://maven.jenkins-ci.org:8081/content/repositories/releases/org/jenkins-ci/plugins/teamconcert/1.0.3/teamconcert-1.0.3.pom [INFO] [INFO] [INFO] [INFO] BUILD FAILURE [INFO] [INFO] [INFO] [INFO] Total time: 6:43.468s [INFO] [INFO] Finished at: Fri May 03 15:08:27 EDT 2013 [INFO] [INFO] Final Memory: 66M/142M [INFO] [INFO] [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy (default-deploy) on project teamconcert: Failed to deploy artifact s: Could not transfer artifact org.jenkins-ci.plugins:teamconcert:hpi:1.0.3 from/to maven.jenkins-ci.org( http://maven.jenkins-ci.org:8081/content/repositories/ releases): Failed to transfer file: http://maven.jenkins-ci.org:8081/content/repositories/releases/org/jenkins-ci/plugins/teamconcert/1.0.3/teamconcert-1.0.3.hp i. Return code is: 401, ReasonPhrase:Unauthorized. - [Help 1] [INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy (default-deploy) o n project teamconcert: Failed to deploy artifacts: Could not transfer artifact org.jenkins-ci.plugins:teamconcert:hpi:1.0.3 from/to maven.jenkins-ci.org (http:/ /maven.jenkins-ci.org:8081/content/repositories/releases): Failed to transfer file: http://maven.jenkins-ci.org:8081/content/repositories/releases/org/jenkins-c i/plugins/teamconcert/1.0.3/teamconcert-1.0.3.hpi. Return code is: 401, ReasonPhrase:Unauthorized. [INFO] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) [INFO] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) [INFO] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) [INFO] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) [INFO] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) [INFO] at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) [INFO] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) [INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) [INFO] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) [INFO] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) [INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) [INFO] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) [INFO] at java.lang.reflect.Method.invoke(Method.java:611) [INFO] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) [INFO] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) [INFO] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) [INFO] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Re: A possible fix for Jenkins-14551 - subversion-plugin duplicating file contents
meeging is good, but NOT SCREWING UP with the consequences this change can
cause I would suggest to do extensive testing. Some bussinesses rely on this
pligins stability...
--
Sent from my Nokia N9
On 02/05/2013 10:05 Kenny Ayers wrote:
KK - any word on integrating this pull request?
On Friday, April 26, 2013 3:48:43 PM UTC-7, Kenny Ayers wrote:
Ah, I see... perhaps I can bribe him with mail-order cookies or beer or
something...
I'll do a pull request on my change, and see if that gets the ball rolling.
Thanks for the replies,
Kenny
On Friday, April 26, 2013 2:45:04 PM UTC-7, Stephen Connolly wrote:
The process I usually follow is to beg KK to do the merge pleading that it blew
up in my face and there is no way he could do it during his lunchbreak...
Though I may be using the no way you could do that in your lunchbreak dare a
bit too often... he may have wised up to my tricks... perhaps I need to find a
new one ;-)
On 26 April 2013 22:39, Kenny Ayers theother...@gmail.com wrote:
Hey Stephen,
Alexander Kitaev from SVNKit has peer-reviewed this change and has rolled it
into the upstream libraries, and the new binaries are available here:
http://teamcity.tmatesoft.com/viewLog.html?buildId=6105tab=artifactsbuildTypeId=bt43
(http://issues.tmatesoft.com/issue/SVNKIT-368#comment=60-4930). I'm not sure
what the process is for getting this updated in the plugin, please let me know
if there is anything else I can do to help.
Thank you,
Kenny
On Friday, April 26, 2013 3:04:03 AM UTC-7, Stephen Connolly wrote:
Traditionally, the jenkins fork is maintaining a (hopefully) smaller set of
patches on top of the upstream version.
The aim is to get the set of patches to zero and then drop the fork.
With reference to the above aim, my preference would be to get it in upstream
rather than add to our current patch set.
It is a real pain trying to update the code from upstream, at least every time
I have tried I have had to give up and get KK to do it (he has some set of
magic workspaces or something) so I would just love if we can get the need for
this fork to disappear completely
-Stephen
On 26 April 2013 03:22, Kenny Ayers theother...@gmail.com wrote:
Hi folks,
Short Version:
I may have a fix for Jenkins-14551
(https://issues.jenkins-ci.org/browse/JENKINS-14551). I've submitted this
potential resolution to SVNKit as well as their 1.7.6 SVN branch has the same
issue (http://issues.tmatesoft.com/issue/SVNKIT-368). I've compiled the change
into the subversion-plugin on my test server, and the fix appears to work.
Can a contributor peer review this change?
How do I go about submitting this fix to the Jenkins SVNKit repo? Do I need
a unit test before I can do a pull request? The bug is obvious when you look
at the code, and the unit test setup and execution seems like it would be
complicated. I've forked the Jenkins SVNKit repo and committed the
modification here:
https://github.com/theotherwhitemeat/svnkit-1/commit/27decb28216ee4fd15b8fcbdb769bf41d81978eb
Longer Version:
In org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor15.java, in function
addFileWithHistory (line 867), there's a code block that calls
myFileFetcher.fetchFile() twice. Each time this is called, baseTextOS is
written to. Upon the second write, the file contents are duplicated. Here's
the code:
baseTextOS = SVNFileUtil.openFileForWriting(info.copiedBaseText);
myFileFetcher.fetchFile(copyFromPath, copyFromRevision, baseTextOS,
baseProperties);
SVNChecksumOutputStream checksumBaseTextOS = new
SVNChecksumOutputStream(baseTextOS,
SVNChecksumOutputStream.MD5_ALGORITHM, true);
baseTextOS = checksumBaseTextOS;
myFileFetcher.fetchFile(copyFromPath, copyFromRevision, baseTextOS,
baseProperties);
info.copiedBaseChecksum = checksumBaseTextOS.getDigest();
I was able to find this by stepping through the code using NetBeans IDE 7.3
attached to a remote debugging session on Jenkins. I've compiled and tested
this change inside the context of the subversion-plugin and the file contents
are no longer duplicated.
I've forked the svnkit repo used in Jenkins here, and committed this change
if anyone would like to download the fix and do some testing:
https://github.com/theotherwhitemeat/svnkit-1/commit/27decb28216ee4fd15b8fcbdb769bf41d81978eb
Here's my patch:
Index: SVNUpdateEditor15.java
===
--- SVNUpdateEditor15.java (revision 9722)
+++ SVNUpdateEditor15.java (working copy)
@@ -864,7 +864,6 @@
OutputStream baseTextOS = null;
try {
baseTextOS =
SVNFileUtil.openFileForWriting(info.copiedBaseText);
-myFileFetcher.fetchFile(copyFromPath, copyFromRevision,
baseTextOS, baseProperties);
SVNChecksumOutputStream checksumBaseTextOS = new
SVNChecksumOutputStream(baseTextOS,
Re: Modifying the computer list view with a plugin
Bump! On Thursday, May 2, 2013 9:20:51 AM UTC+4, Marc MacIntyre wrote: I can't seem to find an extension point that allows modifying the way computers are displayed in a list (in /computer); I see the ListView, but that seems specific to the display of jobs. Do I have to create a completely new view to display the Computers in a new way? -- Marc MacIntyre -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Let Axis values refer to custom ToolInstallation entries
On 05/03/2013 06:46 AM, Alexander R. wrote: Would you suggest a custom Axis implementation? Yes, this would make sense. Job definer picks the ToolInstallation subtype (e.g. Ant, MATLAB, whatever), and whoever triggers the build selects the installation from among those defined of that type. Then if the parameter is called ANT then you would define environment variables $ANT with the name of the tool and $ANT_HOME with its defined home directory (substituted for the actual matrix configuration build of course). Would be a great little plugin. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Problem releasing plugin
Hello, I'm trying to release my plugin without any luck so far. I have followed all steps listed here https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins but I get the build error you see below. As the link mentions, my jenkins-ci username and github username are different, but I have already added my public key to Github and started a ssh-agent and the outcome is the same. The following line shows that it is trying to push a tag to my github account but with wrong credentials: [INFO] Executing: /bin/sh -c cd /home/esteban/Workspaces/Jenkins-Sonargraph-plugin/sonargraph-plugin git push ssh://esteban_h2m:conga01...@github.com/jenkinsci/sonargraph-plugin.git sonargraph-plugin-1.0 It is pushing with the jenkins-ci username stored in the settings.xml Any Ideas on how to solve this? esteban@esteban-VirtualBox:~/Workspaces/Jenkins-Sonargraph-plugin/sonargraph-plugin$ mvn release:prepare release:perform [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building Sonargraph Plugin 1.0 [INFO] [INFO] [INFO] --- maven-release-plugin:2.2.2:prepare (default-cli) @ sonargraph-plugin --- [INFO] Resuming release from phase 'scm-tag' [INFO] Tagging release with the label sonargraph-plugin-1.0... [INFO] Executing: /bin/sh -c cd /home/esteban/Workspaces/Jenkins-Sonargraph-plugin/sonargraph-plugin git tag -F /tmp/maven-scm-1942063480.commit sonargraph-plugin-1.0 [INFO] Working directory: /home/esteban/Workspaces/Jenkins-Sonargraph-plugin/sonargraph-plugin [INFO] Executing: /bin/sh -c cd /home/esteban/Workspaces/Jenkins-Sonargraph-plugin/sonargraph-plugin git push ssh://esteban_h2m:conga01...@github.com/jenkinsci/sonargraph-plugin.git sonargraph-plugin-1.0 [INFO] Working directory: /home/esteban/Workspaces/Jenkins-Sonargraph-plugin/sonargraph-plugin [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 5.084s [INFO] Finished at: Mon May 06 12:16:04 COT 2013 [INFO] Final Memory: 11M/146M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.2.2:prepare (default-cli) on project sonargraph-plugin: Unable to tag SCM [ERROR] Provider message: [ERROR] The git-push command failed. [ERROR] Command output: [ERROR] Permission denied (publickey). [ERROR] fatal: The remote end hung up unexpectedly [ERROR] - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException -- Esteban Angee Agudelo Software Engineer hello2morrow S.A.S (574)5804555 esteban.an...@hello2morrow.com http://www.hello2morrow.com -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
AsyncAperiodicWork and getRecurrencePeriod
I've got a subclass of AsyncAperiodicWork firing off a task periodically, at an interval that can be updated and configured by the user in the config. When the user updates the config, I am immediately scheduling a new run of the task by instantiating a new instance and calling doAperiodicRun() on it. However, when I do that, the next scheduled run doesn't happen until the previously configured recurrenceInterval has gone by (and the new interval doesn't take effect until that happens, too). For example: at startup, recurrence of 10 minutes. at 1 minute, reconfigure for recurrence of 1 minute call doAperiodicRun() Next occurrence of the task doesn't come until t=10minutes Then every minute afterward the task fires I tried a possible workaround, which was to grab the instance created in getNewInstance() and store it in a class variable, and call doAperiodicRun() on that when attempting to reschedule, but it didn't change the behavior (and feels pretty dangerous, anyway). Is there something I'm supposed to be doing to force a reschedule of the pending runs, or is this a bug? -- Marc MacIntyre -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: AsyncAperiodicWork and getRecurrencePeriod
I think you're on the right track. I think that you do need to save off the new instance in getNewInstance(), so that when the user reconfigures, you can call cancel() on it to cancel the pending run. Then, instead of calling doAperiodicRun(), call doRun() which is inherited from AperiodicWork. This calls doAperiodicRun() and then sets up the new schedule. You don't need to create the new instance yourself. -- Dean On Monday, May 6, 2013 10:36:51 AM UTC-7, Marc MacIntyre wrote: I've got a subclass of AsyncAperiodicWork firing off a task periodically, at an interval that can be updated and configured by the user in the config. When the user updates the config, I am immediately scheduling a new run of the task by instantiating a new instance and calling doAperiodicRun() on it. However, when I do that, the next scheduled run doesn't happen until the previously configured recurrenceInterval has gone by (and the new interval doesn't take effect until that happens, too). For example: at startup, recurrence of 10 minutes. at 1 minute, reconfigure for recurrence of 1 minute call doAperiodicRun() Next occurrence of the task doesn't come until t=10minutes Then every minute afterward the task fires I tried a possible workaround, which was to grab the instance created in getNewInstance() and store it in a class variable, and call doAperiodicRun() on that when attempting to reschedule, but it didn't change the behavior (and feels pretty dangerous, anyway). Is there something I'm supposed to be doing to force a reschedule of the pending runs, or is this a bug? -- Marc MacIntyre -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: AsyncAperiodicWork and getRecurrencePeriod
Ok, thanks; I'll give that a shot. I still need to create the new instance myself, though, don't I? So I have something to call doRun() on? On Mon, May 6, 2013 at 1:14 PM, Dean Yu dean...@gmail.com wrote: I think you're on the right track. I think that you do need to save off the new instance in getNewInstance(), so that when the user reconfigures, you can call cancel() on it to cancel the pending run. Then, instead of calling doAperiodicRun(), call doRun() which is inherited from AperiodicWork. This calls doAperiodicRun() and then sets up the new schedule. You don't need to create the new instance yourself. -- Dean On Monday, May 6, 2013 10:36:51 AM UTC-7, Marc MacIntyre wrote: I've got a subclass of AsyncAperiodicWork firing off a task periodically, at an interval that can be updated and configured by the user in the config. When the user updates the config, I am immediately scheduling a new run of the task by instantiating a new instance and calling doAperiodicRun() on it. However, when I do that, the next scheduled run doesn't happen until the previously configured recurrenceInterval has gone by (and the new interval doesn't take effect until that happens, too). For example: at startup, recurrence of 10 minutes. at 1 minute, reconfigure for recurrence of 1 minute call doAperiodicRun() Next occurrence of the task doesn't come until t=10minutes Then every minute afterward the task fires I tried a possible workaround, which was to grab the instance created in getNewInstance() and store it in a class variable, and call doAperiodicRun() on that when attempting to reschedule, but it didn't change the behavior (and feels pretty dangerous, anyway). Is there something I'm supposed to be doing to force a reschedule of the pending runs, or is this a bug? -- Marc MacIntyre -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Marc MacIntyre -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: AsyncAperiodicWork and getRecurrencePeriod
Dean, that worked like a charm; thanks again. On Mon, May 6, 2013 at 1:14 PM, Dean Yu dean...@gmail.com wrote: I think you're on the right track. I think that you do need to save off the new instance in getNewInstance(), so that when the user reconfigures, you can call cancel() on it to cancel the pending run. Then, instead of calling doAperiodicRun(), call doRun() which is inherited from AperiodicWork. This calls doAperiodicRun() and then sets up the new schedule. You don't need to create the new instance yourself. -- Dean On Monday, May 6, 2013 10:36:51 AM UTC-7, Marc MacIntyre wrote: I've got a subclass of AsyncAperiodicWork firing off a task periodically, at an interval that can be updated and configured by the user in the config. When the user updates the config, I am immediately scheduling a new run of the task by instantiating a new instance and calling doAperiodicRun() on it. However, when I do that, the next scheduled run doesn't happen until the previously configured recurrenceInterval has gone by (and the new interval doesn't take effect until that happens, too). For example: at startup, recurrence of 10 minutes. at 1 minute, reconfigure for recurrence of 1 minute call doAperiodicRun() Next occurrence of the task doesn't come until t=10minutes Then every minute afterward the task fires I tried a possible workaround, which was to grab the instance created in getNewInstance() and store it in a class variable, and call doAperiodicRun() on that when attempting to reschedule, but it didn't change the behavior (and feels pretty dangerous, anyway). Is there something I'm supposed to be doing to force a reschedule of the pending runs, or is this a bug? -- Marc MacIntyre -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Marc MacIntyre -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Request for project on BuildHive
Could you add this plugin to BuildHive please? https://github.com/jenkinsci/build-pipeline-plugin Thanks -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
