[JIRA] (JENKINS-8226) Add reviewers in gerrit when a build is successful
rsandell commented on JENKINS-8226 Add reviewers in gerrit when a build is successful It's basically that feature I am waiting for before I make a new release. 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-15415) Anonymous users can browse source code through coverage report
Jes Struck commented on JENKINS-15415 Anonymous users can browse source code through coverage report I have created this pull reqeust to solve the issue https://github.com/jenkinsci/cobertura-plugin/pull/11 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-16011) Add a global view
mat007 created JENKINS-16011 Add a global view Issue Type: Improvement Assignee: wolfs Components: depgraph-view Created: 03/Dec/12 9:27 AM Description: It would be very useful to have a global view with all projects and their dependencies in order to track missing dependencies. Thanks ! Project: Jenkins Priority: Major Reporter: mat007 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-16007) Weblogic Deploy periodically not working
Ye Gaung commented on JENKINS-16007 Weblogic Deploy periodically not working I'm also facing same 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-15562) Support setting the client version
johno commented on JENKINS-15562 Support setting the client version As the plugin maintainer feel free to do as you please. I was simply looking at offers on FreedomSponsors for some quick cash to purchase a new modem 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-16012) Allow users to be able to specify a reason why Jenkins is in shutdown
Thomas Fields created JENKINS-16012 Allow users to be able to specify a reason why Jenkins is in shutdown Issue Type: Improvement Affects Versions: current Assignee: Unassigned Components: core Created: 03/Dec/12 11:44 AM Description: Hi there, You can already specify a reason why you're taking a build node offline and I think it would be really useful if you could specify why you've put Jenkins in shutdown when you click "Jenkins->Manage Jenkins->Prepare for shutdown". Seems like an easy thing to add and plugins such as thinBackup, which automatically triggers a shutdown command in order to perform the backup could then use this new API to provide it's own reason description. Cheers, Tom Environment: Windows 7 Project: Jenkins Priority: Major Reporter: Thomas Fields 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-16013) "Use custom workspace" is not working with the MultiJob Plugin
Doron Shai created JENKINS-16013 "Use custom workspace" is not working with the MultiJob Plugin Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: plugin Created: 03/Dec/12 12:31 PM Description: When I use the "Use custom workspace" (Out of the box feature of Jenkins, under the Advanced Project Options area), enter some path i.e. c:\Example), Save and then open the Job again the customized value disappears. Environment: Windows 2008 R2, Tomcat 7.0, Jenkins 1.490 and MultiJob Plugin 1.7 Project: Jenkins Priority: Major Reporter: Doron Shai 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-16013) [jenkins-multijob-plugin] "Use custom workspace" is not working with the MultiJob Plugin
Doron Shai updated JENKINS-16013 [jenkins-multijob-plugin] "Use custom workspace" is not working with the MultiJob Plugin Change By: Doron Shai (03/Dec/12 12:32 PM) Summary: [jenkins-multijob-plugin] "Use custom workspace" is not working with the MultiJob Plugin Component/s: jenkins-multijob-plugin Component/s: 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-15799) loosing matrix sub builds
G. Ann Campbell commented on JENKINS-15799 loosing matrix sub builds The ticket I opened got closed as a duplicate of this one. I saw this "forgetting" behavior with a renamed, top-level, non-matrix job. Right after renaming the job, the builds showed in the history, but ... several hours later they were gone (altho still there on disk.) 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-16014) losing build history in configuration matrix jobs
Michaël Serisier created JENKINS-16014 losing build history in configuration matrix jobs Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 03/Dec/12 1:15 PM Description: I have several jobs set to use a configuration matrix. Since I upgraded to 1.492, it looks like builds are lost after each Jenkins restart. This happens for some jobs only. I have already had problems loading the old builds in such jobs in the past (after the changes made to improve Jenklins startup times around 1.47x), but at least the build folders weren't removed from the disk, so downgrading fixed my issues. Here is a better description of the jobs that lose their history: MYJOB: matrix configuration of "windows" and "linux" runs on: master (which is also the machine used for the "windows" configuration) After a Jenkins restart (Jenkins is running as a service), all folders inside of \Jenkins\jobs\MYJOB\configurations\axis-os\windows\builds are moved. The folders in \Jenkins\jobs\MYJOB\builds are not affected The only plugin used by this job is https://wiki.jenkins-ci.org/display/JENKINS/Build+Name+Setter+Plugin, but it is used in jobs that are not affected by this weird behaviour. I cannot find any errors in the logs, and I'm wondering where to start to provide any interesting information to understand the problem. Is anyone else experiencing something like this? Environment: Windows Server 2008 SP2 Project: Jenkins Labels: history loss-of-data build deletion Priority: Critical Reporter: Michaël Serisier 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-15415) Anonymous users can browse source code through coverage report
Jes Struck assigned JENKINS-15415 to Jes Struck Anonymous users can browse source code through coverage report Change By: Jes Struck (03/Dec/12 1:15 PM) Assignee: stephenconnolly Jes Struck 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-16015) Ability to reserve a slot for specific jobs
Matthias Gerstner created JENKINS-16015 Ability to reserve a slot for specific jobs Issue Type: New Feature Assignee: Unassigned Components: core Created: 03/Dec/12 1:35 PM Description: Consider the following scenario: There's a large number of different jobs configured that get triggered a lot all the time. Each of the jobs takes a considerable amount of time to run. On the other there's have a small number of jobs that run not that often and when they run they don't take very long. The latter kind of jobs will suffer starvation by the other kind. If the small jobs are of higher importance for some reason then there's no easy way to priotize them. Even the "Priority Sorter Plugin" doesn't really help, because before the job at the top of the queue is scheduled a slot needs to become available which can take maybe an hour or two before one of the long running jobs completes. What would be really great is to have the ability to configure slots at a similar level as nodes can be configured in respect to labels. I'd like to be able to reserve some slots for the one kind of jobs and some other slots for the other kind of jobs. Project: Jenkins Priority: Minor Reporter: Matthias Gerstner 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-14473) Jenkins server memory leak
Liya Katz commented on JENKINS-14473 Jenkins server memory leak Upgrading to 1.492 (from 1.473) has solved this problem for us. 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-16014) losing build history in configuration matrix jobs
Michaël Serisier commented on JENKINS-16014 losing build history in configuration matrix jobs I can reproduce the problem on a new (clean!) installation, old builds are not loaded after a restart, although my folders aren't always deleted at startup. I'll include a simple job configuration file so you can reproduce it. 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-16014) losing build history in configuration matrix jobs
Michaël Serisier updated JENKINS-16014 losing build history in configuration matrix jobs Change By: Michaël Serisier (03/Dec/12 1:54 PM) Priority: Critical Blocker 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-16014) losing build history in configuration matrix jobs
Michaël Serisier updated JENKINS-16014 losing build history in configuration matrix jobs Steps: 1. Unzip the zip file in \jobs 2. Reload the Jenkins configuration 3. Click the project name Observe: the build of the project are all listed, but the builds of the "default" configuration are not loaded. In some cases, the builds of the "default" configuration are even deleted at startup. The default configuration is run on the master. In my production system, the configuration axes involve proper slaves, not just the "default" configuration. Change By: Michaël Serisier (03/Dec/12 2:04 PM) Attachment: 12E.zip 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-14376) Rational Team Concert Plugin: NullPointerException when changes has been accepted but not yet delivered
chris pearson commented on JENKINS-14376 Rational Team Concert Plugin: NullPointerException when changes has been accepted but not yet delivered Is there any update on a fix for this? We'd like to not lose our incremental builds, but this is causing problems with our CI solution. 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-16016) Global passwords are visible for matrix configuration builds
Natalia Naumova created JENKINS-16016 Global passwords are visible for matrix configuration builds Issue Type: Bug Assignee: Gregory Boissinot Components: envinject Created: 03/Dec/12 2:19 PM Description: I have environment variables defined as 'Global passwords' in matrix job configuration visible with upgrade to envinject 1.73. Previously there were links to 'Injected Environment Variables' only for the configurations of matrix project, e.g.: $JENKINS_URL/job/$JOBNAME/$BUILD_NUMBER/arch=arch1/injectedEnvVars/? With 1.73 update the 'Injected Environment Variables' link appeared for the parent builds, e.g.: $JENKINS_URL/job/$JOBNAME/$BUILD_NUMBER/injectedEnvVars/? And the environment variables defined as 'Global Passwords' are visible in plain text here. Environment: jenkins core 1.492 envinject 1.73 Project: Jenkins Priority: Major Reporter: Natalia Naumova 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-15466) Fatal Error No Class Definition found for Kernel32
pjdarton updated JENKINS-15466 Fatal Error No Class Definition found for Kernel32 I suspect that this is (yet another) case of Windows being a bit non-deterministic - we had this bug happening @work and rebooting the slave made the problem go away, but the slaves get rebooted regularly anyway... As a workaround, I'd suggest that the code drop back to the "old fashioned" way of comparing the canonical path to absolute path if the Windows-specific code fails. This is what I'm doing at work now - as this is an intermittant issue it is difficult to be certain that this change had fixed it completely, but I am sure that it's no worse. I've attached a patch that does this workaround. Change By: pjdarton (03/Dec/12 2:33 PM) Attachment: noclassdeffound_workaround.patch 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-15947) Promoted builds *list* should also be requestable via REST
Thomas Lehmann commented on JENKINS-15947 Promoted builds *list* should also be requestable via REST Could please tell some one if this bug will be fixed (or if it will be rejected) (regardless of the time it's being started or even resolved)? 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-15915) Password Parameter should not be stored (on disk)
Thomas Lehmann commented on JENKINS-15915 Password Parameter should not be stored (on disk) Could please tell some one if this bug will be fixed (or if it will be rejected) (regardless of the time it's being started or even resolved)? 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-16017) Workspace will not create in Jenkins from script
Russell Keeton
created JENKINS-16017
Workspace will not create in Jenkins from script
Issue Type:
Bug
Affects Versions:
current
Assignee:
Richard Lavoie
Components:
selenium
Created:
03/Dec/12 3:04 PM
Description:
When attempting to create a Workspace, nothing appears to be created.
=build/execute script=
[EnvInject] - Executing and processing the following script content:
echo ${WORKSPACE}
cd ${WORKSPACE}
pwd
if [ -d ".env" ]; then
echo "**> virtualenv exists"
else
echo "**> creating virtualenv"
virtualenv .env
fi
. .env/bin/activate
pip install nose
[jenkins] $ /bin/sh -xe /tmp/hudson1911070164953575306.sh
+ echo
+ cd
+ pwd
/var/lib/jenkins
+ [ -d .env ]
+ echo **> virtualenv exists
**> virtualenv exists
+ . .env/bin/activate
+ deactivate nondestructive
Environment:
Jenkins 1.429
Project:
Jenkins
Labels:
jenkins
Priority:
Major
Reporter:
Russell Keeton
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-16018) Not all builds show in the build history dashboard on job
William Lichtenberger created JENKINS-16018 Not all builds show in the build history dashboard on job Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 03/Dec/12 3:12 PM Description: All of the builds that are present on disk do not show up in the 'Build History' in the latest jenkins. I noticed the problem happening where only the last build or last couple builds would show up with the newest version (1.492). I then decided to go back to the latest stable version (1.480.1) to see if that solved the problem. The problem again occurred. I had only build 11 showing for my job, and I rolled back all the way to 1.455, a known stable version. All 11 builds showed back up in the build history. Environment: Windows Server 2008 R2 Enterprise Project: Jenkins Labels: builds history Priority: Critical Reporter: William Lichtenberger 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-16019) Copy Artifact Plugin isn't copying the "last successful" correctly
Ben Douglas created JENKINS-16019 Copy Artifact Plugin isn't copying the "last successful" correctly Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: copyartifact Created: 03/Dec/12 3:15 PM Description: We have a job setup to copy the "Latest successful" build (tried with stable, and without stable). Our last job failed, and the plugin couldn't find the module artifact correctly. We're using the Job/package.path$module format and getting the error: "Unable to find a build for artifact copy from: Job/package.path$module/". We do have a build from Friday 11/30 that successfully built, and one from this morning (12/3) that failed. Project: Jenkins Priority: Critical Reporter: Ben Douglas 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-15792) jnidispatch (/com/sun/jna/linux-ppc64/libjnidispatch.so) not found in resource path
Matt Riedemann updated JENKINS-15792 jnidispatch (/com/sun/jna/linux-ppc64/libjnidispatch.so) not found in resource path Changing severity as I'm able to produce ppc64 builds using our ppc64 box as a slave where the Jenkins server is running on our x86 server. Change By: Matt Riedemann (03/Dec/12 3:41 PM) Priority: Blocker Minor 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-15367) Jenkins kicks off the wrong downstream builds for Maven
Jesse Glick assigned JENKINS-15367 to olamy Jenkins kicks off the wrong downstream builds for Maven Should this now be resolved as fixed? Change By: Jesse Glick (03/Dec/12 4:05 PM) Assignee: Kohsuke Kawaguchi olamy 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-15367) Jenkins kicks off the wrong downstream builds for Maven
olamy commented on JENKINS-15367 Jenkins kicks off the wrong downstream builds for Maven It looks yes. I didn't notice more complain 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-15367) Jenkins kicks off the wrong downstream builds for Maven
Erik Riemers commented on JENKINS-15367 Jenkins kicks off the wrong downstream builds for Maven Seems to have done it on our end. Had no complaints either. 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-16020) Changelog no longer lists summaries.
Andrew Kujtan created JENKINS-16020 Changelog no longer lists summaries. Issue Type: Bug Affects Versions: current Assignee: Unassigned Attachments: changelog.png, changelog.xml Components: subversion Created: 03/Dec/12 4:48 PM Description: The changelog does not seem to list the summaries anymore. It is just a link to the details which then has the summaries and the changeset as seen in the attachment. I've also included the corresponding changelog.xml from the Dec 3 build in the image. Environment: Win7x64 Project: Jenkins Priority: Major Reporter: Andrew Kujtan 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-6604) Possible race condition in RemoteClassLoader renders slave unusable
Jesse Glick resolved JENKINS-6604 as Fixed Possible race condition in RemoteClassLoader renders slave unusable With @olamy’s integration, should now be fixed. Change By: Jesse Glick (03/Dec/12 4:52 PM) 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-16014) losing build history in configuration matrix jobs
Bertrand Latinville commented on JENKINS-16014 losing build history in configuration matrix jobs I'm facing a similar issue when adding configurations to existing matrix job. Here is the details of the issue as reported on the mailing list. I have made some changes in matrix jobs. I have added new configuration to a user defined axis. The matrix job run properly and I could see that new configuration was build properly : The parent jobs console log says " newconfiguation completed with result SUCCESS" I can go to the the new configuration web page, see the logs and the artifacts. Looking at the matrix, the bullet corresponding to the new configuration is blue ! After some time ( less than 2 hours) the result from the build is lost. The bullet corresponding to the new configuration is grey and indicates NOT RUN when I pass the mouse over it. So I cannot click on the bullet to see the build. If I go back to the parent job console, I can click on the "newconfiguation completed with result SUCCESS" link. I get a web page, where everything is empty : no Build History, empty change log, no artifacts. I run the job again . Can see the newconfiguration build. Some hours later , everything is gone again. Looking on the master node , in /va/lib/jenkins/jobs, I can see /var/lib/jenkins/jobs/job_name/configurations/../axis-xxx/newconfiguration/ I this folder everything looks fine : "builds config.xml lastStable lastSuccessful" In lastSuccessful I can see the log, the build.xml. Cf this topic on the mailing list: https://groups.google.com/forum/#!topic/jenkinsci-users/uBdlIp69uhQ 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-16005) CommandInstaller assumes write access to installation directory
Jesse Glick updated JENKINS-16005 CommandInstaller assumes write access to installation directory The bug is actually in CommandInstaller.performInstallation, which assumes that it can use the tool home as a temporary directory—which is normally a safe assumption, but not when sudo or the like is being used to create files. Should just use the system temp directory. Change By: Jesse Glick (03/Dec/12 4:57 PM) Summary: Mercurial plugin CommandInstaller assumes write access to installation directory Component/s: core Component/s: mercurial 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-16011) Add a global view
wolfs resolved JENKINS-16011 as Not A Defect Add a global view There is already a global view. Go to the all view in your Jenkins with all projects and click on dependency graph. If you need something different please reopen. Change By: wolfs (03/Dec/12 5:01 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
[JIRA] (JENKINS-15367) Jenkins kicks off the wrong downstream builds for Maven
Jay Meyer resolved JENKINS-15367 as Fixed Jenkins kicks off the wrong downstream builds for Maven Fixed in 1.492. I have not verified this myself, but I trust the word of others who have verified this. I have scheduled to try this on my builds the week of Dec-10. If it fails again, I will re-open this issue with the details of the failure. Change By: Jay Meyer (03/Dec/12 5:01 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-16005) CommandInstaller assumes write access to installation directory
Jesse Glick commented on JENKINS-16005 CommandInstaller assumes write access to installation directory If you click Install automatically then Installation directory disappears so I am not sure why you have it set—Installation directory only makes sense if you are not having Jenkins perform the installation. It is Tool Home which should be set to /usr (or just set Executable to /usr/bin/hg and leave Tool Home blank). 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-16005) CommandInstaller assumes write access to installation directory
Jesse Glick updated JENKINS-16005 CommandInstaller assumes write access to installation directory Change By: Jesse Glick (03/Dec/12 5:07 PM) Priority: Major Minor 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-15466) Fatal Error No Class Definition found for Kernel32
Jesse Glick commented on JENKINS-15466 Fatal Error No Class Definition found for Kernel32 @pjdarton: best to submit a pull request—gets more visibility, more easily reviewed. Anyway your patch would not apply against current trunk, needs a bit of an update. 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-16005) CommandInstaller assumes write access to installation directory
cowwoc commented on JENKINS-16005 CommandInstaller assumes write access to installation directory >If you click Install automatically then Installation directory disappears so I am not sure why you have it set I am using Hudson 1.492 and this isn't the case. Selecting "install automatically" does not cause the "installation directory" field to become hidden. Should I file an additional bug report for this? 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-16011) Add a global view
mat007 edited a comment on JENKINS-16011 Add a global view I don't see a "Dependency Graph" entry in the menu for the 'all' view (which btw is in French for some reason 'tous' if that matters), I need to click on a project first. Also I just noticed that some projects don't have it either, is it supposed to be there for all projects ? 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-16011) Add a global view
mat007 commented on JENKINS-16011 Add a global view I don't see a "Dependency Graph" entry in the menu for the 'all' view (which btw is in French for some reason 'tous' if that matters), I need to click on a project first. Also I just noticed that some projects don't have it neither, is it supposed to be there for all projects ? 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-15466) Fatal Error No Class Definition found for Kernel32
pjdarton
commented on JENKINS-15466
Fatal Error No Class Definition found for Kernel32
The patch I uploaded was written against 1.480.1 (the LTS branch /stable), not against the bleeding edge code, hence I wouldn't be surprised if it doesn't apply directly.
One would hope that this sort of bug would be fixed in the LTS build as well (as that's what I'm running, and I found this JIRA by googling against the error I was seeing!).
The patch itself is dead trivial and probably easier for someone with commit-rights to hand-craft the code instead of doing a patch - just surround the call to Kernel32Utils in a try/catch, catch NoClassDefFoundError and ignore it, allowing execution to continue on to the general case.
i.e. replace
return Kernel32Utils.isJunctionOrSymlink(file);
with
try {
return Kernel32Utils.isJunctionOrSymlink(file);
} catch (NoClassDefFoundError ex) {
/*
* Kernel32 does not load reliably.
* If it fails, fall through to the manual method.
*/
}
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-16011) Add a global view
wolfs commented on JENKINS-16011 Add a global view In my installation it is there on the all view and on all projects. Do you see some errors in the log? 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-16011) Add a global view
mat007 commented on JENKINS-16011 Add a global view All right I had installed the plugin without restarting jenkins, now that I did that everything seems to be working fine. Sorry for the noise. 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-16011) Add a global view
wolfs closed JENKINS-16011 as Not A Defect Add a global view Change By: wolfs (03/Dec/12 6:05 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-10832) make testng reporter-output field viewable from testng-plugin generated reports
Dan Alvizu commented on JENKINS-10832 make testng reporter-output field viewable from testng-plugin generated reports Pull request for fix: https://github.com/jenkinsci/testng-plugin-plugin/pull/10 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-16021) Use Jenkins' Internal Database Users already working PLUS new Active Directory ones
Leroy Jenkins created JENKINS-16021 Use Jenkins' Internal Database Users already working PLUS new Active Directory ones Issue Type: Improvement Assignee: Unassigned Components: active-directory Created: 03/Dec/12 6:31 PM Description: We have users in the jenkins internal database in production enviroment, now we need to use Active Directory users and keep the already created users working. Is that possible? Tests in another enviroment showed us that isn't, but we are not sure. We created the 'admin' user with full permission and after activating de active directory this 'admin' could not log on the system. Is there a way to mix the internal database with active directory? Due Date: 03/Dec/12 12:00 AM Project: Jenkins Priority: Critical Reporter: Leroy Jenkins 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-16014) losing build history in configuration matrix jobs
abayer resolved JENKINS-16014 as Duplicate losing build history in configuration matrix jobs Change By: abayer (03/Dec/12 6:38 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-15976) Provided maven settings.xml in maven builder is lost
domi commented on JENKINS-15976 Provided maven settings.xml in maven builder is lost ok, thanks - now I'm able to reproduce it. but I need to dig a bit deeper to solve this... 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-14475) Conditional build steps should be available as post-build actions
owenmehegan commented on JENKINS-14475 Conditional build steps should be available as post-build actions emszpak: No, I ended up using the PostBuildScript plugin (https://wiki.jenkins-ci.org/display/JENKINS/PostBuildScript+Plugin) to trigger Conditional Build Step in a post-build action. It's really ugly, I wish Conditional Build Step worked in post-build natively. But this works. 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-16005) CommandInstaller assumes write access to installation directory
Jesse Glick commented on JENKINS-16005 CommandInstaller assumes write access to installation directory It worked when I tried in 1.424 (baseline for the plugin), so if it is not working in 1.492 then that sounds like a regression which ought to be filed. 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-16022) "Install Automatically" does not hide "Installation Directory" field
cowwoc created JENKINS-16022 "Install Automatically" does not hide "Installation Directory" field Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 03/Dec/12 7:37 PM Description: When "Install automatically" is selected for the Mercurial tool, the field "Installation directory" is supposed to disappear, but in Jenkins 1.492 it does not. According to Jesse Glick this used to work under version 1.424 so this is a possible regression. Project: Jenkins Priority: Major Reporter: cowwoc 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-16005) CommandInstaller assumes write access to installation directory
cowwoc commented on JENKINS-16005 CommandInstaller assumes write access to installation directory Filed JENKINS-16022. 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-15466) Fatal Error No Class Definition found for Kernel32
Jesse Glick commented on JENKINS-15466 Fatal Error No Class Definition found for Kernel32 Can someone encountering this bug on 1.487+ (i.e. with 7e8bf72) please confirm that the original error (including the UnsatisfiedLinkError message) is printed somewhere in the Jenkins log file, under the Failed to load Kernel32 heading? If so, silently catching NoClassDefFoundError as @pjdarton proposes should suffice; otherwise some additional logging work needs to be done. 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-15156) Builds Disappear from Build History after Completion
Christian Köberl commented on JENKINS-15156 Builds Disappear from Build History after Completion We have the same issue with 1.489. Restarting or reloading config from disk fixes this temporarily. Build history gets lost eventually after the next build. We have master/slave setup with 3 slaves executing jobs (all machines on Linux SLES) 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-16023) Lazy loading causes massive delays after a period of inactivity when loading job tabs
johno created JENKINS-16023 Lazy loading causes massive delays after a period of inactivity when loading job tabs Issue Type: Bug Assignee: Unassigned Components: core Created: 03/Dec/12 8:36 PM Description: Handling GET /hudson-rc/ : http-10080-21 java.io.UnixFileSystem.getBooleanAttributes0(Native Method) java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228) java.io.File.exists(File.java:733) hudson.model.RunMap.retrieve(RunMap.java:217) hudson.model.RunMap.retrieve(RunMap.java:59) jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:601) jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:344) hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:103) hudson.model.Job.getLastFailedBuild(Job.java:780) sun.reflect.GeneratedMethodAccessor139.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:597) org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134) org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81) org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:146) org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150) org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150) org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) org.kohsuke.stapler.jelly.groovy.JellyBuilder.doInvokeMethod(JellyBuilder.java:283) org.kohsuke.stapler.jelly.groovy.Namespace$ProxyImpl.invoke(Namespace.java:92) $Proxy58.projectView(Unknown Source) lib.JenkinsTagLib$projectView.call(Unknown Source) org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42) org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108) org.codeha
[JIRA] (JENKINS-13536) File parameter causing data lost after Jenkins restart
Jesse Glick assigned JENKINS-13536 to Jesse Glick File parameter causing data lost after Jenkins restart Change By: Jesse Glick (03/Dec/12 9:13 PM) Assignee: Jesse Glick 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-13536) File parameter causing data lost after Jenkins restart
Jesse Glick commented on JENKINS-13536 File parameter causing data lost after Jenkins restart Reproduced more simply: create job add file parameter, name irrelevant build job specify any file shut down Jenkins see that build.xml contains a filename in /tmp; delete it restart Jenkins 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-16023) Lazy loading causes massive delays after a period of inactivity when loading job tabs
johno updated JENKINS-16023 Lazy loading causes massive delays after a period of inactivity when loading job tabs Change By: johno (03/Dec/12 9:26 PM) Description: " Handling GET /hudson-rc/ : http-10080-21 " daemon prio=5 tid=1094 RUNNABLE at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228) Local Variable: java.io.File #1653 at java . io.File. exists(File.java:733) at hudson.model.RunMap.retrieve(RunMap.java:217) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) Local Variable: java.io.File#1654 at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:601) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:344) Local Variable: hudson.model. RunMap#107 Local Variable: jenkins.model.lazy.AbstractLazyLoadRunMap$Direction#1 Local Variable: java.util.TreeMap$Entry#76935 at hudson.model. AbstractBuild.getPreviousBuild(AbstractBuild.java:210) Local Variable: hudson.model. FreeStyleBuild#215 at hudson.model. AbstractBuild.getPreviousBuild(AbstractBuild.java:103) at hudson.model.Job.getLastFailedBuild(Job.java:780) at sun.reflect.GeneratedMethodAccessor139.invoke( Unknown Source ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) Local Variable: org.apache.commons.jexl.parser.ASTReference #2352 at org . apache.commons.jexl.parser.ASTReference. value(ASTReference.java:57) at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) Local Variable: org.apache.commons.jexl.ExpressionImpl#1862 Local Variable: hudson.ExpressionFactory2$ JellyJexlContext#1 at hudson.ExpressionFactory2$ JexlExpression.evaluate(ExpressionFactory2.java:72) Local Variable: hudson.ExpressionFactory2$JexlExpression#1862 at org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134) Local Variable: org.apache.commons.jelly. tags.core.CoreTagLibrary$3#164 Local Variable: java.lang.String#347180 at org.apache.commons.jelly. impl.ScriptBlock.run(ScriptBlock.java:95) Local Variable: java.util.AbstractList$Itr#6 Local Variable: org.apache.commons.jelly. JellyContext#1 at org.apache.commons.jelly. tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81) at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:146) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) Local Variable: java.net.URL#11160 Local Variable: org.apache.commons.jelly. impl.TagScript#941 at org.apache.commons.jelly. TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150) Local Variable: hudson.util.CopyOnWriteList$1#1 Local Variable: org.apache.commons.jelly. tags.core.ForEachTag#2 at org.apache.commons.jelly. impl.TagScript.run(TagScript.java:269) Local Variable: java.net.URL#11163 Local Variable: org.apache.commons.jelly.impl. TagScript#940 at org.apache.commons.jelly.impl. ScriptBlock.run(ScriptBlock.java:95) Local Variable: java.util.AbstractList$Itr#7 Local Variable: org. apache.commons.jelly.JellyContext#2 at org. kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) Local Variable: org. kohsuke.stapler.jelly.ReallyStaticTagLibrary$1#1253 at org. apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
[JIRA] (JENKINS-16023) Lazy loading causes massive delays after a period of inactivity when loading job tabs
johno updated JENKINS-16023 Lazy loading causes massive delays after a period of inactivity when loading job tabs Change By: johno (03/Dec/12 9:34 PM) Attachment: stacktrace.txt Description: "Handling GET /hudson-rc/ : http-10080-21" daemon prio=5 tid=1094 RUNNABLE at java See attached stacktrace . io.UnixFileSystem.getBooleanAttributes0(Native Method) at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228) Local Variable: java.io.File#1653 at java.io.File.exists(File.java:733) at hudson.model.RunMap.retrieve(RunMap.java:217) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) Local Variable: java.io.File#1654 at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:601) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:344) Local Variable: hudson.model.RunMap#107 Local Variable: jenkins.model.lazy.AbstractLazyLoadRunMap$Direction#1 Local Variable: java.util.TreeMap$Entry#76935 at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) Local Variable: hudson.model.FreeStyleBuild#215 at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:103) at hudson.model.Job.getLastFailedBuild(Job.java:780) at sun.reflect.GeneratedMethodAccessor139.invoke() at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) Local Variable: org.apache.commons.jexl.parser.ASTReference#2352 at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) Local Variable: org.apache.commons.jexl.ExpressionImpl#1862 Local Variable: hudson.ExpressionFactory2$JellyJexlContext#1 at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) Local Variable: hudson.ExpressionFactory2$JexlExpression#1862 at org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134) Local Variable: org.apache.commons.jelly.tags.core.CoreTagLibrary$3#164 Local Variable: java.lang.String#347180 at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) Local Variable: java.util.AbstractList$Itr#6 Local Variable: org.apache.commons.jelly.JellyContext#1 at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81) at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:146) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) Local Variable: java.net.URL#11160 Local Variable: org.apache.commons.jelly.impl.TagScript#941 at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150) Local Variable: hudson.util.CopyOnWriteList$1#1 Local Variable: org.apache.commons.jelly.tags.core.ForEachTag#2 at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) Local Variable: java.net.URL#11163 Local Variable: org.apache.commons.jelly.impl.TagScript#940 at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) Local Variable: java.util.AbstractList$Itr#7 Local Variable: org.apache.commons.jelly.JellyContext#2 at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) Local Variable: org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1#1253 at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at
[JIRA] (JENKINS-16023) Lazy loading causes massive delays after a period of inactivity when loading job tabs
johno updated JENKINS-16023 Lazy loading causes massive delays after a period of inactivity when loading job tabs Change By: johno (03/Dec/12 9:34 PM) Description: See Please see attached stacktrace. 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-13536) File parameter causing data lost after Jenkins restart
Jesse Glick
commented on JENKINS-13536
File parameter causing data lost after Jenkins restart
Have not figured out how to reproduce in a functional test. Starting with
ParametersDefinitionProperty pdp = new ParametersDef
FreeStyleProject p = j.createFreeStyleProject();
p.addProperty(pdp);
p.save();
File f = new File(j.createTmpDir(), "stuff");
FileUtils.writeStringToFile(f, "some stuff here\n");
it is not clear how to proceed.
p.scheduleBuild2(0, null, new ParametersAction(new FileParameterValue("stuff", f, "stuff")));
is the obvious approach but this would be using FileParameterValue.FileItemImpl which bypasses the actual bug.
Using HtmlUnit (WebRequestSettings, HtmlPage, HtmlForm, HtmlFileInput) would closely follow the user workflow but loading the initial form fails due to crumb issues.
curl -F file=@/tmp/… -Fjson='{"parameter": {"name": "file", "file": "file"}}' 'http://localhost:8080/job/…/build?delay=0sec'
works from the command line but HttpUnit is not currently available in jenkins/test so there is no apparent way to directly simulate this.
For now will just have to verify fix manually.
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-16024) SCM Sync fails to check in any files
Joe Delfino created JENKINS-16024 SCM Sync fails to check in any files Issue Type: Bug Affects Versions: current Assignee: Frédéric Camblor Components: scm-sync-configuration Created: 03/Dec/12 10:51 PM Description: I installed the SCM Sync Configuration plugin, but it never synced any configuration. The log shows many messages like these: Dec 03, 2012 10:38:00 PM hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness queueChangeSet INFO: Queue of changeset A hudson.scm.SubversionSCM.xml A hudson.maven.MavenModuleSet.xml A config.xml A hudson.tasks.Ant.xml A hudson.tasks.Maven.xml A hudson.tasks.Shell.xml A hudson.triggers.SCMTrigger.xml A scm-sync-configuration.xml A hudson.scm.CVSSCM.xml A hudson.tasks.Mailer.xml aborted (scm manipulator not settled !) Dec 03, 2012 10:32:57 PM hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness queueChangeSet INFO: Queue of changeset A jobs/en_libraries_build/promotions/Push to pypi/config.xml A jobs/en_libraries_build/config.xml aborted (scm manipulator not settled !) The plugin has been installed for several days, and still has not synced anything. I'm not sure where to look for more information on this error (why isn't the manipulator settled? what does that mean?). I am able to check out svn directories from other jobs. It even properly warns me when I enter a SVN directory that doesn't exist into the 'Repository URL' box in the 'SCM Sync Configuration' section under 'Manage Jenkins'. Also, I have successfully checked in changes by hand to the target directory with the credentials being used, so I know the svn user has the correct read and write permissions to SVN. I tried the plugin on a fresh Jenkins install at v1.492, and it worked. Are there known version incompatibilities? For various reasons, upgrading the v1.460 Jenkins installation in question will be difficult (but not impossible), so I'd like to avoid that unless there is some reason to believe it will fix the problem. Thanks for your time! Environment: Jenkins v1.460, linux, SCM Sync v0.0.6 Project: Jenkins Priority: Major Reporter: Joe Delfino 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-15898) Subversion back-end cannot handle renaming of jobs
Joe Delfino commented on JENKINS-15898 Subversion back-end cannot handle renaming of jobs Additionally, I have a Jenkins instance running v1.484 that is also exhibiting the same symptoms. 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-15898) Subversion back-end cannot handle renaming of jobs
Joe Delfino edited a comment on JENKINS-15898 Subversion back-end cannot handle renaming of jobs (sorry, accidentally commented on the wrong 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-16024) SCM Sync fails to check in any files
Joe Delfino commented on JENKINS-16024 SCM Sync fails to check in any files Additionally, I have a Jenkins instance running v1.484 that is exhibiting the same symptoms. 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-13536) File parameter causing data lost after Jenkins restart
dogfood commented on JENKINS-13536 File parameter causing data lost after Jenkins restart Integrated in jenkins_main_trunk #2121 [FIXED JENKINS-13536] Using file parameters could cause build records to not load. (Revision 4dde24e62037439b7b73addd7cefae83a254eb3c) Result = SUCCESS Jesse Glick : 4dde24e62037439b7b73addd7cefae83a254eb3c Files : changelog.html core/src/main/java/hudson/model/FileParameterValue.java 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-15808) CVS plugin 2.0-2.7 breaks Gerrit Trigger (v2.5.2 and 2.6.0) configuration
Andrew Erickson commented on JENKINS-15808 CVS plugin 2.0-2.7 breaks Gerrit Trigger (v2.5.2 and 2.6.0) configuration You need to use the job config I attached. Jobs that don't use Gerrit Trigger appear to be fine. If you click 'apply' before clicking save the error doesn't occur. Something that buildFormTree does fixes the invalid form structure. 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-14473) Jenkins server memory leak
Anoop Karollil commented on JENKINS-14473 Jenkins server memory leak Thanks Liya. I did see a few weeks ago (memory usage crept up to 5gigs of RAM), but things have been okay the past week with 1.491 - upgraded to 1.492 anyway. Hopefully this has been resolved - I will close this bug once I am sure. 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-16025) Allow full path when uploading a file
wizard113 created JENKINS-16025 Allow full path when uploading a file Issue Type: New Feature Assignee: Michael Watt Components: s3 Created: 04/Dec/12 12:15 AM Description: The S3 plugin currently uploads a file with the key set equal to the base filename that is returned by the matcher. I would like to upload files with a key of the path that is returned by the matcher, i.e. if I have a matcher of 'el/**', and several files underneath, I would like to see the following keys in the S3 bucket: el/noarch/file1.txt el/some/path/file2.c el/some/other/path/file3.java el/afile el/readme and so on. Project: Jenkins Priority: Minor Reporter: wizard113 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-16026) Success build record lose after restart of Jenkins service
reeve lau updated JENKINS-16026 Success build record lose after restart of Jenkins service Change By: reeve lau (04/Dec/12 2:35 AM) Description: The reporting part of this plugin is really attractive and easy to understand. Since I need to setup both klocwork plug in both win and linux node, I need to maintain the "kwbuildproj" in my own ant script. So I setup a free-style job to trigger my ant build. The ant build will handle all klocwork related commands, "kwadmin", "kwinject", "kwbuildproject" and "kwinspectreport".After the ant script is done, a klocwork-result.xml is produced. The "Post-build Actions: Publish Klocwork test result report" capture the xml and show the report nicely on the build page. But after restart of Jenkins service, all the successful build of the job will be lost.I guess (without evident evidence ), there is some persistent structure has to be created in Jenkins build record to store the Klocwork report. Somehow, this structure doesn't get created with only executing the "Post build action". 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-16026) Success build record lose after restart of Jenkins service
reeve lau updated JENKINS-16026 Success build record lose after restart of Jenkins service Change By: reeve lau (04/Dec/12 2:34 AM) Summary: Success build record lose after restart restart or of Jenkins service 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-16026) Success build record lose after restart restart or Jenkins service
reeve lau created JENKINS-16026 Success build record lose after restart restart or Jenkins service Issue Type: Bug Affects Versions: current Assignee: Gregory Boissinot Components: klocwork Created: 04/Dec/12 2:34 AM Description: The reporting part of this plugin is really attractive and easy to understand. Since I need to setup both klocwork plug in both win and linux node, I need to maintain the "kwbuildproj" in my own ant script. So I setup a free-style job to trigger my ant build. The ant build will handle all klocwork related commands, "kwadmin", "kwinject", "kwbuildproject" and "kwinspectreport". After the ant script is done, a klocwork-result.xml is produced. The "Post-build Actions: Publish Klocwork test result report" capture the xml and show the report nicely on the build page. But after restart of Jenkins service, all the successful build of the job will be lost. I guess (without evident), there is some persistent structure has to be created in Jenkins build record to store the Klocwork report. Somehow, this structure doesn't get created with only executing the "Post build action". Environment: Jenkins ver. 1.466.2 Klocwork Plugin 1.14 Jenknis Host Server, Red Hat 4.4.6-4 Slave: Windows 7 Klocwork Server 9.5 SR1 Project: Jenkins Labels: plugin Priority: Major Reporter: reeve lau 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-16007) Weblogic Deploy periodically not working
Ye Gaung commented on JENKINS-16007 Weblogic Deploy periodically not working For me, "Deployment policy" selection is seem like never work. Because I tried out for the following option but deployment never do and it say the plug-in execution is disabled on console. 1. "Deploy Periodically" option 2. "Built by user" option 3. "Build periodically" option 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-9292) Provide an option for deleting extra volumes produced by terminated ec2 instances
Craig Ringer commented on JENKINS-9292 Provide an option for deleting extra volumes produced by terminated ec2 instances Really, Jenkins should be setting the EBS "delete on terminate" flag on the instance root volume. That way this issue won't arise. 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-16027) Jenkins fails to create remote FS root if it doesn't exist, at least on EC2
Craig Ringer created JENKINS-16027 Jenkins fails to create remote FS root if it doesn't exist, at least on EC2 Issue Type: Bug Affects Versions: current Assignee: Francis Upton Components: ec2, slave-setup Created: 04/Dec/12 5:37 AM Description: On Jenkins 1.492, EC2 1.17, when I launch an instance that has a custom Remote FS root set in the EC2 plugin configuration for the AMI, the root isn't created. If I set the remote cache root to /var/cache/jenkins/ on an EC2-launched Debian instance, for example, I get the error: Verifying that java exists java full version "1.6.0_18-b18" Copying slave.jar Launching slave agent: java -jar /tmp/slave.jar <===[JENKINS REMOTING CAPACITY]===>Slave.jar version: 2.18 This is a Unix slave ERROR: Failed to copy /var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven-agent-1.2.jar to /var/cache/jenkins/maven-agent.jar hudson.util.IOException2: Failed to copy /var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven-agent-1.2.jar to /var/cache/jenkins/maven-agent.jar at hudson.FilePath.copyTo(FilePath.java:1650) at hudson.maven.MavenComputerListener.copyJar(MavenComputerListener.java:90) at hudson.maven.MavenComputerListener.preOnline(MavenComputerListener.java:57) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:368) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:316) at hudson.plugins.ec2.ssh.EC2UnixLauncher.launch(EC2UnixLauncher.java:134) at hudson.plugins.ec2.EC2ComputerLauncher.launch(EC2ComputerLauncher.java:57) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:199) 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:636) Caused by: java.io.FileNotFoundException: /var/cache/jenkins/maven-agent.jar (No such file or directory) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.(FileOutputStream.java:209) at java.io.FileOutputStream.(FileOutputStream.java:160) at hudson.FilePath$28.call(FilePath.java:1558) at hudson.FilePath$28.call(FilePath.java:1554) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) ... 5 more ERROR: Connection terminated java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2570) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1314) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368) at hudson.remoting.Command.readFrom(Command.java:90) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) Project: Jenkins Priority: Major Reporter: Craig Ringer 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:
[JIRA] (JENKINS-16027) Jenkins fails to create remote FS root if it doesn't exist, at least on EC2
Craig Ringer commented on JENKINS-16027 Jenkins fails to create remote FS root if it doesn't exist, at least on EC2 If I: sudo mkdir /var/cache/jenkins sudo chown admin /var/cache/jenkins to create the working dir and grant ownership to the user the slave runs as, then re-launch the slave, it works. It looks like the EC2 plugin needs to create the working directory using the sudo command prefix and then set its ownership before proceeding. 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-16027) Jenkins fails to create remote FS root if it doesn't exist, at least on EC2
Craig Ringer edited a comment on JENKINS-16027 Jenkins fails to create remote FS root if it doesn't exist, at least on EC2 If I: sudo mkdir /var/cache/jenkins sudo chown admin /var/cache/jenkins to create the working dir and grant ownership to the user the slave runs as, then re-launch the slave, it works. It looks like the EC2 plugin needs to create the working directory using the sudo command prefix and then set its ownership before proceeding. 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-16028) COPYARTIFACT_BUILD_NUMBER_ is not set when copyartifact plugin is ran as Maven pre-build
Adam Rofer created JENKINS-16028 COPYARTIFACT_BUILD_NUMBER_ is not set when copyartifact plugin is ran as Maven pre-build Issue Type: Bug Assignee: Unassigned Components: copyartifact Created: 04/Dec/12 5:42 AM Description: Create a freestyle build with 2 steps: Copy artifacts from another project (pick a random project and filename, set it to optional, Latest successful build) Execute Shell (contents: "set" - should work on windows/unix) RESULT: Shows COPYARTIFACT_BUILD_NUMBER_(project name) set as described Create a maven build with 2 pre-build steps: Copy artifacts from another project (pick a random project and filename, set it to optional, Latest successful build) Execute Shell (contents: "set" - should work on windows/unix) RESULT: DOES NOT SHOW COPYARTIFACT_BUILD_NUMBER_(project name) Set! Hopefully this is an easy and quick fix...thanks! Environment: Jenkins 1.492, Copy Artifact Plugin 1.25 Project: Jenkins Priority: Major Reporter: Adam Rofer 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
