Re: Jenkins plugin release RSS-feed dead?
Ping... can some check why https://ci.jenkins-ci.org/job/infa_release.rss/ is failing since Aug. 1 ? Am Donnerstag, 8. August 2013 14:03:54 UTC+2 schrieb Björn Pedersen: I checked the jenkins-ci page: The infa_release.rss jobs is failing with a NPE since Aug. 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.
Quick query re publishers
Hopefully a quick question - from a publisher's perform method, can you get access to the job that the build relates to? Thanks Richard. -- 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: Quick query re publishers
build.getProject() Robert Sandell Software Tools Engineer - SW Environment and Product Configuration Sony Mobile Communications From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-dev@googlegroups.com] On Behalf Of Richard Bywater Sent: den 12 augusti 2013 10:55 To: jenkinsci-dev@googlegroups.com Subject: Quick query re publishers Hopefully a quick question - from a publisher's perform method, can you get access to the job that the build relates to? Thanks Richard. -- 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.commailto: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.
ssh-agent, git publisher and build wrappers workflow
Hi, folks! Recently SSH-Agent was updated to run before SCM scheckout and therefore became usable for the sake of git authentication. However, there still is an issue with Git publisher. Due to general BuildWrappers' workflow in Free-style builds, BuildWrapper-produced Environment objects have their tearDown method called right after all the Builders finish for project (and before any Recorders/Notifiers are run). This makes impossible to use SSH-Agent for the sake of Git publisher (i.e. pushing changed branches to the master repository). I've managed to create an ugly workaround (Recorder wrapper that runs BuildWrappers once again for a given recorder), but it does not look like a proper solution to me. Looks like the proper fix is to allow BuildWrapper effect extend upon the Publishers too, but it requires fix in the Jenkins core. Are there any other options? Maybe, there is already a plugin to solve this trouble? Thanks in advance! Best regards, Ivan Kalinin. -- 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.
Jenkow plugin: error importing with EGit
Hello Max, great work with Jenkow, indeed! I followed easily all your tutorial steps, but had some problem with the following *Jenkow v0.2 Setup: 4. import workflow project* - http://youtu.be/M_TuXAHPl5Q here I get a problem when Importing a workflow into Eclipse. In fact after copying the administrator git repo URI (e.g. ssh://localhost:51565/jenkow-repository.git) into the Dialog and answering Yes to the SSH Acknowlegment popup I get this error: Read time out after 30.000 ms Please check Network Connection settings - SSH2 Eclipse preferences I use EGit regularly, so I have Eclipse preferences setup with my keys, but I don't understand what should I set in this case. Should I put my pub key into some Jenkins folder and/or configuration? Thank you very much Vincenzo -- 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: New Feature: Realtime test results for JUnit
Thanks for the feedback. I guess we agreed that it would be an interesting feature for core provided we can implement it in a reasonably efficient way. @kpfleming: We can do better than re-runing JUnitResultArchiver. I have modified the parser to update result object incrementally in order _not_ to parse the same report files over and over again. My draft invokes parsing JIT (but it is blocking the UI thread which probably could be eliminated using ajax) so there is no parsing as long as no one wants to see the results. Possible improvement we might be interested in is spinning a thread on slave to monitor new report files and push updates to master when there is something new (no polling on master, no polling over network). I did not find a way to eliminate polling altogether preserving all the flexibility JUnitResultArchiver provides, though. Testing on remote slave is actually faster than I expected. Refreshing test results takes ~5 seconds when building jenkins. @Roman: This filesystem based approach will cover your use case as well. Here is what I have: https://github.com/jenkinsci/jenkins/pull/904 -- 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: Backporting for 1.509.3 started
I assume we do not want to wait two weeks with 1.509.3 until stapler 1.217 became soaked. Besides, using stapler 1.217 in Jenkins seems to introduce new regression [1]. It seems that JENKINS-18776 is the only thing to revert it we want to stay on 1.207. So I vote for pushing it to 1.509.4 that would use new fixed stapler so we can backport JENKINS-18776 and JENKINS-14362. [1] https://github.com/jenkinsci/jenkins/commit/7e8bbea3336dc65a10c2fd69a20beac20bc6fca3#commitcomment-3835893 -- 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: Backporting for 1.509.3 started
On Mon, Aug 12, 2013 at 8:06 AM, ogondza ogon...@gmail.com wrote: It seems that JENKINS-18776 is the only thing to revert it we want to stay on 1.207. So I vote for pushing it to 1.509.4 that would use new fixed stapler so we can backport JENKINS-18776 and JENKINS-14362. I agree this seems like the safest route for 1.509.3; there are other important fixes we want to deliver. Does anyone know what the practical impact of JENKINS-18776 is? I.e. what plugins or features are broken by it? Sounds like this would only affect form validation. -- 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: New Feature: Realtime test results for JUnit
On Mon, Aug 12, 2013 at 6:58 AM, ogondza ogon...@gmail.com wrote: it would be an interesting feature for core Definitely it would, though for something this complex I cannot help but ask if we should not first make a real effort to split JUnit reporting out of core into a proper plugin. spinning a thread on slave to monitor new report files Or use java.nio.file.WatchService when available. Most practical when the report wildcard contains just a single wildcard in the final path segment, i.e. ‘some-dir/TEST-*.xml’ can be easily monitored by watching some-dir; in the general case (e.g. ‘**/TEST-*.xml’) you might need to watch the whole workspace, which is inefficient using the current API. -- 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.
Validated merge for Jenkins core
I have set up an experimental installation of CloudBees validated merge [1] on jenkins.ci.cloudbees.com for Jenkins core [2]. This lets you have Jenkins test your commit(s) before pushing them upstream. If you are a Jenkins committer and would like to try this service, please let me know (off list) what your user ID on this server is (typically an email address), and I can add you to a security group in order to be allowed to push here. If you are not a Jenkins committer, or are but prefer to use pull requests to get feedback, then this service is irrelevant since PRs are already validated. The point is being able to offload testing to CI for commits not associated with any PR. Validated merge also supports commit --amend, so if your commit causes a minor test failure you can just patch it up and try again. (Since we do not yet have SSH service into DEV@cloud, and I could not figure out command-line Git’s HTTP authentication, for now this uses a secret push URL per user. Keep your .git/config secure if you used git remote add.) [1] http://jenkins-enterprise.cloudbees.com/docs/user-guide-bundle/validated-merge.html [2] https://jenkins.ci.cloudbees.com/job/core/job/jenkins_main_trunk/repo.git/ -- 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: New Feature: Realtime test results for JUnit
On 08/12/2013 02:58 PM, ogondza wrote: Thanks for the feedback. I guess we agreed that it would be an interesting feature for core provided we can implement it in a reasonably efficient way. @kpfleming: We can do better than re-runing JUnitResultArchiver. I have modified the parser to update result object incrementally in order _not_ to parse the same report files over and over again. My draft invokes parsing JIT (but it is blocking the UI thread which probably could be eliminated using ajax) so there is no parsing as long as no one wants to see the results. Possible improvement we might be interested in is spinning a thread on slave to monitor new report files and push updates to master when there is something new (no polling on master, no polling over network). I did not find a way to eliminate polling altogether preserving all the flexibility JUnitResultArchiver provides, though. Testing on remote slave is actually faster than I expected. Refreshing test results takes ~5 seconds when building jenkins. @Roman: This filesystem based approach will cover your use case as well. It will be great. Could I help in achieving this? Thanks, Roman Here is what I have: https://github.com/jenkinsci/jenkins/pull/904 -- 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.
Jenkins Job uniquie ID?
Does Jenkins associate a unique ID with jobs? If so, how can i access this value? I'm trying to keep track of some basic information in an external DB, and this would help keep things in order (especially since jobs names can change). Thanks, Eric -- 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: Jenkins Job uniquie ID?
On Mon, Aug 12, 2013 at 1:44 PM, Eric Lordahl elord...@vt.edu wrote: Does Jenkins associate a unique ID with jobs? There is Item.fullName. A job can be renamed however. There is no other unique identifier. -- 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: Redmine Plugin - very restricted github repo - forbidden to merge PR
I've cloned repo from url g...@github.com:jenkinsci/redmine-plugin.git, merged into just cloned repo my remote repo (ljader/redmine-plugin) and tried to git push origin master with message: ERROR: Permission to jenkinsci/redmine-plugin.git denied to ljader. fatal: Could not read from remote repository. W dniu poniedziałek, 12 sierpnia 2013 22:45:02 UTC+2 użytkownik Baptiste Mathus napisał: Hi, Did you just try merging using the web UI? If so, then maybe try doing it with pure git. Merging locally and pushing should close the corresponding PR. My 2 cents. Le 12 août 2013 19:54, Łukasz Jąder ljad...@gmail.com javascript: a écrit : Hi, I've received jenkins commit access but I'm forbidden to merge PRs in https://github.com/jenkinsci/redmine-plugin . I can merge other people PRs in other repos that I checked. I've recieved confirmation that this repo is somehow restricted https://groups.google.com/forum/?fromgroups=#!topic/jenkinsci-dev/nRZRNAaqcPY. Because I can't merge I assume that also tagging and releasing new version of plugin would fail. Please verify this repo settings and provide some feedback. It's quite frustrating to be unable to push forward in development of this plugin. Thanks in advance. -- 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-de...@googlegroups.com javascript:. 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.
Custom JellyTagLibrary
Hi fellow Jenkins Devs :)
I'd like to create a custom Jelly tag (Java, not a *.jelly template) and
persuade Stapler to load it from my Jenkins plugin.
According to various bits and pieces of conversations I found around the
Internet:
http://mail-archives.apache.org/mod_mbox/commons-user/200411.mbox/%3c826ffd876f610049bf04d94cdf9ed133c3d...@yvain.ms.dsi.cnrs.fr%3E
https://java.net/projects/hudson/lists/dev/archive/2010-09/message/255
I understand that it is possible, and that I should do the following:
- in my plugin package (assume com.myplugin for the sake of simplicity)
create the CustomTag.java (com.myplugin.CustomTag), that extends any
public tag from org.kohsuke.stapler.jelly.* (since the AbstractStaplerTagis
not available outside of the org.kohsuke.stapler.jelly package) -
* it might not be necesary to extend any other tag, or is it?*
- in the same package create the TagLibrary class, say
MyCustomTagLibrary.java, extending org.apache.commons.jelly.TagLibrary,
where I register my CustomTag class:
public class CustomTagLibrary extends TagLibrary {
public CustomTagLibrary() {
registerTag(custom, CustomTag.class);
}
}
- in the same package create an empty taglib file *I'm not sure if
that's at all required?*
- in my plugin's main.jelly, where I'd like to use the custom tag,
register the custom taglib by specifying:
j:jelly ...
xmlns:mc=jelly:com.myplugin.MyCustomTagLibrary
The code compiles and runs fine, but the custom tag code: mc:custom ... is
not evaluated.
What I managed to find out so far, is that Stapler's
CustomJellyContext::getTagLibrary
only allows me to retrieve those TagLibraries that have been previously
explicitly registered.
So I guess my question is: *How can I register a custom JellyTagLibrary
from within the plugin?*
I don't seem to be able to get hold of the CustomJellyContext class, which
has the registerTagLibrary method on it? Please tell me I'm completely
wrong, missing something obvious and there's a nice and simple way of
achieving this goal :)
Any suggestions would be greatly appreciated!
--
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.
