[JIRA] (JENKINS-14521) Configuration Slicing should temporarily disable the Auto Refresh plugin
OHTAKE Tomohiro commented on JENKINS-14521 Configuration Slicing should temporarily disable the Auto Refresh plugin I guess he would like configurationslicing to add norefresh="true" attribute to . If my guess is right, I would like too. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14495) Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder
Stephan Grimm commented on JENKINS-14495 Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder It works after downgrading to Jenkins 1.471 and Parameterized Trigger Plugin 2.14. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14525) 'fixed' trigger does not fire when there are no scm changes
Mark S. created JENKINS-14525 'fixed' trigger does not fire when there are no scm changes Issue Type: Bug Affects Versions: current Assignee: Slide-O-Mix Components: email-ext Created: 23/Jul/12 8:03 AM Description: I have a job that repeatedly builds on jenkins. When there are sporadic failures, I get the failure triggered emails, but the fixed trigger does not fire when the build goes ok the next time. However, the tooltip on the job config page says "An email will be sent when the build status changes from "Failure" or "Unstable" to "Successful"". Project: Jenkins Priority: Minor Reporter: Mark S. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14474) Multi-configuration jobs disappear from the list when Jenkins configuration is reloaded from disk
Ronen Peleg commented on JENKINS-14474 Multi-configuration jobs disappear from the list when Jenkins configuration is reloaded from disk As I wrote to you, I had the same issues like yours and I downgraded to 1.472, only then everything back to normal (I was able to see "multi-configuration" jobs. I recommended to you to actually copy the jenkins.war (1.472) and not to use the Jenkins downgrade option. This is what I did: 1. Stop Jenkins service. 2. Copy (from backup) the jenkins.war (1.472) to Jenkins home folder (c:\Jenkins). 3. Start Jenkins service. After you downgrade to 1.472, try to create a new "multi-configuration" job and see (after restart Jenkins) if the job staying stable. if its working, try to copy the config.xml from your old "multi-configuration" job to the new "multi-configuration" job. In any case, this bug must be solved ASAP! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14474) Multi-configuration jobs disappear from the list when Jenkins configuration is reloaded from disk
Sarah Woodall commented on JENKINS-14474 Multi-configuration jobs disappear from the list when Jenkins configuration is reloaded from disk Yes. That's exactly what I did. And, indeed, I can create new multi-config jobs and they do stay stable, so I can use this version. But I still have the other problem I mentioned: my old multi-config jobs that I created on my old system (Jenkins 1.441) and copied over to the new machine won't load. Jenkins gives a null-pointer exception when it tries to load them. So there is a separate bug to do with loading these old jobs. I should raise a separate bug report for that one, but at the moment I haven't done so, because the two issues seem to be so closely related. I thought it was better to wait and see what happens with this report first. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14461) Warnings plugin not Java 1.5 compatible?
SCM/JIRA link daemon commented on JENKINS-14461 Warnings plugin not Java 1.5 compatible? Code changed in jenkins User: Ulli Hafner Path: pom.xml src/main/java/hudson/plugins/warnings/parser/JSLintParser.java src/main/java/hudson/plugins/warnings/parser/fxcop/FxCopParser.java http://jenkins-ci.org/commit/warnings-plugin/6958bb7bc216075b0d82c806ad11ba99a87cb4fd Log: [FIXED JENKINS-14461] Removed references to JDK6 exception constructor. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14461) Warnings plugin not Java 1.5 compatible?
SCM/JIRA link daemon resolved JENKINS-14461 as Fixed Warnings plugin not Java 1.5 compatible? Change By: SCM/JIRA link daemon (23/Jul/12 8:33 AM) Status: In Progress Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14526) NPE in greenballs
robsimon created JENKINS-14526 NPE in greenballs Issue Type: Bug Affects Versions: current Assignee: asgeirn Components: greenballs Created: 23/Jul/12 8:38 AM Description: all UI images disappear. login impossible! WARNUNG: Untrapped Error in Servlet java.lang.NullPointerException at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:50) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) 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 org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) 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 org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) 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:66) 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 winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at winstone.RequestDispatcher.forward(RequestDispatcher.java:331) at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Environment
[JIRA] (JENKINS-14057) Active Directory Plugin doesn't work anymore (user/group identification in authorization strategy fails)
schtefan commented on JENKINS-14057 Active Directory Plugin doesn't work anymore (user/group identification in authorization strategy fails) I am also wondering why the class ActiveDirectoryUnixAuthenticationProvider is invoked although we are running on a Windows system. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14057) Active Directory Plugin doesn't work anymore (user/group identification in authorization strategy fails)
schtefan assigned JENKINS-14057 to Kohsuke Kawaguchi Active Directory Plugin doesn't work anymore (user/group identification in authorization strategy fails) I am asking who to assign issues related to the Active Directory plugin as the automatic assignment is Unassigned Change By: schtefan (23/Jul/12 8:50 AM) Assignee: Kohsuke Kawaguchi This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14474) Multi-configuration jobs disappear from the list when Jenkins configuration is reloaded from disk
Ronen Peleg commented on JENKINS-14474 Multi-configuration jobs disappear from the list when Jenkins configuration is reloaded from disk Maybe your old jobs requests for plugins that not including in your new Jenkins system. Check and make sure that you have the same system settings and plugins like in you had in the old Jenkins system. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14474) Multi-configuration jobs disappear from the list when Jenkins configuration is reloaded from disk
Ronen Peleg edited a comment on JENKINS-14474 Multi-configuration jobs disappear from the list when Jenkins configuration is reloaded from disk Maybe your old multi-config jobs requests for plugins that not including (exist) in your NEW Jenkins system. Check and make sure that you have the same system settings and plugins like in you had in the old Jenkins system. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13915) NPE Exception, possibly caused by disabled jobs?
Ben Golding
commented on JENKINS-13915
NPE Exception, possibly caused by disabled jobs?
I could reproduce this issue again today. In this case the assigned node for *_de02winterm20 jobs was disconnected (JNLP slave was not running). Notice from the log below, two *_de02winterm20 jobs are triggered but do not complete:
===
parallel {
Trigger job rsync_binmod_de02winterm31
Trigger job rsync_binmod_stormcs241
Trigger job downmerge_f2011.06
Trigger job rsync_SDR_de02winterm31
Trigger job rsync_SDR_stormcs240
Trigger job rsync_SDR_stormcs241
Trigger job rsync_binmod_de02winterm20
Trigger job checkbinmod
Trigger job rsync_binmod_stormcs240
Trigger job downmerge_main
Trigger job rsync_SDR_de02winterm20
Trigger job downmerge_g2012.06
Trigger job removebinmod
checkbinmod #68 completed
downmerge_main #143 completed
downmerge_f2011.06 #124 completed
rsync_binmod_stormcs240 #47 completed
removebinmod #66 completed
rsync_binmod_stormcs241 #350 completed
rsync_binmod_de02winterm31 #40 completed
rsync_SDR_de02winterm31 #39 completed
rsync_SDR_stormcs240 #42 completed
rsync_SDR_stormcs241 #122 completed
downmerge_g2012.06 #93 completed
FATAL: null
java.lang.NullPointerException
at org.codehaus.groovy.runtime.callsite.GetEffectivePojoPropertySite.acceptGetProperty(GetEffectivePojoPropertySite.java:51)
[... see attached console.log for full backtrace ...]
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14096) XPath is not working with Jaxen provided by Jenkins
Matthias Vach commented on JENKINS-14096 XPath is not working with Jaxen provided by Jenkins Hi, are there plans to fix that issue? Regard Matthias This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14509) PMD Plugin reporting existing warnings as new
David Resnick commented on JENKINS-14509 PMD Plugin reporting existing warnings as new The contextHashCode values do seem to be almost contiguous – they all seem to be between 7000-9000. Not as I'd expect hash values to be. Yes, the fileName element in the pmd-warnings.xml file holds the correct filename for the most recent job run. Note that the job may run in different locations depending on the Jenkins slave that was used. How is the filename used? They are the full, not relative path to the file in the job workspace. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14509) PMD Plugin reporting existing warnings as new
David Resnick edited a comment on JENKINS-14509 PMD Plugin reporting existing warnings as new The contextHashCode values do seem to be almost contiguous – in a recent run they all seem to be between 7000-9000. Not as I'd expect hash values to be. Yes, the fileName element in the pmd-warnings.xml file holds the correct filename for the most recent job run. Note that the job may run in different locations depending on the Jenkins slave that was used. How is the filename used? They are the full, not relative path to the file in the job workspace. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13515) Copy failed on windows machine because of timestamp
Markus Unterauer edited a comment on JENKINS-13515 Copy failed on windows machine because of timestamp In jenkins v1.474 this problem is still there This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14514) Repeatable jelly tag appears to be broken in 1.474+
bap updated JENKINS-14514 Repeatable jelly tag appears to be broken in 1.474+ Change By: bap (23/Jul/12 11:13 AM) Summary: Publish Over SSH( Repeatable jelly tag appears to be broken in 1. 7) can not work at Jenkins ver. 1. 474 + Assignee: Slide-O-Mix Component/s: core Component/s: gui Component/s: publish-over-cifs Component/s: publish-over-ftp Component/s: publish-over-ssh Component/s: adaptiveplugin This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14514) Repeatable jelly tag appears to be broken in 1.474+
bap assigned JENKINS-14514 to Kohsuke Kawaguchi Repeatable jelly tag appears to be broken in 1.474+ Change By: bap (23/Jul/12 11:17 AM) Assignee: Slide-O-Mix Kohsuke Kawaguchi This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14514) Repeatable jelly tag appears to be broken in 1.474+
bap commented on JENKINS-14514 Repeatable jelly tag appears to be broken in 1.474+ The repeatable blocks fail to display when using jenkins 1.474 onwards (possibly due to the modular js and the use of adjunct) https://github.com/jenkinsci/publish-over-ftp-plugin/blob/2bba237f3deaac9eb543f6312d038a711f7f2862/src/main/resources/jenkins/plugins/publish_over_ftp/BapFtpPublisherPlugin/config.jelly behaves correctly on 1.388 -> 1.473 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14528) Provide better feedback when downstream builds are not triggered due to circular dependencies
Michael Donaghy created JENKINS-14528 Provide better feedback when downstream builds are not triggered due to circular dependencies Issue Type: Improvement Assignee: Unassigned Components: core Created: 23/Jul/12 11:53 AM Description: I believe jenkins' build triggering logic was previously changed so as to not trigger downstream builds until all their dependencies have been built, with the side effect that if there is a circular dependency between two or more downstream builds, none of them will be triggered Unfortunately, there is no indication that this has occurred, and no obvious way to find out why the downstream builds are not running. To the frustrated user it simply appears as though build triggering is not working correctly (with a large number of maven projects, it can be easy to introduce a cyclic dependency without noticing) Please add some indication or at least logging in the console output as to why a downstream build has not been triggered, so that it's possible to see what has happened and fix the circular dependency. Project: Jenkins Priority: Major Reporter: Michael Donaghy This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10442) RestartNotSupportedException when trying to do safeRestart
evernat resolved JENKINS-10442 as Duplicate RestartNotSupportedException when trying to do safeRestart It seems to be a duplicate of JENKINS-10354, so closing as duplicate. Please reopen if not. Change By: evernat (23/Jul/12 12:00 PM) Status: Open Resolved Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14138) New git branch has empty changelist
tsondergaard updated JENKINS-14138 New git branch has empty changelist Patch to make git plugin compute changelog differently for jobs configured with a merge-target Change By: tsondergaard (23/Jul/12 12:19 PM) Attachment: git-plugin.diff This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13422) Release button column
wernight updated JENKINS-13422 Release button column Mock Change By: wernight (23/Jul/12 12:28 PM) Attachment: Release Button.png This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7810) Set the next build number of a downstream project with a post build action
peter_schuetze closed JENKINS-7810 as Fixed Set the next build number of a downstream project with a post build action Change By: peter_schuetze (23/Jul/12 1:14 PM) Status: Resolved Closed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14529) BindException whhen using --daemon with JMX
Georg Sash created JENKINS-14529 BindException whhen using --daemon with JMX Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 23/Jul/12 1:19 PM Description: java -Dcom.sun.management.jmxremote.port= -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -jar jenkins.war --deamon results in Forking into background to run as a daemon. Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: ; nested exception is: java.net.BindException: Address already in use This means I cannot use VisualVM on a deamonized Jenkins instance. I encountered this problem when using the RPM installer to setup Jenkins and afterwards manually adding the -D options to JENKINS_JAVA_OPTIONS in /etc/sysconfig/jenkins. Project: Jenkins Priority: Major Reporter: Georg Sash This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14529) BindException when using --daemon with JMX
Georg Sash updated JENKINS-14529 BindException when using --daemon with JMX Change By: Georg Sash (23/Jul/12 1:20 PM) Summary: BindException whhen when using --daemon with JMX This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14530) Allow to upgrade/downgrade to any plugin version
vjuranek created JENKINS-14530 Allow to upgrade/downgrade to any plugin version Issue Type: Improvement Assignee: Unassigned Components: core Created: 23/Jul/12 1:50 PM Description: Currently you can upgrade only to the latest available plugin version and downgrade to previously installed plugin. If would be nice if Jenkins allows to offer e.g. combo box where I can choose plugin version I want to upgrade. It's useful when e.g. I want to upgrade some plugin and it's known the in the latest version is some critical bug, which is not present in previous version. This is just for user convenience to can easily do this via Jenkins UI and not have to do it manually by replacing the plugin on the file system level. Project: Jenkins Priority: Major Reporter: vjuranek This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14329) SCM Sync Configuration plugin conflicts with Parameterized Trigger plugin. (stuck on waiting for the completion of OtherBuild)
peter_schuetze commented on JENKINS-14329 SCM Sync Configuration plugin conflicts with Parameterized Trigger plugin. (stuck on waiting for the completion of OtherBuild) I have Jenkins 1.461, Parametrized Trigger Plugin 2.13, and SCM Sync 0.0.4. I Do not experience this issue. In your A config I see the following line. false Looks like you should supply some parameters, but you actually don't. Don't know if that makes a difference. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-6124) git - optional control to disable fetching tags?
Douglas Beatty commented on JENKINS-6124 git - optional control to disable fetching tags? I would also like to add that this also makes the help text associated with the refspec in the job configuration false. Specifically, "When do you want to modify this value? A good example is when you want to just retrieve one branch. For example, +refs/heads/master:refs/remotes/origin/master would only retrieve the master branch and nothing else." This is not true. It would retrieve the master branch and every tag (and their associated objects) in the entire repository. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14531) CAS1 and 'Trigger builds remotely' incompatibility
João Antunes assigned JENKINS-14531 to João Antunes CAS1 and 'Trigger builds remotely' incompatibility Change By: João Antunes (23/Jul/12 2:38 PM) Assignee: João Antunes This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14531) CAS1 and 'Trigger builds remotely' incompatibility
João Antunes created JENKINS-14531 CAS1 and 'Trigger builds remotely' incompatibility Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: cas1 Created: 23/Jul/12 2:37 PM Description: Basicly, if one wants to have scripts that actually trigger the build remotely, it must perform a CAS1 authentication, if the CAS1 plugin is activated. Environment: Jenkins with CAS1 and Jobs with 'Trigger build remotely' Project: Jenkins Priority: Major Reporter: João Antunes This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14531) CAS1 and 'Trigger builds remotely' incompatibility
João Antunes started work on JENKINS-14531 CAS1 and 'Trigger builds remotely' incompatibility Change By: João Antunes (23/Jul/12 2:38 PM) Status: Open In Progress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14483) Remaining Xvfb processes in matrix jobs
Thorsten Kahler
commented on JENKINS-14483
Remaining Xvfb processes in matrix jobs
Hi Zoran,
I tried version 1.0.3-SNAPSHOT (private-07/21/2012 12:32-zregvart) on Jenkins 1.434 without success: Xvfb is still started on the matrix build too.
console output:
...
Ignoring Matrix build, waiting for Matrix jobs to follow
Xvfb starting$ /usr/bin/Xvfb :2 -screen 0 1024x768x24 -fbdir ${JENKINS_HOME}/2012-07-23_16-22-104384832168309393644xvfb
...
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14532) Wrong group name set when using dynamic permissions.
Tomasz Zieleniewski
created JENKINS-14532
Wrong group name set when using dynamic permissions.
Issue Type:
Bug
Affects Versions:
current
Assignee:
bertrandgressier
Attachments:
dynamicPermissions.png
Components:
createjobadvanced
Created:
23/Jul/12 2:53 PM
Description:
Using the same configuration as provided in the example in the help message:
Job name pattern: job.([A-Z]{3}).(.*)
Group format: perm.{0}.Developer
Job name: job.ABC.ProjectAJob
The final assigned group name is perm.job.ABC.ProjectAJob.Developer, where it should be perm.ABC.Developer.
The print screen attached.
Regards,
Tomasz
Environment:
Debian OS, 2.6.32-5-amd64
Jenkins ver. 1.475
Create Job Advanced ver. 1.6
Project:
Jenkins
Labels:
plugins
Priority:
Major
Reporter:
Tomasz Zieleniewski
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-5079) Release plugin is not available for multi-config projects
Darragh Bailey commented on JENKINS-5079 Release plugin is not available for multi-config projects Perhaps the problem with implementing this is no longer true? I've made a (potentially naive) stab with https://github.com/darraghb/release-plugin/tree/feature/support-multi-configuration-projects and it appears to do the right thing. I'm not particularly familiar with plugin dev for Jenkins, nor the various interaction points in the code, so there may be more to do for this to work correctly in all cases. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14533) Maven plugin: validation on "Root POM" field should be disabled if field contains vars
Ian Kemp
created JENKINS-14533
Maven plugin: validation on "Root POM" field should be disabled if field contains vars
Issue Type:
Bug
Assignee:
Unassigned
Components:
maven
Created:
23/Jul/12 3:08 PM
Description:
Currently, if the Root POM field contains a string with a variable like "${BRANCH}/path/to/pom.xml", an error will be displayed when saving the build configuration. The string will be saved and correctly resolved at runtime, but next time you view the configuration, the Root POM field will be empty *and will be saved as empty*.
I think the resolution might be as simple as having MavenModuleSet.doCheckFileInWorkspace() return FormValidation.ok() if the input string contains a variable - i.e. disabling the validation.
Project:
Jenkins
Priority:
Minor
Reporter:
Ian Kemp
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13837) vSphere Plugin not powering up virtual machines
Srinath C commented on JENKINS-13837 vSphere Plugin not powering up virtual machines I got the issue resolved. VMs are successfully getting launched on the vSphere server now. It was not even related to jenkins or the vSphere Cloud plugin. It was the Leap Second bug on the jenkins server that was causing the problem. I took a jstack of the jenkins process while the slave was stuck at launching and found that the thread was hung at : "pool-6-thread-8" daemon prio=10 tid=0x7f75d8252800 nid=0x7292 sleeping[0x7f768651c000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at com.vmware.vim25.mo.Task.waitForTask(Task.java:229) at com.vmware.vim25.mo.Task.waitForTask(Task.java:152) at org.jenkinsci.plugins.vSphereCloudLauncher.launch(vSphereCloudLauncher.java:169) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) After spending a lot of time peeking into the source code I realized that even a simple program to sleep for 1 second using Thread.currentThread().sleep(1000) was also getting stuck indefinitely. Fortunately, I found the reason at http://stackoverflow.com/questions/11294573/thread-sleep-never-returns and a simple reboot of the server solved the problem. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14534) After jenkins upgrade from 1.464 to 1.474, while executing a job..its recreating the Ant/Maven installation tools again.
rajesh annaram created JENKINS-14534 After jenkins upgrade from 1.464 to 1.474, while executing a job..its recreating the Ant/Maven installation tools again. Issue Type: Bug Assignee: Unassigned Components: ant, maven Created: 23/Jul/12 5:55 PM Description: Hi , I have jenkins installed 1.464 on tomcat webapps with JVM options as -Xmx1024m -XX:MaxPermSize=512m in linux-x86-64 and have ant1.8.3 , maven3.0.3 versions installed automatically after configure and able to build jobs. jenkins upgraded from 1.464 to 1.474 and reloaded existed config.xml , all came up fine but while executing a ant/maven related build job , jenkins1.474 version recreating the Ant/Maven installations again without taking the existed one. no error logs coming. Please suggest whats the issue for this becuase cant able to move forward with new upgrades of jenkins. Due Date: 26/Jul/12 12:00 AM Environment: Linux server Project: Jenkins Priority: Major Reporter: rajesh annaram This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14535) Fails to poll when no executors on master
James Westby created JENKINS-14535 Fails to poll when no executors on master Issue Type: Bug Affects Versions: current Assignee: Gregory Boissinot Components: scripttrigger Created: 23/Jul/12 6:02 PM Description: Hi, ScriptTrigger is very useful, thanks. I have one small issue that I think is related to trying to run everything on slaves. I have a jenkins instance where there are two slaves with two executors each. The master has no executors. In this setup scripttrigger fails to poll with: Polling started on Jul 23, 2012 5:59:44 PM Polling for the job XXX Looking nodes where the poll can be run. Looking for a node to the restricted label YYY. Polling remotely on YYY (1.1.1.1) The expected script execution code is 0 [ERROR] - SEVERE - Polling error null This is the same regardless of whether I try and restrict ScriptTrigger to a label that corresponds to the slaves. Note that in the above log it says it is trying to to poll remotely. If I enable a single executor on the master, even if it is set to only be used by jobs bound to it, then the polling works. Thanks, James Project: Jenkins Priority: Major Reporter: James Westby This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14096) XPath is not working with Jaxen provided by Jenkins
Jørgen Tjernø updated JENKINS-14096 XPath is not working with Jaxen provided by Jenkins This was incorrectly assigned to me - I have nothing to do with this. Moving to component 'core' and setting 'assignee' to 'automatic' (probably kohsuke) Change By: Jørgen Tjernø (23/Jul/12 6:06 PM) Assignee: Jørgen Tjernø Component/s: core Component/s: ruby-plugin-runtime This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14536) Jenkins logo in JIRA is served using http resulting in a security warning for every page load
bap created JENKINS-14536 Jenkins logo in JIRA is served using http resulting in a security warning for every page load Issue Type: Bug Assignee: Unassigned Components: infrastructure Created: 23/Jul/12 6:09 PM Description: When using the jenkins jira instance (using https) every page load results in a warning from the web browser as the logo is served over HTTP Environment: Any modern web browser Project: Jenkins Priority: Major Reporter: bap This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14340) Remote directory of a Transfer Set should resolve env variable more than once
bap commented on JENKINS-14340 Remote directory of a Transfer Set should resolve env variable more than once This is non trivial due to the way variables are currently resolved in the publish over plugins. I will look into it at some point, and see if the token macro plugin can be used to resolve variables without affecting the current behaviour. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14514) Repeatable jelly tag appears to be broken in 1.474+
bap commented on JENKINS-14514 Repeatable jelly tag appears to be broken in 1.474+ Another candidate is the change to prevent ajax calls when the page is not visible. I cannot find anything else in the changes from 1.473 to 1.474 that may have introduced this issue This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14537) Template SCMs + Multiple SCMs results in failure parsing change log
Joe Hansche created JENKINS-14537 Template SCMs + Multiple SCMs results in failure parsing change log Issue Type: Bug Assignee: Kevin Bell Components: multiple-scms, template-project Created: 23/Jul/12 6:21 PM Description: Using a configuration similar that outlined in the Environment field, Jenkins is unable to parse the changelog.xml file, because it results in a nested CDATA section. That is because Multiple-SCMs creates an XML structure similar to: "hudson.plugins.git.GitSCM"> "hudson.plugins.git.GitSCM"> That works fine for just the multiple-scm configuration. But when combined with the template-project "Use SCM from another project" option, the sub-log itself is completely wrapped in CDATA, thus resulting in an invalid XML document (it is invalid to nest CDATA sections): "hudson.plugins.git.GitSCM"> "hudson.plugins.templateproject.ProxySCM"> "hudson.plugins.git.GitSCM"> ]]> As you can see, the GitSCM sub-log entries here are wrapped in CDATA, but the ProxySCM entry was already wrapped in CDATA. Ideally, CDATA should only be used if needed (e.g., in this case, the nodes could simply be nested, and only use CDATA around the actual commit data [from GitSCM]). Environment: * Template1: ** Multiple SCMs: *** Git[subprojectA]: git://server/subprojectA.git *** Git[subprojectB]: git://server/subprojectB.git * ProjectJob: ** Multiple SCMs: *** Use SCM from another job: Template1 *** Git[project]: git://server/project.git Project: Jenkins Priority: Major Reporter: Joe Hansche This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-4564) Launch slave agent: jcifs SmbException
Denis Blanchette commented on JENKINS-4564 Launch slave agent: jcifs SmbException I am having the same issue on a Windows Server 2008 R2 and Windows 7 x64 slave. Here is an example : Connecting to beast.example.com Checking if Java exists java full version "1.6.0_26-b03" Installing the Jenkins slave service Copying jenkins-slave.exe Copying slave.jar ERROR: 0xC205 jcifs.smb.SmbException: 0xC205 at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:545) at jcifs.smb.SmbTransport.send(SmbTransport.java:646) at jcifs.smb.SmbSession.send(SmbSession.java:244) at jcifs.smb.SmbTree.send(SmbTree.java:119) at jcifs.smb.SmbFile.send(SmbFile.java:770) at jcifs.smb.SmbFile.open0(SmbFile.java:982) at jcifs.smb.SmbFile.open(SmbFile.java:999) at jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:142) at jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:97) at jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:67) at jcifs.smb.SmbFile.getOutputStream(SmbFile.java:2842) at hudson.os.windows.ManagedWindowsServiceLauncher.copySlaveJar(ManagedWindowsServiceLauncher.java:416) at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:298) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) AAABb85aBtbiIQSmjNKU4P08vOT+vOD8nVc8DzHWtSE4tKMnMz/PLL0ldFVf2c+b/lb5MDAwVRQxSaBqcITRIIQMEMIIUFgAAckCEiWA=[0morg.jinterop.dcom.common.JIException: Message not found for errorCode: 0xC205 at org.jinterop.winreg.smb.JIWinRegStub.winreg_OpenHKLM(JIWinRegStub.java:102) at hudson.util.jna.DotNet.isInstalled(DotNet.java:77) at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:288) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: jcifs.smb.SmbException: 0xC205 at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:545) at jcifs.smb.SmbTransport.send(SmbTransport.java:622) at jcifs.smb.SmbSession.send(SmbSession.java:244) at jcifs.smb.SmbTree.send(SmbTree.java:119) at jcifs.smb.SmbFile.send(SmbFile.java:770) at jcifs.smb.TransactNamedPipeOutputStream.write(TransactNamedPipeOutputStream.java:65) at rpc.ncacn_np.RpcTransport.send(RpcTransport.java:113) at rpc.DefaultConnection.transmitFragment(DefaultConnection.java:127) at rpc.DefaultConnection.transmit(DefaultConnection.java:55) at rpc.ConnectionOrientedEndpoint.send(ConnectionOrientedEndpoint.java:223) at rpc.ConnectionOrientedEndpoint.connect(ConnectionOrientedEndpoint.java:249) at rpc.ConnectionOrientedEndpoint.bind(ConnectionOrientedEndpoint.java:217) at rpc.ConnectionOrientedEndpoint.call(ConnectionOrientedEndpoint.java:85) at rpc.Stub.call(Stub.java:112) at org.jinterop.winreg.smb.JIWinRegStub.winreg_OpenHKLM(JIWinRegStub.java:100) ... 8 more This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14537) Template SCMs + Multiple SCMs results in failure parsing change log
Joe Hansche
commented on JENKINS-14537
Template SCMs + Multiple SCMs results in failure parsing change log
To elaborate, I think the problem is that ProxySCM should avoid the CDATA entirely, because it should be understood that the remote ("proxied") SCM will already use CDATA where it needs to:
"hudson.plugins.git.GitSCM">
"hudson.plugins.templateproject.ProxySCM">
"hudson.plugins.git.GitSCM">
That way, even if ProxySCM uses only a single remote GitSCM configuration, it is still valid. I haven't looked into the code, so the problem may actually be Multiple-SCMs using CDATA all the time, when it is only necessary for the actual final SCM log data. That may be difficult to determine though, since neither plugin was probably designed to work with the other. In our case though (as mentioned in the Environment field above), this combination is actually very useful, and we use it for dozens of jobs. It works well in general, the only thing that fails is the changelog parsing (which in turn causes our log file to fill up because of the error in parsing the changelog.xml file)
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-4564) Launch slave agent: jcifs SmbException
Denis Blanchette edited a comment on JENKINS-4564 Launch slave agent: jcifs SmbException I am having the same issue on a Windows Server 2008 R2 x64 master and Windows 7 x64 slave. Here is an example : Connecting to beast.example.com Checking if Java exists java full version "1.6.0_26-b03" Installing the Jenkins slave service Copying jenkins-slave.exe Copying slave.jar ERROR: 0xC205 jcifs.smb.SmbException: 0xC205 at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:545) at jcifs.smb.SmbTransport.send(SmbTransport.java:646) at jcifs.smb.SmbSession.send(SmbSession.java:244) at jcifs.smb.SmbTree.send(SmbTree.java:119) at jcifs.smb.SmbFile.send(SmbFile.java:770) at jcifs.smb.SmbFile.open0(SmbFile.java:982) at jcifs.smb.SmbFile.open(SmbFile.java:999) at jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:142) at jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:97) at jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:67) at jcifs.smb.SmbFile.getOutputStream(SmbFile.java:2842) at hudson.os.windows.ManagedWindowsServiceLauncher.copySlaveJar(ManagedWindowsServiceLauncher.java:416) at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:298) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) AAABb85aBtbiIQSmjNKU4P08vOT+vOD8nVc8DzHWtSE4tKMnMz/PLL0ldFVf2c+b/lb5MDAwVRQxSaBqcITRIIQMEMIIUFgAAckCEiWA=[0morg.jinterop.dcom.common.JIException: Message not found for errorCode: 0xC205 at org.jinterop.winreg.smb.JIWinRegStub.winreg_OpenHKLM(JIWinRegStub.java:102) at hudson.util.jna.DotNet.isInstalled(DotNet.java:77) at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:288) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: jcifs.smb.SmbException: 0xC205 at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:545) at jcifs.smb.SmbTransport.send(SmbTransport.java:622) at jcifs.smb.SmbSession.send(SmbSession.java:244) at jcifs.smb.SmbTree.send(SmbTree.java:119) at jcifs.smb.SmbFile.send(SmbFile.java:770) at jcifs.smb.TransactNamedPipeOutputStream.write(TransactNamedPipeOutputStream.java:65) at rpc.ncacn_np.RpcTransport.send(RpcTransport.java:113) at rpc.DefaultConnection.transmitFragment(DefaultConnection.java:127) at rpc.DefaultConnection.transmit(DefaultConnection.java:55) at rpc.ConnectionOrientedEndpoint.send(ConnectionOrientedEndpoint.java:223) at rpc.ConnectionOrientedEndpoint.connect(ConnectionOrientedEndpoint.java:249) at rpc.ConnectionOrientedEndpoint.bind(ConnectionOrientedEndpoint.java:217) at rpc.ConnectionOrientedEndpoint.call(ConnectionOrientedEndpoint.java:85) at rpc.Stub.call(Stub.java:112) at org.jinterop.winreg.smb.JIWinRegStub.winreg_OpenHKLM(JIWinRegStub.java:100) ... 8 more This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14125) The workspace parameter passed to perforce-plugin have problem with "/" at the begining
SCM/JIRA link daemon resolved JENKINS-14125 as Fixed The workspace parameter passed to perforce-plugin have problem with "/" at the begining Change By: SCM/JIRA link daemon (23/Jul/12 6:51 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14125) The workspace parameter passed to perforce-plugin have problem with "/" at the begining
SCM/JIRA link daemon commented on JENKINS-14125 The workspace parameter passed to perforce-plugin have problem with "/" at the begining Code changed in jenkins User: Rob Petti Path: src/main/java/hudson/plugins/perforce/PerforceSCM.java http://jenkins-ci.org/commit/perforce-plugin/e7d5a1d082335daf6056227e369969aa4c65db90 Log: [FIXED JENKINS-14125] removed code that was messing up remote workspace paths This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14335) Jenkins build API changeset contains duplicated fields
SCM/JIRA link daemon resolved JENKINS-14335 as Fixed Jenkins build API changeset contains duplicated fields Change By: SCM/JIRA link daemon (23/Jul/12 7:02 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14335) Jenkins build API changeset contains duplicated fields
SCM/JIRA link daemon commented on JENKINS-14335 Jenkins build API changeset contains duplicated fields Code changed in jenkins User: Rob Petti Path: src/main/java/hudson/plugins/perforce/PerforceChangeLogEntry.java http://jenkins-ci.org/commit/perforce-plugin/b2063692fb3a53792831f6a8e0acd6fee86eaef2 Log: [FIXED JENKINS-14335] removing redundant exports This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14273) Matrix jobs don't get loaded
Michael Prokop commented on JENKINS-14273 Matrix jobs don't get loaded Yes, it works for me again with Jenkins 1.475. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14537) Template SCMs + Multiple SCMs results in failure parsing change log
Joe Hansche
edited a comment on JENKINS-14537
Template SCMs + Multiple SCMs results in failure parsing change log
Looking into this more, I guess the real problem is that the changelog itself is generally not XML (but plain text). ProxySCM generally does not inject any sort of identifier that it is the one responsible for the changelog (just proxies what the original SCM changelog said, verbatim). I see that Multiple-SCMs actually expects to never have a nested node (because it removes the MultiSCM descriptor from the list of available SCMs to choose from). However, the ProxySCM now makes it possible to have that nested changelog, and because it's a template project, it actually does make sense to allow for that.
One way to get around this would be to strip the tags from the ProxySCM sublog, but then you're relying on text-based magic to achieve it, and it still wouldn't really be perfect.
Instead, I think the most appropriate way to fix this is to go back to what the standard ChangeLogParser does (at least, how GitSCM works), and NOT expect any XML structure at all. Instead, maybe a kind of binary-safe parser that inserts a marker with the SCM class identifier, plus the length of the next "sub-log chunk". The reader would then read the length number, then read that many bytes from the file, and treat that as one separate sublog file. Then the sublog writer call would look something more like:
String subLogText = FileUtils.readFileToString(subChangeLog);
logWriter.write(String.format("MultiSCM:\"%s\"\n%d\n%s\n",
scm.getType(),
subLogText.length(),
subLogText);
And the output (e.g., from my initial description) would be more like:
MultiSCM:hudson.plugins.git.GitSCM
512
Changes in origin/master, ...
...
total of 512 bytes here
...
MultiSCM:hudson.plugins.templateproject.ProxySCM
1122
MultiSCM:hudson.plugins.git.GitSCM
512
Changes in projectA/master, ...
...
total of 512 bytes here
...
MultiSCM:hudson.plugins.git.GitSCM
512
Changes in projectB/master, ...
...
total of 512 bytes here
...
The tokenization is still not perfect, and particularly with the way ProxySCM works (since there is no easy way to tell that the proxied SCM is in fact a MultiSCM changelog).
Although, for that matter, ... It would actually make sense to use a true libxml document generator, and let it decide whether to do CDATA or not, based on what the text is. Could also just encode the cdata section (e.g, using < > ), so that the nested is not interpreted as such.
In general, I think it's a mistake to use the SAX parser to read the file, but not use the SAX framework to generate the XML in the first place. By using plain String.format(), you are not guaranteeing that the resulting XML file is valid, thus the SAX parser will barf on the invalid document, because you didn't use a proper XML-generating library to create the file initially. I'm sure using was your way of getting around that, but as you can see here, that is still not perfect (and in fact, you would still have the same problem, if a commit message was written with something like:
$ git commit -m'Wrap the unknown content in to avoid parsing issues'
Because it would result in the same bug described here.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14537) Template SCMs + Multiple SCMs results in failure parsing change log
Joe Hansche
commented on JENKINS-14537
Template SCMs + Multiple SCMs results in failure parsing change log
Looking into this more, I guess the real problem is that the changelog itself is generally not XML (but plain text). ProxySCM generally does not inject any sort of identifier that it is the one responsible for the changelog (just proxies what the original SCM changelog said, verbatim). I see that Multiple-SCMs actually expects to never have a nested node (because it removes the MultiSCM descriptor from the list of available SCMs to choose from). However, the ProxySCM now makes it possible to have that nested changelog, and because it's a template project, it actually does make sense to allow for that.
One way to get around this would be to strip the tags from the ProxySCM sublog, but then you're relying on text-based magic to achieve it, and it still wouldn't really be perfect.
Instead, I think the most appropriate way to fix this is to go back to what the standard ChangeLogParser does (at least, how GitSCM works), and NOT expect any XML structure at all. Instead, maybe a kind of binary-safe parser that inserts a marker with the SCM class identifier, plus the length of the next "sub-log chunk". The reader would then read the length number, then read that many bytes from the file, and treat that as one separate sublog file. Then the sublog writer call would look something more like:
String subLogText = FileUtils.readFileToString(subChangeLog);
logWriter.write(String.format("MultiSCM:\"%s\"\n%d\n%s\n",
scm.getType(),
subLogText.length(),
subLogText);
And the output (e.g., from my initial description) would be more like:
MultiSCM:hudson.plugins.git.GitSCM
512
Changes in origin/master, ...
...
total of 512 bytes here
...
MultiSCM:hudson.plugins.templateproject.ProxySCM
1122
MultiSCM:hudson.plugins.git.GitSCM
512
Changes in projectA/master, ...
...
total of 512 bytes here
...
MultiSCM:hudson.plugins.git.GitSCM
512
Changes in projectB/master, ...
...
total of 512 bytes here
...
The tokenization is still not perfect, and particularly with the way ProxySCM works (since there is no easy way to tell that the proxied SCM is in fact a MultiSCM changelog).
Although, for that matter, ... It would actually make sense to use a true libxml document generator, and let it decide whether to do CDATA or not, based on what the text is. Could also just encode the cdata section (e.g, using < > ), so that the nested is not interpreted as such.
In general, I think it's a mistake to use the SAX parser to read the file, but not use the SAX framework to generate the XML in the first place. By using plain String.format(), you are not guaranteeing that the resulting XML file is valid, thus the SAX parser will barf on the invalid document, because you didn't use a proper XML-generating library to create the file initially. I'm sure using was your way of getting around that, but as you can see here, that is still not perfect (and in fact, you would still have the same problem, if a commit message was written with something like:
$ git commit -m'Wrap the unknown content in to avoid parsing issues'
Because it would result in the same bug described here.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14538) Separate "configure tools" page
jglick created JENKINS-14538 Separate "configure tools" page Issue Type: Bug Assignee: Unassigned Components: core, gui Created: 23/Jul/12 7:31 PM Description: Currently if you want to manage tool installations in a Jenkins instance, you just go to the master /configure page. Unfortunately this can get out of hand: when there are a lot of tools already (such as twenty dot-dot JDK releases), regular Jenkins configuration can get lost in the mess. The configureTools branch (see URL) proposes to split tool installations off into their own configuration page for comfort. Open issues: All tools are shown on a single page, though it may also be feasible to produce one page per tool type (Ant, Maven, JDK, ...); or one page with tabs, if there were a clear meaning for Save and Apply in that case. The management link uses the same setting.png as the main /configure page; probably needs its own icon. TBD whether other bits of configuration belong in the new location, notably ToolLocationNodeProperty and Shell.DescriptorImpl - should there be a way of indicating that a given Descriptor would like to be renderer on an alternate config page? Project: Jenkins Labels: configuration Priority: Minor Reporter: jglick This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14538) Separate "configure tools" page
jan_ruzicka commented on JENKINS-14538 Separate "configure tools" page This is interesting idea. Can there be a link from the main configuration page to the one with separated plugin settings? It would be nice for easier transition. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14461) Warnings plugin not Java 1.5 compatible?
Trevor Bekolay commented on JENKINS-14461 Warnings plugin not Java 1.5 compatible? Thank you! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14480) Git plugin 1.1.21 cannot build branches with repository specified but no wildcards
SCM/JIRA link daemon commented on JENKINS-14480 Git plugin 1.1.21 cannot build branches with repository specified but no wildcards Code changed in jenkins User: Nicolas De Loof Path: src/main/java/hudson/plugins/git/util/DefaultBuildChooser.java http://jenkins-ci.org/commit/git-plugin/2ee61e6c01ac47099dd0ade635e0ea78d558f362 Log: [FIXED JENKINS-14480] handle fully qualified branch names backward compatible way This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14480) Git plugin 1.1.21 cannot build branches with repository specified but no wildcards
SCM/JIRA link daemon resolved JENKINS-14480 as Fixed Git plugin 1.1.21 cannot build branches with repository specified but no wildcards Change By: SCM/JIRA link daemon (23/Jul/12 8:29 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8563) REOPEN -Can't use parameters in git plugin "Branches to build" configuration
SCM/JIRA link daemon resolved JENKINS-8563 as Fixed REOPEN -Can't use parameters in git plugin "Branches to build" configuration Change By: SCM/JIRA link daemon (23/Jul/12 8:49 PM) Status: Reopened Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8563) REOPEN -Can't use parameters in git plugin "Branches to build" configuration
SCM/JIRA link daemon commented on JENKINS-8563 REOPEN -Can't use parameters in git plugin "Branches to build" configuration Code changed in jenkins User: Nicolas De Loof Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/2283620895c888f5f02f06fcac2fb33f1def0691 Log: [FIXED JENKINS-8563] add support for env expansion on branch specification This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14516) Build process hangs after slave finished the build with success
Attila Tamás Zimler resolved JENKINS-14516 as Not A Defect Build process hangs after slave finished the build with success It turned out, that one of the program in the build process does not quit correctly (but looks like running correctly) and the build hangs because the program does not really quit. Change By: Attila Tamás Zimler (23/Jul/12 9:04 PM) Status: Open Resolved Resolution: Not A Defect This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
Top sites for sale
Hello, Apologies for the unsolicited email.. I've got a proposition concerning your website. Would you be interested in acquiring any of the websites listed on http://www.wrongstart.net (don't forget to scroll!) I can upload an HTML file temporarily to verify ownership of the domain, in case you're concerned. Let me know what you think to discuss further. PS: I'm only emailing you because I believe you can benefit from this and you wouldn't have to waste tens of thousands in advertising cost yet you can benefit viraly by owning I do not intend to email you again unless you respond to this inquiry. Regards, Dan Whitehouse http://twitter.com/dannywhitehouse
[JIRA] (JENKINS-14539) Incorrectly Using Committer User Full Name in resolving Committer Email Address
J Sidney created JENKINS-14539 Incorrectly Using Committer User Full Name in resolving Committer Email Address Issue Type: Bug Assignee: Slide-O-Mix Components: email-ext, git Created: 23/Jul/12 9:25 PM Description: I have seen where this same issue has been resolved for other SCM plugins, but this is still happening for the GIT SCM When using the Email Ext plugin and selecting the "Send To Committers" option on failure, it appears that the committer user's full name is being used and is creating two email addresses to be sent notification. For example if the committer user's full name is John Doe and the default email suffix is "@jenkins.com" then the committer designated emails are incorrectly being sent to: j...@jenkins.com d...@jenkins.com The committer's actual email address is not even being accessed Jenkins 1.472 Email-ext 2.22 Git 1.1.21 Environment: RHEL 5.8 Project: Jenkins Priority: Major Reporter: J Sidney This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14526) NPE in greenballs
asgeirn commented on JENKINS-14526 NPE in greenballs Which version of the Green Balls plugin? Is the error reproducible with the Green Balls plugin disabled? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14497) Can't start emulator with new Android SDK Tools rev. 20.0.1
Kevin Chow commented on JENKINS-14497 Can't start emulator with new Android SDK Tools rev. 20.0.1 Yes, this is reproducible on my side. Checking with Android SDK Manager, 20.0.1 Android SDK Tools is being used and caused this error when running a job with Android Emulator. Thanks, Kevin This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14497) Can't start emulator with new Android SDK Tools rev. 20.0.1
Kevin Chow edited a comment on JENKINS-14497 Can't start emulator with new Android SDK Tools rev. 20.0.1 Yes, this is reproducible on my side. Checking with Android SDK Manager, Android SDK Tools 20.0.1 is being used and caused this error when running a job with Android Emulator. We are using Android Emulator Plugin 2.2. Thanks, Kevin This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14540) hudson.model.Hudson cannot be cast to hudson.model.Slave
Henri Pipe created JENKINS-14540 hudson.model.Hudson cannot be cast to hudson.model.Slave Issue Type: Bug Assignee: jarlebh Components: skype, skype-notifier Created: 23/Jul/12 11:01 PM Description: Trying to get skype-notifier plugin working. When Jenkins fires up, it throws: createConnection java.lang.ClassCastException: hudson.model.Hudson cannot be cast to hudson.model.Slave at hudson.plugins.skype.im.transport.SkypeIMConnection.createConnection(SkypeIMConnection.java:147) at hudson.plugins.skype.im.transport.SkypeIMConnection.connect(SkypeIMConnection.java:106) at hudson.plugins.skype.im.transport.SkypeIMConnectionProvider.createConnection(SkypeIMConnectionProvider.java:53) at hudson.plugins.im.IMConnectionProvider.create(IMConnectionProvider.java:65) at hudson.plugins.im.IMConnectionProvider.access$600(IMConnectionProvider.java:22) at hudson.plugins.im.IMConnectionProvider$ConnectorRunnable.run(IMConnectionProvider.java:183) at java.lang.Thread.run(Thread.java:636) Skype is running on the system as the same user, jenkins from config.xml: All 0 skype Can't seem to find much on the web about the installation. Followed the example on jenkins site, however, I only have a master, no slave. Any pointers or help would be greatly appreciated. Thanks Henri Pipe Environment: Jenkins 1.460, Ubuntu 10.4 , Linux 2.6.32-37-generic ; Instant Messaging Plugin 1.21, Fix Versions: current Project: Jenkins Labels: skype-notifier Priority: Blocker Reporter: Henri Pipe This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13972) Concurrent matrix builds abort
SCM/JIRA link daemon commented on JENKINS-13972 Concurrent matrix builds abort Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html core/src/main/java/hudson/matrix/MatrixBuild.java core/src/main/java/hudson/matrix/MatrixConfiguration.java http://jenkins-ci.org/commit/jenkins/9c7ef619cc96dc0111220412e841199de71d5b8d Log: [FIXED JENKINS-13972] Fixed a problem in actually making concurrent builds work. Compare: https://github.com/jenkinsci/jenkins/compare/c2c31e2b933a...9c7ef619cc96 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13972) Concurrent matrix builds abort
SCM/JIRA link daemon resolved JENKINS-13972 as Fixed Concurrent matrix builds abort Change By: SCM/JIRA link daemon (23/Jul/12 11:44 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14095) RedHat RPM has different checksum than repository metadata
billy paul reopened JENKINS-14095 RedHat RPM has different checksum than repository metadata On all packages >= 1.469, I'm still seeing this issue. If I try a lower version (i.e. 1.460), it works fine. I think there is something still out of whack with the checksum generation. Change By: billy paul (24/Jul/12 12:47 AM) Resolution: Fixed Status: Resolved Reopened This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14541) Option to checkout with --quiet (or equivalent)
dmeibusch created JENKINS-14541 Option to checkout with --quiet (or equivalent) Issue Type: Improvement Assignee: Unassigned Components: subversion Created: 24/Jul/12 4:20 AM Description: The console output of projects with very large checkouts can be dominated by subversion output. For checkouts, it would be nice to suppress this output. Other mechanisms for sync'ing such as update still benefit from the information. Project: Jenkins Priority: Major Reporter: dmeibusch This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14542) Issue ID Pattern no longer working
James Bushell created JENKINS-14542 Issue ID Pattern no longer working Issue Type: Bug Affects Versions: current Assignee: sogabe Components: mantis Created: 24/Jul/12 4:35 AM Description: Our commit messages starts with [12345] . and I used to use Issue id pattern [%ID%], however this is no longer working. Reading through hudson.plugins.mantis.MantisProjectProperty.java, method createRegexp(..) should generate the regular _expression_ (?<=[)(\d+)(?=]) which will happily find the regex, so doesn't look like its a problem there. What appears to be occuring is that the Issue ID pattern is being saved with quotes around it eg "[%ID%]", because if I commit svn messages with quotes around the square brackets it all works, and looking in the job xml it is saving the field as "[%ID%]" I can get around the problem by using a Regexp pattern of [(\d+)] and leave the Issue id pattern blank, but it would be ideal if this could be fixed Project: Jenkins Priority: Minor Reporter: James Bushell This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14542) Issue ID Pattern no longer working
James Bushell commented on JENKINS-14542 Issue ID Pattern no longer working Note that this Jira issue doesn't show the escaped left/right square brackets correctly for the regular expressions. There is a \ before the [ or ] This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14543) Add full name option for admin user
Vijay Kiran created JENKINS-14543 Add full name option for admin user Issue Type: New Feature Assignee: Vijay Kiran Components: jclouds Created: 24/Jul/12 5:11 AM Description: Add an optional field for the plugin configuration to specify the Admin user's Full Name. JClouds API now supports fullName option (http://code.google.com/p/jclouds/issues/detail?can=2&q=1020) Fix Versions: current Project: Jenkins Priority: Major Reporter: Vijay Kiran This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13855) Parallel deployment to Tomcat 7 with deploy plugin throws exception and fails the build
Daniel Barth commented on JENKINS-13855 Parallel deployment to Tomcat 7 with deploy plugin throws exception and fails the build I found an corresponding issue in the Cargo Jira: https://jira.codehaus.org/browse/CARGO-1041 I'm also working on updating the deploy plugin to the latest Cargo version (1.2.3). I forked the GitHub repo (username trexter) and did the changes to use Cargo 1.2.3, the plugin is compiling and building fine in Eclipse. I get the .hpi and I can upload and install it in Jenkins 1.473. I can see it under installed plugins with correct version number (used 1.10) but I cannot add it to a (freestyle) job, it's not showing up in the post build action picker!? I found nothing the logs so far regarding the plugin. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14095) RedHat RPM has different checksum than repository metadata
Vladimir Girnet commented on JENKINS-14095 RedHat RPM has different checksum than repository metadata I've just updated to 1.475-1.1 using default Jenkins repository (baseurl=http://pkg.jenkins-ci.org/redhat/) without any issues. You may try to do a "yum clean all" before checking for updates. So, I think Jenkins repository is ok. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
