Create extension based on plugin logic
Hi, I would like to create an automated process for adding users and roles to Jenkins. However, the user management is done by the Role-Strategy Plugin ( https://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Plugin). My question is: How can I create a new plugin which depends on the source of an exisiting plugin? I don't want to change the Role-Strategy Plugin, in order to be able receive further updates. Best Regards
Help releasing plugin
I've unsuccessfully tried to release our plugin. The release:prepare release:perform, seemed to go well, but I can't see the update in either of the sites mentioned or the jsonhttps://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins . The output of the release says it was uploaded to: http://maven.jenkins-ci.org:8081/content/repositories/releases/com/blazemeter/plugins/BlazeMeterJenkinsPlugin/ And I can see it there. Will it move from there to the download center? If you need to see the output of the command, just tell me. 10x in advance, Doron.
Build Step wrapper
Hello guys, As far as I know there is no Build-Step Wrapper/Decorator in jenkins-core,I tried (a couple month ago) to study this point but i requires some core-updates. I've got some use cases which can take advantage of this extension point. In a Job configuration we can't add some details about build steps. The idea is to include some debug/info information but at the build step level. These information could be displayed (or not) in the console output. First of all, it would improve the maintenance of a job configuration (just as comments do in a source code), then displayed in log file it offers a more functional (high-level) point of view of the job's process. I like Ant behavior which build anchors to navigate to the console output but unfortunately we can't navigate easily from build step to build step. A wrapper could build these anchors for every build steps (based on the Console annotator mechanism). This plugin is very close to the concept. https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin It's a build step, wrapping and triggering nested build steps. Is it the official approach or a smart solution? What's your thoughts on this?
Re: Maven JVM terminated unexpectedly with exit code 134
Hello once again, Should I report bug about that? Br, Alexander On 10 September 2012 12:02, Alexander Potapov outro...@gmail.com wrote: Hello, Haven't seen this problem when I had one build process. Thus, we cannot take into account the case of one Maven process for sure. In my setup I increased the number of build executors. By default it is 2, I have 5. All jobs in my Jenkins are interconnected, they have Maven dependencies specified what is not uncommon. I believe it is something to do with Jenkins. It gives possibility to have multiple build processes at the same time on the same machine. And it fails to perform that. Br, Alexander. On 7 September 2012 18:40, Jesse Glick jgl...@cloudbees.com wrote: On 09/07/2012 08:15 AM, Alexander Potapov wrote: SIGBUS (0x7) at pc=0x7ffae80661b0, pid=26833, tid=140715262596864 J java.util.zip.ZipFile.**getEntry(JLjava/lang/String;Z)**J J java.util.zip.ZipFile.**getEntry(Ljava/lang/String;)** Ljava/util/zip/ZipEntry; j org.eclipse.jdt.internal.**compiler.classfmt.** ClassFileReader.read(Ljava/**util/zip/ZipFile;Ljava/lang/** String;Z)Lorg/eclipse/jdt/**internal/compiler/classfmt/** ClassFileReader;+2 This Java code (in JDT) is trying to read classes from a JAR file which has been, or is being, overwritten (probably by the same Maven process) with a newer version since the JAR was opened. Oracle-derived JVMs use libzip.so/dll (rather than pure Java code) to implement ZipFile, and this library was not designed to handle ZIP files being replaced “under its feet”. I have repeatedly advocated that ZipFile use a more robust pure Java implementation (leaving libzip for use only by HotSpot loading the bootclasspath, which is expected to be immutable), but no one in the Java team seems to consider this a priority, so do not expect it to be fixed unless someone pushes it from OpenJDK. In the meantime the workarounds, insofar as you can control the code immediately involved in the bug, are: 1. Prevent the JAR from being overwritten. 2. Rather than reading the JAR “in-place”, make a temporary copy (File.createTempFile/**deleteOnExit) and open that instead. Note that this bug does not occur on Windows—mandatory file locking means that if the ZipFile is open for reading, any attempt to overwrite (or delete) it will fail with an IOException or the like.
Re: Help releasing plugin
10x for your reply. It seems that it took just about a day. https://wiki.jenkins-ci.org/display/JENKINS/BlazeMeter+Plugin May I ask for a bit more direction? How do I make the wiki show the link to the .hpi itself so that people won't have to compile the code for themselves? Do I have to link to it directly, or can I somehow add it to the template of the plugin info? I see no other reason to release the plugin. I can just commit to github, and the most up to date version will be there. Can someone elaborate? Thanks again, Doron. On Monday, September 24, 2012 3:52:30 PM UTC+2, Robert Sandell wrote: It takes a day or so for the update center backend to scan through the repository and update itself. But it also only checks a specific set of namespaces; like org/jenkins-ci/plugins and some others.Probably an admin needs to add “com/blazemeter” to the list of groups to scan. * * *Robert Sandell* Software Tools Engineer - Tools and Integration Sony Mobile Communications *From:* jenkin...@googlegroups.com javascript: [mailto: jenkin...@googlegroups.com javascript:] *On Behalf Of *Doron Bloch *Sent:* den 24 september 2012 09:34 *To:* jenkin...@googlegroups.com javascript: *Subject:* Help releasing plugin I've unsuccessfully tried to release our plugin. The release:prepare release:perform, seemed to go well, but I can't see the update in either of the sites mentioned or the jsonhttps://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins . The output of the release says it was uploaded to: http://maven.jenkins-ci.org:8081/content/repositories/releases/com/blazemeter/plugins/BlazeMeterJenkinsPlugin/ And I can see it there. Will it move from there to the download center? If you need to see the output of the command, just tell me. 10x in advance, Doron.
Re: Plugin Information on Wiki shows wrong SCM
Kohsuke pointed out the root cause of my problem: Jenkow is a multi-module Maven project. The plugin project is just a sub-module. Only the main POM had the correct SCM element, but not the plugin sub-module. After adding the correct SCM element to the plugin sub-module, the Wiki macro shows the correct information. -Max On 09/12/2012 10:49 AM, Max Spring wrote: For my plugin, the Wiki page shows the wrong SCM. https://wiki.jenkins-ci.org/display/JENKINS/Jenkow+Plugin The source is on Github and the POM clearly says git: https://github.com/jenkinsci/jenkow-plugin/blob/master/pom.xml#L70 But the Plugin Information is shown as Subversion. How can I fix this? Thanks! -Max
Re: Checkbox to allow the Custom Workspace be shared among different slaves.
The @N notation I was referring to was just the style of path you cited in your first scenario: job1 - /Nodes/path/job job2 - /Nodes/path/job@2 job3 - /Nodes/path/job@3 The @2 and @3 were added by Jenkins because you configured concurrent builds. I think you're actually describing two features: 1. Make sure that jobs with custom workspaces work correctly when configured to run concurrent builds. This is what I thought you were after, and so I felt that this should just work, without requiring additional user configuration. 2. Allow the workspace a job uses to be passed as a parameter from one job to the next. -- Dean From: Marek Gimza marekgi...@gmail.commailto:marekgi...@gmail.com Reply-To: jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com Date: Saturday, September 22, 2012 8:01 AM To: jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com Subject: Re: Checkbox to allow the Custom Workspace be shared among different slaves. Thanks Dean, I sincerely appreciate the reply. I am not sure what you mean by @N notation. Maybe this will help me improve my build-environment. (I will google it ) I like to have this behaviour to be configurable by the user. The reason is that I have a main (parent) project that has this checkbox set, but its downstream (child) projects do not. The parent job sets the workspace for the build, gets the src from the SCM, and passes it on to the other jobs to compile, test,etc The child downstream projects just get the workspace directory as a parameter and perform their task(i.e. compile,test). I have a set of jobs where each one only performs a specific task on a given workspace (i.e.compile,test,etc...). Each one does not care about the SCM nor any other project details. It just gets a workspace dir to perform+report its work and away it goes. The beauty of this is that All of these downstream jobs are concurrently running across 10 build and test machines. Each one acting on a workspace. In some cases I am compiling build-targets on the same workspace dir at the same time from different machines. The compile targets do not conflict with each other, and I save a lot of time. I also re-use these donwstream jobs for different SCM branches. Using the MultiJob plugin allows the main (parent) upstream project to know when all of its requested compiles and testing has finished. I hope that this makes sense. Thanks, Marek Gimza On Fri, Sep 21, 2012 at 4:31 PM, Dean Yu d...@shutterfly.commailto:d...@shutterfly.com wrote: To summarize, the problem that you have is that when your project is configured with both a custom workspace and to perform concurrent builds, the same path is used by all the builds, causing them to step on each other. Is that correct? If this is the case, is there ever a case where you don't want to use the @N notation in this situation? In other words, why not just make this always be the behavior instead of having to require the user to configure it? -- Dean From: mgimza marekgi...@gmail.commailto:marekgi...@gmail.com Reply-To: jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com Date: Thursday, September 20, 2012 2:28 PM To: jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com Subject: Checkbox to allow the Custom Workspace be shared among different slaves. I would like to share a change I have made to the jenkins-core that introduces a new checkbox called customWorkspaceRoot to a job configuration. Please find attached a GIF file showing the CustomWorkspace path and checkbox setting in a job's configuration page. Objective To let Jenkins use the CustomWorkspace path (set in a Job's configuration page) in the same manner as the Remote FS root path that is set in the Node's configuration page. Normally the customWorkspace is static, in the sense that Jenkins does not alter the workspace path for different concurrently running instances of the same job. The intent of this code-change is to be able to allow Jenkins to run the same job multiple times, where the CustomWorkspace path is used to create a unique workspace path for each concurrently running instance of the same Job. For example: --- Scenario 1. Normally when the customWorkspace is NOT set, the selected Node's Remote FS root path is used for each concurrently running instance of the job: job1 - /Nodes/path/job job2 - /Nodes/path/job@2 job3 - /Nodes/path/job@3 etc... Scenario 2. Normally when the customWorkspace is set, the 'same' customWorkspace path is used for each concurrently running instance of the job: job1 - /Nodes/path/job job2 - /Nodes/path/job job3 -
Re: Maven Projects with dependencies is too eager since 1.481
+1 2012/9/24 Arnaud Héritier aherit...@gmail.com: Hi, +1000 with Larry I also noticed this issue triggering many many useless builds between projects. I was also suspecting this change as the root cause of the issue. Is there already an issue opened about this regression ? I'm in favor to revert JENKINS-12735 if someone don't find a fix quickly Cheers, Arnaud On Wed, Sep 19, 2012 at 5:04 PM, Larry Shatzer, Jr. lar...@gmail.com wrote: I've noticed something weird with Maven projects that are set to build downstream jobs if there is a SNAPSHOT dependency. It now lists jobs as dependencies (and builds them) even if it is not a SNAPSHOT dependency but a regular dependency. It looks like the code for JENKINS-12735 to allow version ranges is causing this. If you use version of version1.0.0/version, that should not trigger it, but the other uses like [1.0.0,2.0.0), etc. should. This is causing lots of extra unnecessary builds when you have a lot of projects that are dependent on each other, but set to a release of the other and not a SNAPSHOT. -- Larry -- - Arnaud Héritier 06-89-76-64-24 http://aheritier.net Mail/GTalk: aherit...@gmail.com Twitter/Skype : aheritier -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy
Diskspace Notification for Jenkins
Hi Guys, Just sharing a temporary solution for Diskspace Notifcation for Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-15278 Thanks.
Archetypal plugins examples
I'm working on my slides for JUC SF, Getting to your third plugin, and in the talk I'd like to highlight some ideal plugins to fork or just to look at in general. *What would people consider ideal modern plugins?* For example while the FindBugs plugins is great, but it leans really heavily on Analysis Collector Plugin which makes it a bad example to exemplify writing a plugin. Another example is that I don't want to point some to a plugin which extends Plugin or doesn't use DataBoundConstructor. While associated-files-plugin has a nice simple layout that appears to do everything in a moden way, so it makes a good archetype. I'd like some more for the other major @Extension points. -justin
