[JIRA] (JENKINS-11509) maven release plugin does not allow to set the pom file used
[ https://issues.jenkins-ci.org/browse/JENKINS-11509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Burmeister reopened JENKINS-11509: Actually this ticket must be reopened, because I'm facing the same error now with Jenkins version 1.454, Plugin version 0.9.1 and Maven 3.0.4. There is no option to set the pom-name (-f option) for the release:prepare/perform and the normal maven configuration is not used within releases. Any ideas? I have a project with multiple poms in the same directory, so I have to give different names for them. maven release plugin does not allow to set the pom file used Key: JENKINS-11509 URL: https://issues.jenkins-ci.org/browse/JENKINS-11509 Project: Jenkins Issue Type: Improvement Components: m2release Reporter: Sedat Guclu Assignee: teilo The m2-release-plugin does not allow to define the pom file name and location as it is possible in a standard maven-type job. It is blocking for some of projects because the pom.xml file is not always located at the job's root directory (dotnet project with solution files located in subdirectories). An option to set the location (with the default pom.xml value) would be nice... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162593#comment-162593 ] Jan Klass commented on JENKINS-11381: - On my RC1 problem: SVN version is 1.7 as well (thought you wanted a more specific version). Just as working copy format in global configuration, which is 1.7 as well. Will try out the new RC. Subversion Plugin does not support Subversion 1.7 - Key: JENKINS-11381 URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 Project: Jenkins Issue Type: Improvement Components: subversion Reporter: soundworker Priority: Blocker Attachments: subversion.hpi, subversion.hpi, subversion.hpi -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162593#comment-162593 ] Jan Klass edited comment on JENKINS-11381 at 5/9/12 7:07 AM: - On my RC1 problem: SVN version is 1.7 as well (thought you wanted a more specific version). Just as working copy format in global configuration, which is 1.7 as well. Accessed via svn protocol. Will try out the new RC. was (Author: jk): On my RC1 problem: SVN version is 1.7 as well (thought you wanted a more specific version). Just as working copy format in global configuration, which is 1.7 as well. Will try out the new RC. Subversion Plugin does not support Subversion 1.7 - Key: JENKINS-11381 URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 Project: Jenkins Issue Type: Improvement Components: subversion Reporter: soundworker Priority: Blocker Attachments: subversion.hpi, subversion.hpi, subversion.hpi -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13718) Plugin status of modules is not propagated to parent module
Ulli Hafner created JENKINS-13718: - Summary: Plugin status of modules is not propagated to parent module Key: JENKINS-13718 URL: https://issues.jenkins-ci.org/browse/JENKINS-13718 Project: Jenkins Issue Type: Bug Components: analysis-core Reporter: Ulli Hafner Assignee: Ulli Hafner For multi/module maven projects the plug/in status is not evaluated correctly. E.g. if parent consists of module A and B, and A contains a new warning, then the new warnings failure is shown for that module but not for the master. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12854) Large Artifacts can not be downloaded over WebInterface
[ https://issues.jenkins-ci.org/browse/JENKINS-12854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] lloydchang reassigned JENKINS-12854: Assignee: lloydchang Large Artifacts can not be downloaded over WebInterface --- Key: JENKINS-12854 URL: https://issues.jenkins-ci.org/browse/JENKINS-12854 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Server: Win XP SP3 32-Bit Jenkins 1.451 Client: Win XP SP3 32- Bit Browser: Firefox 10.0.2 Reporter: Andre Gross Assignee: lloydchang Attachments: jenkins.err.log I create an ISO which is around 3GB. When I try to access it through the web interface I get the following error in FireFox: Die Dateien unter http://wxde423hc4jw:8080/job/600_CreateSoMachineISO/lastSuccessfulBuild/artifact/SoMachine-3.1.1-12.02.22.03.iso konnten nicht gefunden werden. It says something like File not found. I also attached the jenkins error log which shows an exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12854) Large Artifacts can not be downloaded over WebInterface
[ https://issues.jenkins-ci.org/browse/JENKINS-12854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] lloydchang resolved JENKINS-12854. -- Assignee: Andre Gross (was: lloydchang) Fix Version/s: current Resolution: Fixed Code Reviewed and Merged Andre Gross' pull request via commit at https://github.com/jenkinsci/winstone/commit/e462d03fdab858742653e30a187b28fc79656c96 GitHub transaction described at https://github.com/jenkinsci/winstone/pull/3 Large Artifacts can not be downloaded over WebInterface --- Key: JENKINS-12854 URL: https://issues.jenkins-ci.org/browse/JENKINS-12854 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Server: Win XP SP3 32-Bit Jenkins 1.451 Client: Win XP SP3 32- Bit Browser: Firefox 10.0.2 Reporter: Andre Gross Assignee: Andre Gross Fix For: current Attachments: jenkins.err.log I create an ISO which is around 3GB. When I try to access it through the web interface I get the following error in FireFox: Die Dateien unter http://wxde423hc4jw:8080/job/600_CreateSoMachineISO/lastSuccessfulBuild/artifact/SoMachine-3.1.1-12.02.22.03.iso konnten nicht gefunden werden. It says something like File not found. I also attached the jenkins error log which shows an exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8706) Can't download artefacts greater than or equal to 2GB, can't use file params greater than or equal to 2GB
[ https://issues.jenkins-ci.org/browse/JENKINS-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162595#comment-162595 ] OHTAKE Tomohiro commented on JENKINS-8706: -- Fixed in winstone. See JENKINS-12854. Can't download artefacts greater than or equal to 2GB, can't use file params greater than or equal to 2GB - Key: JENKINS-8706 URL: https://issues.jenkins-ci.org/browse/JENKINS-8706 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Windows XP Reporter: Paul M Priority: Blocker When an artefact is archived it can't be downloaded if its file size is =2GB. Steps for upload failure: 1. Setup a project that takes a file paremeter 2. Start a new build, it asks for a file to be uploaded 3. Select a file thats =2GB 4. The page 404's Steps for download failure: 1. Setup a project that archives artefacts 2. The actual build that causes this issue generates a huge zip file (about 2.5GB), the zip file is created using 7z NOT by Jenkins download as zip feature. 3. Attempt to download this using the URL at the end of the build, it will 404, yet the download as zip or the view link appears to work ok -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13352) Jenkins returns Error 6 (net::ERR_FILE_NOT_FOUND): The file or directory could not be found when trying to download artifacts 2GB
[ https://issues.jenkins-ci.org/browse/JENKINS-13352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] OHTAKE Tomohiro resolved JENKINS-13352. --- Resolution: Duplicate Fixed by JENKINS-12854. Jenkins returns Error 6 (net::ERR_FILE_NOT_FOUND): The file or directory could not be found when trying to download artifacts 2GB Key: JENKINS-13352 URL: https://issues.jenkins-ci.org/browse/JENKINS-13352 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Server Win2k8 - Jenkins ver. 1.455 and 1.457 (server has zero executors) Slave Win2k8 R2 - Slave ver. 2.12 (21 slaves) WebBrowser - Firefox 11.0 and Chrome 18.0.1025.142 m The build which is failing to archive artifacts is tied to a single slave. Reporter: Richard Taylor *** This issues appears to be that artifacts larger than 2GB can not be downloaded from Jenkins server *** We have started getting bad links to artifacts from some runs of our package build job. * The build completes with out error. * The artifacts are sucesfully copied back to the server. * The artifacts can be copied and verified ok using SMB drive share. * Any artifacts which are larger than 2GB will fail to download from the jenkins server. This web page has not been found Error 6 (net::ERR_FILE_NOT_FOUND): The file or directory could not be found. As a work around we are looking to split up the artifacts into multiple files but this is a less than ideal workflow. Thanks Richard. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-4998) Not possible to download artifacts larger than 2GB
[ https://issues.jenkins-ci.org/browse/JENKINS-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] OHTAKE Tomohiro resolved JENKINS-4998. -- Resolution: Duplicate JENKINS-12854 will resolve the issue. If not, please reopen. Not possible to download artifacts larger than 2GB -- Key: JENKINS-4998 URL: https://issues.jenkins-ci.org/browse/JENKINS-4998 Project: Jenkins Issue Type: Bug Components: core Environment: Tried on SUSE. Issue probably exists all other OSes too. Reporter: glundh It is not possible to download artifacts larger than 2GB. After a timeout, the user only receives a 0 byte file. This is course a huge issue for all environments delivering larger build artifacts. Issue discussed further here: http://n4.nabble.com/limit-on-artifact-size-td390948.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13007) Git plugin cannot find revision to build on Windows
[ https://issues.jenkins-ci.org/browse/JENKINS-13007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162598#comment-162598 ] Jens Reimann commented on JENKINS-13007: I got the same issue with the current 1.1.18 version and needed to downgrade to 1.1.12 (which was the last version for me). Git plugin cannot find revision to build on Windows --- Key: JENKINS-13007 URL: https://issues.jenkins-ci.org/browse/JENKINS-13007 Project: Jenkins Issue Type: Bug Components: git Environment: Windows 2008 Server 64 Bit NTFS Reporter: ritzmann Assignee: Nicolas De Loof Priority: Critical After we upgraded the Git plugin from 1.1.14 to 1.1.16, all our builds on Windows build slaves started failing like this: Started by user anonymous Building remotely on win-slave1 in workspace d:\hudson\workspace\my-app Checkout:my-app / d:\hudson\workspace\my-app - hudson.remoting.Channel@95ff886:win-slave1 Using strategy: Default Last Built Revision: Revision e00e2c1328a011ca99980e0ffd90f7534b34 (origin/master) Checkout:my-app / d:\hudson\workspace\my-app - hudson.remoting.LocalChannel@470a4b80 Fetching changes from 1 remote Git repository Fetching upstream changes from d:\hudson\shared\repo.git ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job. The builds on our Linux slaves are not affected. Wiping the workspaces on the Windows slaves did not help. Both clones and checkouts/updates seem to fail with the same error. Downgrading back to 1.1.14 made the Windows builds work again. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162600#comment-162600 ] Jan Klass commented on JENKINS-11381: - Thank you very much for your work, looking forward to the release! Subversion Plugin does not support Subversion 1.7 - Key: JENKINS-11381 URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 Project: Jenkins Issue Type: Improvement Components: subversion Reporter: soundworker Priority: Blocker Attachments: subversion.hpi, subversion.hpi, subversion.hpi -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9764) Fix wrong create-project instruction
[
https://issues.jenkins-ci.org/browse/JENKINS-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Kruse resolved JENKINS-9764.
-
Resolution: Fixed
Fix wrong create-project instruction
Key: JENKINS-9764
URL: https://issues.jenkins-ci.org/browse/JENKINS-9764
Project: Jenkins
Issue Type: Bug
Components: clearcase-ucm
Reporter: Lars Kruse
Assignee: Christian Wolfgang
Fix For: current
When PUCM creates the read-only branch for the stream and there is no
Hudson project available the stream is created in the current project
instead, and a warning is issued:'
{{*The build project was not found. You can create the project with:
cleartool mkproject -c Your special build Project -in
rootFolder@\your_pvob yourBuildProject@\your_pvob.*}}
{{*Since there's no build project in ClearCase, pucm have made an extra
stream in your integration stream to build in*}}
Problem is that this instruction is not correct:
If you create the UCM project named Hudson from the GUI you are OK, but if
you created it using the cleartool command above you will get a UCM project
without an integration stream, so it's not enough. you have to go something
like:
{color:green}{{cleartool mkproject -c Hudson project -in RootFolder@\[YOUR
PVOB] hudson@\[YOUR PVOB]}}
{{cleartool mkstream -int -in project:hudson@\[YOUR PVOB] hudson_int@\[YOUR
PVOB]}}
{color}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13719) CVS Updates are not reflected
Mitesh shah created JENKINS-13719: - Summary: CVS Updates are not reflected Key: JENKINS-13719 URL: https://issues.jenkins-ci.org/browse/JENKINS-13719 Project: Jenkins Issue Type: Bug Components: cvs Environment: Fedora -15 , 32-bit Reporter: Mitesh shah I used a Test Project in which I changed some files and committed into CVS(Set up on local machine). On cvs console it shows new revision number. But when I do build it doesn't show any changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10771) hudson.util.IOException2: remote file operation failed
[ https://issues.jenkins-ci.org/browse/JENKINS-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162601#comment-162601 ] Michael Pisula commented on JENKINS-10771: -- Since updating from 1.458 to 1.463 I am also having this problem. My master is running on debian, my slave on solaris. Reconnecting the slave did not work. There is enough disk space on the machine, and I am running jenkins standalone, so deleting the xerces-lib is not applicable. Would be really grateful if someone can help. Here is the exception in my case (the underlying NoClassDefFoundException can have other stacktraces) : hudson.util.IOException2: remote file operation failed: /export/home/jenkins/v2010_ci at hudson.remoting.Channel@1dc5322:xxx at hudson.FilePath.act(FilePath.java:828) at hudson.FilePath.act(FilePath.java:814) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685) at hudson.model.AbstractProject.checkout(AbstractProject.java:1218) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) at hudson.model.Run.run(Run.java:1434) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: java.io.IOException: Remote call on xxx failed at hudson.remoting.Channel.call(Channel.java:655) at hudson.FilePath.act(FilePath.java:821) ... 10 more Caused by: java.lang.NoClassDefFoundError at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:766) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676) at java.lang.Thread.run(Thread.java:595) hudson.util.IOException2: remote file operation failed -- Key: JENKINS-10771 URL: https://issues.jenkins-ci.org/browse/JENKINS-10771 Project: Jenkins Issue Type: Bug Components: master-slave Affects Versions: current Environment: node: Windows Server 2008 R2, amd64 - Intel64 Family 6 Model 15 Stepping 1, GenuineIntel, jvm 1.6.0_25-b06 master: AIX Reporter: Thorsten Löber After upgrading jenkins from 1.415 to 1.426 we cannot build anymore any project on our windows node. We get the exception: Building remotely on WSJENKINSDEV01 hudson.util.IOException2: remote file operation failed: d:\Program Files\jenkins_slave\workspace\TASC Workbench at hudson.remoting.Channel@4f854f85:WSJENKINSDEV01 at hudson.FilePath.act(FilePath.java:754) at hudson.FilePath.act(FilePath.java:740) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:731) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:676) at hudson.model.AbstractProject.checkout(AbstractProject.java:1193) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:555) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:443) at hudson.model.Run.run(Run.java:1376) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:230) Caused by: java.io.IOException: Remote call on WSJENKINSDEV01 failed at hudson.remoting.Channel.call(Channel.java:677) at hudson.FilePath.act(FilePath.java:747) ... 10 more Caused by: java.lang.NoClassDefFoundError: Could not initialize class hudson.model.Hudson at hudson.scm.SubversionWorkspaceSelector.syncWorkspaceFormatFromMaster(SubversionWorkspaceSelector.java:85) at hudson.scm.SubversionSCM.createSvnClientManager(SubversionSCM.java:808) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:751) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:738) at
[JIRA] (JENKINS-13720) The manifest branch, file other parameters should evaluate input parameters
Greg BOUGEARD created JENKINS-13720:
---
Summary: The manifest branch, file other parameters should
evaluate input parameters
Key: JENKINS-13720
URL: https://issues.jenkins-ci.org/browse/JENKINS-13720
Project: Jenkins
Issue Type: Bug
Components: repo
Reporter: Greg BOUGEARD
I added a String parameter BRANCH_NAME to my job.
I'd like to use it as manifest branch manifest file and it's not evaluated when
the repo init is done :
fatal: manifest '${BRANCH_NAME}.xml' not available
fatal: manifest ${BRANCH_NAME}.xml not found
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11547) Jobs trigger continually even though there are no changes due to git repository being corrupt
[
https://issues.jenkins-ci.org/browse/JENKINS-11547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162602#comment-162602
]
Valentin Rentschler commented on JENKINS-11547:
---
Any combination of Jenkins/git-plugin where this does not occur?
Jobs trigger continually even though there are no changes due to git
repository being corrupt
---
Key: JENKINS-11547
URL: https://issues.jenkins-ci.org/browse/JENKINS-11547
Project: Jenkins
Issue Type: Bug
Components: git
Affects Versions: current
Reporter: James Cook
Priority: Blocker
There is a problem with the git polling mechanism which is causing all our
jobs to kick themselves off continually. This happens at random times and
just fixes itself, but is causing us all sorts of problems due to the large
number of builds triggered.
This is an example of the git polling log:
{noformat}
Started on 28-Oct-2011 03:20:22
Using strategy: Default
[poll] Last Build : #480
[poll] Last Built Revision: Revision abcb8a2492b390521e0c720f96f66a88eae09f18
(origin/master)
Workspace has a .git repository, but it appears to be corrupt.
No Git repository yet, an initial checkout is required
Done. Took 0.26 sec
Changes found
{noformat}
This is caused when a git rev-parse --verify HEAD fails for some reason,
but there is no logging to help in what might have gone wrong. It looks like
the try/catch around the [validateRevision
line|https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitAPI.java#L115]
is too simplistic and the cause of the exception should be considered before
returning false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13620) Being able to tone down the enthusiasm of Jenkins towards popping up some contextual menu
[ https://issues.jenkins-ci.org/browse/JENKINS-13620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162603#comment-162603 ] Alexander Ost commented on JENKINS-13620: - I second this -- I used to copy/paste job names frequently from the overview pages. This is no longer possible, and one has to perform two more mouse clicks and wait for several seconds (ie, open the job itself, copy name from title, then go back). To my surprise this seems to bother not only me as Jenkins admin, but also many developers in our team. -- a global configuration flag to disable the menus will be useful -- ideally, a per-user setting will allow to override the global setting Being able to tone down the enthusiasm of Jenkins towards popping up some contextual menu - Key: JENKINS-13620 URL: https://issues.jenkins-ci.org/browse/JENKINS-13620 Project: Jenkins Issue Type: Improvement Components: gui Affects Versions: current Reporter: Bruno Mahé The new UI improvments and menus are great! But sometimes it goes a little bit too far. To that end, it would be really nice if they would be used that much (or providing a way to disable some of it). As an example, I have now a great difficulty to select a job name since a contextual menu keeps on popping up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10771) hudson.util.IOException2: remote file operation failed
[ https://issues.jenkins-ci.org/browse/JENKINS-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162601#comment-162601 ] Michael Pisula edited comment on JENKINS-10771 at 5/9/12 1:28 PM: -- Since updating from 1.458 to 1.463 I am also having this problem. My master is running on debian, my slave on solaris. Reconnecting the slave did not work. There is enough disk space on the machine, and I am running jenkins standalone, so deleting the xerces-lib is not applicable. Would be really grateful if someone can help. Here is the exception in my case (the underlying NoClassDefFoundException can have other stacktraces) : hudson.util.IOException2: remote file operation failed: /export/home/jenkins/v2010_ci at hudson.remoting.Channel@1dc5322:xxx at hudson.FilePath.act(FilePath.java:828) at hudson.FilePath.act(FilePath.java:814) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685) at hudson.model.AbstractProject.checkout(AbstractProject.java:1218) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) at hudson.model.Run.run(Run.java:1434) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: java.io.IOException: Remote call on xxx failed at hudson.remoting.Channel.call(Channel.java:655) at hudson.FilePath.act(FilePath.java:821) ... 10 more Caused by: java.lang.NoClassDefFoundError at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:766) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676) at java.lang.Thread.run(Thread.java:595) UPDATE: I got it working. In one of my builds, the underlying exception was bad class version which led me to inspect which java version the slave was using. Indeed somehow the path was not set correctly on the slave. As soon as I corrected the path everything started working again. No idea why the paths got reset during this particular update. was (Author: pushy): Since updating from 1.458 to 1.463 I am also having this problem. My master is running on debian, my slave on solaris. Reconnecting the slave did not work. There is enough disk space on the machine, and I am running jenkins standalone, so deleting the xerces-lib is not applicable. Would be really grateful if someone can help. Here is the exception in my case (the underlying NoClassDefFoundException can have other stacktraces) : hudson.util.IOException2: remote file operation failed: /export/home/jenkins/v2010_ci at hudson.remoting.Channel@1dc5322:xxx at hudson.FilePath.act(FilePath.java:828) at hudson.FilePath.act(FilePath.java:814) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685) at hudson.model.AbstractProject.checkout(AbstractProject.java:1218) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) at hudson.model.Run.run(Run.java:1434) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: java.io.IOException: Remote call on xxx failed at hudson.remoting.Channel.call(Channel.java:655) at hudson.FilePath.act(FilePath.java:821) ... 10 more Caused by: java.lang.NoClassDefFoundError at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:766) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at
[JIRA] (JENKINS-13007) Git plugin cannot find revision to build on Windows
[ https://issues.jenkins-ci.org/browse/JENKINS-13007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162604#comment-162604 ] chanti vlad commented on JENKINS-13007: --- Same here. Windows Server 2008 x64 slave, had to downgrade from 1.1.18 to 1.1.15 (plugin built from source for Jenkins 1.463) Git plugin cannot find revision to build on Windows --- Key: JENKINS-13007 URL: https://issues.jenkins-ci.org/browse/JENKINS-13007 Project: Jenkins Issue Type: Bug Components: git Environment: Windows 2008 Server 64 Bit NTFS Reporter: ritzmann Assignee: Nicolas De Loof Priority: Critical After we upgraded the Git plugin from 1.1.14 to 1.1.16, all our builds on Windows build slaves started failing like this: Started by user anonymous Building remotely on win-slave1 in workspace d:\hudson\workspace\my-app Checkout:my-app / d:\hudson\workspace\my-app - hudson.remoting.Channel@95ff886:win-slave1 Using strategy: Default Last Built Revision: Revision e00e2c1328a011ca99980e0ffd90f7534b34 (origin/master) Checkout:my-app / d:\hudson\workspace\my-app - hudson.remoting.LocalChannel@470a4b80 Fetching changes from 1 remote Git repository Fetching upstream changes from d:\hudson\shared\repo.git ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job. The builds on our Linux slaves are not affected. Wiping the workspaces on the Windows slaves did not help. Both clones and checkouts/updates seem to fail with the same error. Downgrading back to 1.1.14 made the Windows builds work again. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13417) git-plugin: rev-parse dereferencing tags breaks on Windows
[
https://issues.jenkins-ci.org/browse/JENKINS-13417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162605#comment-162605
]
chanti vlad commented on JENKINS-13417:
---
Problem confirmed using cygwin git on windows:
- no problem for a manual git clone / checkout as a build step
- ERROR: Couldn't find any revision to build using git plugin 1.1.18
I downgraded to git plugin 1.1.15 (built from source for Jenkins 1.463) and
this worked.
git-plugin: rev-parse dereferencing tags breaks on Windows
--
Key: JENKINS-13417
URL: https://issues.jenkins-ci.org/browse/JENKINS-13417
Project: Jenkins
Issue Type: Bug
Components: git
Environment: Windows 2008 R2 slave launched with cygwin ssh, cygwin
git
Reporter: Jay Berkenbilt
Assignee: Nicolas De Loof
The change to GitAPI.java in commit 13f6038acc4fa5b5a62413155da6fc8cfcad3fe0
seems to break the git plugin for Windows, at least in some circumstances.
The syntax rev^{commit} gets mangled by cmd because ^ is a quote character.
This means that cmd passes rev{commit} to git, which as a cygwin executable
being run from Windows, further tries to do wildcard expansion and maps this
to revcommit. Putting around rev^{commit} empirically seems to work,
though I haven't tried it in the git plugin itself.
This C fragment:
{code}
#include stdio.h
int main(int argc, char* argv[])
{
int i;
for (i = 0; i argc; ++i)
{
printf(%s\n, argv[i]);
}
return 0;
}
{code}
when compiled with mingw to a native Windows application (a.exe) and invoked
from cmd as a.exe a^{b} prints a{b}. When the same fragment is compiled with
cygwin gcc to cygwin executable a.exe and is invoked the same way from cmd,
it prints ab. Both print a^{b} when invoked from cmd as a.exe a^{b}.
I'm not sure what the fix is here other than perhaps detecting that this is
windows and putting quotes around the argument in Windows.
On another note, I left the Affects Version/s field blank. My Jenkins
installation claims that it is using version 1.1.6. Looking at the git repo
for the plugin, it appears that 1.1.6 should not have the ^{commit} fix, yet
running strings on
plugins/git/WEB-INF/classes/hudson/plugins/git/GitAPI.class clearly shows
that my git plugin has that change in it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13719) CVS Updates are not reflected
[ https://issues.jenkins-ci.org/browse/JENKINS-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162607#comment-162607 ] Michael Clarke commented on JENKINS-13719: -- Could you clarify your statement: Are the files in the workspace actually being updated? Is your job polling CVS? If so is it this that's not finding changes? Is your job building off head, a branch, or a tag? Is it just the changelog that's not working properly? CVS Updates are not reflected - Key: JENKINS-13719 URL: https://issues.jenkins-ci.org/browse/JENKINS-13719 Project: Jenkins Issue Type: Bug Components: cvs Environment: Fedora -15 , 32-bit Reporter: Mitesh shah I used a Test Project in which I changed some files and committed into CVS(Set up on local machine). On cvs console it shows new revision number. But when I do build it doesn't show any changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13413) Git icon(git-48x48.png) missing in job page.
[ https://issues.jenkins-ci.org/browse/JENKINS-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sogabe reassigned JENKINS-13413: Assignee: sogabe (was: Nicolas De Loof) Git icon(git-48x48.png) missing in job page. - Key: JENKINS-13413 URL: https://issues.jenkins-ci.org/browse/JENKINS-13413 Project: Jenkins Issue Type: Bug Components: git Environment: Git Plugin 1.1.17 Tomcat 7 Reporter: sogabe Assignee: sogabe Priority: Minor Attachments: git-icon_missing.png After updating to Git Plugin 1.1.17, Git icon is missing in job page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13721) Update-Center FileNotFoundException, Status 404
Daniel Schaarschmidt created JENKINS-13721:
--
Summary: Update-Center FileNotFoundException, Status 404
Key: JENKINS-13721
URL: https://issues.jenkins-ci.org/browse/JENKINS-13721
Project: Jenkins
Issue Type: Bug
Components: update-center
Affects Versions: current
Environment: behind Company Proxy
Reporter: Daniel Schaarschmidt
Priority: Critical
Whenever I try to update plugins using the Jenkins-UI or even downloading them
with Firefox I get a 404-error.
I found the following discussions relating this kind of problem to a proxy:
http://jenkins.361315.n4.nabble.com/Jenkins-site-down-td4504875.html
http://jenkins.361315.n4.nabble.com/Jenkins-download-page-seems-to-be-down-td3520292.html
Unfortunately, these discussion don't point to a reliable solution. Not using
the proxy is not an option in our company.
Error-Message:
{code}
hudson.util.IOException2: Failed to download from
http://updates.jenkins-ci.org/download/plugins/artifactory/2.0.7/artifactory.hpi
at
hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:659)
at hudson.model.UpdateCenter$DownloadJob._run(UpdateCenter.java:978)
at
hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1121)
at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:957)
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
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)
Caused by: java.io.FileNotFoundException:
http://updates.jenkins-ci.org/download/plugins/artifactory/2.0.7/artifactory.hpi
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1496)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1490)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1144)
at
hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:629)
... 9 more
Caused by: java.io.FileNotFoundException:
http://updates.jenkins-ci.org/download/plugins/artifactory/2.0.7/artifactory.hpi
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1439)
at
sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:2301)
at java.net.URLConnection.getHeaderFieldInt(URLConnection.java:579)
at java.net.URLConnection.getContentLength(URLConnection.java:474)
at
hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:628)
... 9 more
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13227) CVS plugin 2.1 does not detect changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162609#comment-162609 ] Michael Clarke commented on JENKINS-13227: -- I think I've got a change that works, although your CVS rlog output isn't a useful test case given the branch you're using (it finds 0 changes). If I change to use your 'd-chg00017366_op_impl_2012-05-02_v20' branch then I find 8 changes from your rlog output which seems to be valid. I'll do a bit more testing the commit the changes to git. CVS plugin 2.1 does not detect changes -- Key: JENKINS-13227 URL: https://issues.jenkins-ci.org/browse/JENKINS-13227 Project: Jenkins Issue Type: Bug Components: cvs Reporter: Guillaume Bilodeau Assignee: Michael Clarke Priority: Critical Labels: cvs Attachments: rlog.txt As presented in the user group: https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/Dvv0I3FBNW4 We've been running Jenkins 1.451 and 1.454 on Windows XP against a CVS repository for a few weeks now, without any problems. The CVS plugin (v1.6) was using the local cvsnt install. We've since upgraded the CVS plugin to version 2.1 (by manually pinning the plugin) and since then, CVS changes are not detected. The CVS polling log is triggered properly, tons of cvs rlog instructions are sent, but at the end No changes is displayed. Using CVS plugin 1.6 the cvs polling command looked like this (executed at 5:26:21 PM EDT): cvs -q -z3 -n update -PdC -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D Thursday, March 22, 2012 9:26:21 PM UTC Using CVS plugin 2.1, the last cvs checkout command looked like this (executed at 11:56:16 AM EDT): cvs checkout -P -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D 23 Mar 2012 11:56:16 EDT -d portailInt portailInt We're in Montreal, so Eastern Time Zone with Daylight Saving Time in effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13227) CVS plugin 2.1 does not detect changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162609#comment-162609 ] Michael Clarke edited comment on JENKINS-13227 at 5/9/12 2:32 PM: -- I think I've got a change that works, although your CVS rlog output isn't a useful test case given the branch you're using (it finds 0 changes). If I change to use your 'd-chg00017366_op_impl_2012-05-02_v20' branch then I find 8 changes from your rlog output which seems to be valid. I'll do a bit more testing then commit the changes to git. was (Author: mc1arke): I think I've got a change that works, although your CVS rlog output isn't a useful test case given the branch you're using (it finds 0 changes). If I change to use your 'd-chg00017366_op_impl_2012-05-02_v20' branch then I find 8 changes from your rlog output which seems to be valid. I'll do a bit more testing the commit the changes to git. CVS plugin 2.1 does not detect changes -- Key: JENKINS-13227 URL: https://issues.jenkins-ci.org/browse/JENKINS-13227 Project: Jenkins Issue Type: Bug Components: cvs Reporter: Guillaume Bilodeau Assignee: Michael Clarke Priority: Critical Labels: cvs Attachments: rlog.txt As presented in the user group: https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/Dvv0I3FBNW4 We've been running Jenkins 1.451 and 1.454 on Windows XP against a CVS repository for a few weeks now, without any problems. The CVS plugin (v1.6) was using the local cvsnt install. We've since upgraded the CVS plugin to version 2.1 (by manually pinning the plugin) and since then, CVS changes are not detected. The CVS polling log is triggered properly, tons of cvs rlog instructions are sent, but at the end No changes is displayed. Using CVS plugin 1.6 the cvs polling command looked like this (executed at 5:26:21 PM EDT): cvs -q -z3 -n update -PdC -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D Thursday, March 22, 2012 9:26:21 PM UTC Using CVS plugin 2.1, the last cvs checkout command looked like this (executed at 11:56:16 AM EDT): cvs checkout -P -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D 23 Mar 2012 11:56:16 EDT -d portailInt portailInt We're in Montreal, so Eastern Time Zone with Daylight Saving Time in effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13590) Trigger build when new pull request occurs in github
[ https://issues.jenkins-ci.org/browse/JENKINS-13590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162610#comment-162610 ] Max Horn commented on JENKINS-13590: I would also love to have this. Indeed, going beyond it, whenever a pull request is modified (a new commit added, rebased, etc.), another re-run should be triggered, and ideally, the result of the test run would be posted as a comment on the pull request. Kind of like travis-ci.org does it, see http://about.travis-ci.org/blog/announcing-pull-request-support/. They do a bit more, though: Instead of building the remote branch from the pull request, they instead do this: 1) merge the remote branch into master, report error if that fails 2) try to build the result of that merge (and perhaps also run test suite), report error if that fails Extra bonus if this becomes possible (I guess I could handle this with a custom build, as long as it receives sufficient details about the pull request, such as the branch name / commit hash, and the requester's username) Trigger build when new pull request occurs in github Key: JENKINS-13590 URL: https://issues.jenkins-ci.org/browse/JENKINS-13590 Project: Jenkins Issue Type: New Feature Components: git, github Reporter: Miroslav Novak Assignee: Nicolas De Loof Priority: Critical Labels: git, jenkins, plugins We have a project in github and we would like to start new build whenever new pull request occurs. This run should test whether changes in pull request won't break the build. Right now we've a separate script which periodically scans open pull requests and checks lasts builds which of them were already run. This approach is used for JBoss AS7 or HornetQ project and appears to be best practice how to use git(hub). Thanks, Mirek P.S. I hope I don't duplicate another jira. I could not find it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13227) CVS plugin 2.1 does not detect changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162611#comment-162611 ] Guillaume Bilodeau commented on JENKINS-13227: -- Awesome! CVS plugin 2.1 does not detect changes -- Key: JENKINS-13227 URL: https://issues.jenkins-ci.org/browse/JENKINS-13227 Project: Jenkins Issue Type: Bug Components: cvs Reporter: Guillaume Bilodeau Assignee: Michael Clarke Priority: Critical Labels: cvs Attachments: rlog.txt As presented in the user group: https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/Dvv0I3FBNW4 We've been running Jenkins 1.451 and 1.454 on Windows XP against a CVS repository for a few weeks now, without any problems. The CVS plugin (v1.6) was using the local cvsnt install. We've since upgraded the CVS plugin to version 2.1 (by manually pinning the plugin) and since then, CVS changes are not detected. The CVS polling log is triggered properly, tons of cvs rlog instructions are sent, but at the end No changes is displayed. Using CVS plugin 1.6 the cvs polling command looked like this (executed at 5:26:21 PM EDT): cvs -q -z3 -n update -PdC -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D Thursday, March 22, 2012 9:26:21 PM UTC Using CVS plugin 2.1, the last cvs checkout command looked like this (executed at 11:56:16 AM EDT): cvs checkout -P -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D 23 Mar 2012 11:56:16 EDT -d portailInt portailInt We're in Montreal, so Eastern Time Zone with Daylight Saving Time in effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9142) Add Build Step button broken in job configure page
[ https://issues.jenkins-ci.org/browse/JENKINS-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wade Williams updated JENKINS-9142: --- Experienced this problem too on Jenkins ver. 1.462, on Ubuntu 12.04. Turning off Prevent Cross Site Request Forgery exploits resolved the issue for me. Add Build Step button broken in job configure page Key: JENKINS-9142 URL: https://issues.jenkins-ci.org/browse/JENKINS-9142 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: CentOS linux x86_64 firefox 3.6.15 Reporter: Andrew Helfer Priority: Blocker after upggrading from Hudson 1.395 to Jenkins 1.403 and installing the msbuild and VCviewer plugins, the add build step button no longer works. Doesn't add a shell window to the web UI, no matter what I do. Last known successful action was to delete a step, first unsuccessful action was to add an msbuild step. there are no Java console errors or warnings, and nothing in the logs to suggest anything wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13722) vSphere plugin causing non-vSphere jobs to fail
Christian Höltje created JENKINS-13722: -- Summary: vSphere plugin causing non-vSphere jobs to fail Key: JENKINS-13722 URL: https://issues.jenkins-ci.org/browse/JENKINS-13722 Project: Jenkins Issue Type: Bug Components: vsphere-cloud Reporter: Christian Höltje I have vSphere plugin 0.9 and Jenkins 1.462 (and I tried 1.463) and it caused matrix jobs, that do not run on vSphere slaves, to die with this error: Started by timer FATAL: null java.lang.NullPointerException at org.jenkinsci.plugins.vSphereCloudRunListener.onStarted(vSphereCloudRunListener.java:32) at hudson.model.listeners.RunListener.fireStarted(RunListener.java:188) at hudson.model.Run.run(Run.java:1429) at hudson.matrix.MatrixBuild.run(MatrixBuild.java:248) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) at hudson.model.OneOffExecutor.run(OneOffExecutor.java:66) To add insult to injury, the builds then got locked. :-( None of the vSphere slaves seemed to be having problems (in fact, jobs were building on them just fine). My solution was to change all my vSphere slaves to normal slaves and then removing the plugin. Simply changing the slaves wasn't enough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13631) Can't manually promote build with approval parameter
[ https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162613#comment-162613 ] Thomas Lehmann commented on JENKINS-13631: -- I can reproduce this bug with Jenkins 1.462, Promoted Builds 2.5 and OpenJDK Runtime Environment (IcedTea6 1.10.6) (fedora-63.1.10.6.fc15-x86_64) Can't manually promote build with approval parameter Key: JENKINS-13631 URL: https://issues.jenkins-ci.org/browse/JENKINS-13631 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: debian 5 Oracle JDK 1.6.0_12 Jenkins 1.461 Reporter: Aurélien Pelletier Labels: plugin Promoted build plugin version 2.5, it works with version 2.4 I have a job configured with a manually approved + approval parameter promotion. When I try to promoted the build using the Approve button to pass the parameters I get an error 500 with this stack trace: java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB at hudson.maven.ModuleName.fromString(ModuleName.java:97) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117) at jenkins.model.Jenkins.getItem(Jenkins.java:2159) at jenkins.model.Jenkins.getItem(Jenkins.java:2180) at hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13227) CVS plugin 2.1 does not detect changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162614#comment-162614 ] Amir Isfy commented on JENKINS-13227: - Beautiful! CVS plugin 2.1 does not detect changes -- Key: JENKINS-13227 URL: https://issues.jenkins-ci.org/browse/JENKINS-13227 Project: Jenkins Issue Type: Bug Components: cvs Reporter: Guillaume Bilodeau Assignee: Michael Clarke Priority: Critical Labels: cvs Attachments: rlog.txt As presented in the user group: https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/Dvv0I3FBNW4 We've been running Jenkins 1.451 and 1.454 on Windows XP against a CVS repository for a few weeks now, without any problems. The CVS plugin (v1.6) was using the local cvsnt install. We've since upgraded the CVS plugin to version 2.1 (by manually pinning the plugin) and since then, CVS changes are not detected. The CVS polling log is triggered properly, tons of cvs rlog instructions are sent, but at the end No changes is displayed. Using CVS plugin 1.6 the cvs polling command looked like this (executed at 5:26:21 PM EDT): cvs -q -z3 -n update -PdC -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D Thursday, March 22, 2012 9:26:21 PM UTC Using CVS plugin 2.1, the last cvs checkout command looked like this (executed at 11:56:16 AM EDT): cvs checkout -P -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D 23 Mar 2012 11:56:16 EDT -d portailInt portailInt We're in Montreal, so Eastern Time Zone with Daylight Saving Time in effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13724) Cannot upgrade to 1.39 from 1.34/1.37
David Riley created JENKINS-13724: - Summary: Cannot upgrade to 1.39 from 1.34/1.37 Key: JENKINS-13724 URL: https://issues.jenkins-ci.org/browse/JENKINS-13724 Project: Jenkins Issue Type: Bug Components: subversion Reporter: David Riley Priority: Blocker http://groups.google.com/group/jenkinsci-users/browse_thread/thread/b965e844d7cab6cf I am struggling to install the 1.39 update through the ui, and even downloading manually does not work either. Even though it gets installed successfully restarting, afterwards it reports that the installed version is 1.34 and 1.39 is available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8617) cannot customize security group to launch slaves into
[ https://issues.jenkins-ci.org/browse/JENKINS-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162615#comment-162615 ] Yuu Yamashita commented on JENKINS-8617: oh, i just created my version of the patch but it is a duplication of this issue :( https://github.com/jenkinsci/ec2-plugin/pull/18 IMHO, putting security group configuration in SlaveTemplate is good idea since some AMIs may require distinct security group. cannot customize security group to launch slaves into - Key: JENKINS-8617 URL: https://issues.jenkins-ci.org/browse/JENKINS-8617 Project: Jenkins Issue Type: Improvement Components: ec2 Reporter: mwhudson Assignee: mwhudson Priority: Minor It's slightly inconvenient to have to use the 'default' security group for our slaves. It's only slightly inconvenient, but it seems that this should be pretty easy to fix, too. I may even try myself! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13631) Can't manually promote build with approval parameter
[
https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162616#comment-162616
]
Thomas Lehmann commented on JENKINS-13631:
--
I guess I realize what the problem is (however I am not familar with
Jenkins/Hudson nor with the promote plugin).
The passed job name is NAME-OF-THE-JOB. I've debugged the calls and tried to
reverse engineer what Jenkins.getItem() does. After that I've tried to pass
/NAME-OF-THE-JOB. It dit not fail with an exception and responded with 200
OK. After that the promotion was marked approved. So I think this did the
trick. Even though I do not know if this is correct. :)
Bad request:
$ curl -X POST --cookie JSESSIONID.*; JSESSIONID.* --form-string
'_.=NAME-OF-THE-USER' --form-string 'json={: NAME-OF-THE-USER}'
--form-string 'Submit=Approve'
'http://localhost:8070/job/Build-1/9/promotion/promotionProcess/Release%20Approved/promotionCondition/hudson.plugins.promoted_builds.conditions.ManualCondition/approve?job=Build-1buildNumber=9promotion=Release%20Approved'
Good request:
$ curl -X POST --cookie JSESSIONID.*; JSESSIONID.* --form-string
'_.=NAME-OF-THE-USER' --form-string 'json={: NAME-OF-THE-USER}'
--form-string 'Submit=Approve'
'http://localhost:8070/job/Build-1/9/promotion/promotionProcess/Release%20Approved/promotionCondition/hudson.plugins.promoted_builds.conditions.ManualCondition/approve?job=/Build-1buildNumber=9promotion=Release%20Approved'
As this works for me I'll write a Greasemonkey script to workaround this by
patching the formular.
Please give me feedback if the missing slash prefix is the error.
Can't manually promote build with approval parameter
Key: JENKINS-13631
URL: https://issues.jenkins-ci.org/browse/JENKINS-13631
Project: Jenkins
Issue Type: Bug
Components: promoted-builds
Affects Versions: current
Environment: debian 5
Oracle JDK 1.6.0_12
Jenkins 1.461
Reporter: Aurélien Pelletier
Labels: plugin
Promoted build plugin version 2.5, it works with version 2.4
I have a job configured with a manually approved + approval parameter
promotion.
When I try to promoted the build using the Approve button to pass the
parameters I get an error 500 with this stack trace:
java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB
at hudson.maven.ModuleName.fromString(ModuleName.java:97)
at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354)
at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117)
at jenkins.model.Jenkins.getItem(Jenkins.java:2159)
at jenkins.model.Jenkins.getItem(Jenkins.java:2180)
at
hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13724) Cannot upgrade to 1.39 from 1.34/1.37
[ https://issues.jenkins-ci.org/browse/JENKINS-13724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162617#comment-162617 ] Andrew Kujtan commented on JENKINS-13724: - @see https://issues.jenkins-ci.org/browse/JENKINS-13421 Cannot upgrade to 1.39 from 1.34/1.37 - Key: JENKINS-13724 URL: https://issues.jenkins-ci.org/browse/JENKINS-13724 Project: Jenkins Issue Type: Bug Components: subversion Reporter: David Riley Priority: Blocker http://groups.google.com/group/jenkinsci-users/browse_thread/thread/b965e844d7cab6cf I am struggling to install the 1.39 update through the ui, and even downloading manually does not work either. Even though it gets installed successfully restarting, afterwards it reports that the installed version is 1.34 and 1.39 is available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13125) HTTP Content-Range Header one byte past file length
[ https://issues.jenkins-ci.org/browse/JENKINS-13125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162618#comment-162618 ] Roland Schulz commented on JENKINS-13125: - I just upgraded to 1.463 but the Chrome internal PDF viewer still gets stuck on a PDF from Jenkins. Thus this doesn't seem to be fixed. HTTP Content-Range Header one byte past file length --- Key: JENKINS-13125 URL: https://issues.jenkins-ci.org/browse/JENKINS-13125 Project: Jenkins Issue Type: Bug Components: www Affects Versions: current Reporter: Roland Schulz Downloading a PDF artifact using Chrome (17.0.963.79 m on Windows) the HTTP header for the last partial entity-body sent back by Jenkins contains: Content-Range: 2613923-2646691/2646691\r\n I believe this is wrong according to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.16 . I believe the last range should be 2613923-2646690/2646691, because the numbers are 0-indexed. I'm not sure whether this is caused by this or is a separate issue, but Chrome keeps requesting the same last partial segment and Jenkins returns the same one in an endless loop. Thus Chrome is stuck loading the PDF at 100% in the endless loop. This only happens with the Chrome embedded PDF viewer. The file downloads correctly with Save as. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13631) Can't manually promote build with approval parameter
[ https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Lehmann updated JENKINS-13631: - Attachment: fix-missing-slash-in-job-name.user.js Successfully tested with recent Chrome. Not tested with Firefox/Greasemonkey or Safari. Install by opening this file in your browser (browse to file:///path/to/fix-missing-slash-in-job-name.user.js). Can't manually promote build with approval parameter Key: JENKINS-13631 URL: https://issues.jenkins-ci.org/browse/JENKINS-13631 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: debian 5 Oracle JDK 1.6.0_12 Jenkins 1.461 Reporter: Aurélien Pelletier Labels: plugin Attachments: fix-missing-slash-in-job-name.user.js Promoted build plugin version 2.5, it works with version 2.4 I have a job configured with a manually approved + approval parameter promotion. When I try to promoted the build using the Approve button to pass the parameters I get an error 500 with this stack trace: java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB at hudson.maven.ModuleName.fromString(ModuleName.java:97) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117) at jenkins.model.Jenkins.getItem(Jenkins.java:2159) at jenkins.model.Jenkins.getItem(Jenkins.java:2180) at hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13725) Bug encoding file
alexandre schossler created JENKINS-13725:
-
Summary: Bug encoding file
Key: JENKINS-13725
URL: https://issues.jenkins-ci.org/browse/JENKINS-13725
Project: Jenkins
Issue Type: Bug
Components: maven2
Reporter: alexandre schossler
I am running on a debian server jenkins, already rolled my whole project, all
classes are in the UTF-8, but when trying to build the project occurs in the
following error
tarted by timer
Building in workspace /home/hudson/.jenkins/workspace/scuv
Updating http://192.168.3.100/svn/SCUV/trunk
At revision 226
no change for http://192.168.3.100/svn/SCUV/trunk since the previous build
Parsing POMs
[scuv] $ /home/jdk6u31/bin/java -cp
/home/hudson/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven-agent-1.2.jar:/home/maven_2.2.1/boot/classworlds-1.1.jar
hudson.maven.agent.Main /home/maven_2.2.1
/home/hudson/.jenkins/war/WEB-INF/lib/remoting-2.13.jar
/home/hudson/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven-interceptor-1.2.jar
47805
/home/hudson/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven2.1-interceptor-1.2.jar
===[JENKINS REMOTING CAPACITY]===channel started
log4j:WARN No appenders could be found for logger
(org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
Executing Maven: -B -f /home/hudson/.jenkins/workspace/scuv/pom.xml clean
install
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] SCUV
[INFO] SCUV Persistence Module
[INFO] SCUV WebService Module
[INFO] SCUV WebApp Module
[INFO]
[INFO] Building SCUV
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting directory /home/hudson/.jenkins/workspace/scuv/target
[INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
[INFO] [javadoc:jar {execution: default}]
[INFO] Not executing Javadoc as the project is not a Java classpath-capable
package
[INFO] [install:install {execution: default-install}]
[INFO] Installing /home/hudson/.jenkins/workspace/scuv/pom.xml to
/home/hudson/.m2/repository/br/com/digitaldoc/scuv/scuv/0.0.1/scuv-0.0.1.pom
[INFO] Installing
/home/hudson/.jenkins/workspace/scuv/target/scuv-0.0.1-site.xml to
/home/hudson/.m2/repository/br/com/digitaldoc/scuv/scuv/0.0.1/scuv-0.0.1-site.xml
[JENKINS] Archiving /home/hudson/.jenkins/workspace/scuv/pom.xml to
/home/hudson/.jenkins/jobs/scuv/modules/br.com.digitaldoc.scuv$scuv/builds/2012-05-09_14-46-21/archive/br.com.digitaldoc.scuv/scuv/0.0.1/scuv-0.0.1.pom
[JENKINS] Archiving
/home/hudson/.jenkins/workspace/scuv/target/scuv-0.0.1-site.xml to
/home/hudson/.jenkins/jobs/scuv/modules/br.com.digitaldoc.scuv$scuv/builds/2012-05-09_14-46-21/archive/br.com.digitaldoc.scuv/scuv/0.0.1/scuv-0.0.1-site.xml
[INFO]
[INFO] Building SCUV Persistence Module
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting directory
/home/hudson/.jenkins/workspace/scuv/scuv.persistence/target
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 58 source files to
/home/hudson/.jenkins/workspace/scuv/scuv.persistence/target/classes
[JENKINS] Archiving
/home/hudson/.jenkins/workspace/scuv/scuv.persistence/pom.xml to
/home/hudson/.jenkins/jobs/scuv/modules/br.com.digitaldoc.scuv$scuv.persistence/builds/2012-05-09_14-46-21/archive/br.com.digitaldoc.scuv/scuv.persistence/0.0.1/scuv.persistence-0.0.1.pom
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/hudson/.jenkins/workspace/scuv/scuv.persistence/src/main/java/br/com/digitaldoc/scuv/dao/ClienteDao.java:[57,67]
unmappable character for encoding ASCII
.
the character of the error that has an accent, and is a comment
/**
* Busca por todos os itens que tenham no nome e/ou email o parâmetro
* passado
*
*/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13631) Can't manually promote build with approval parameter
[ https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162619#comment-162619 ] Thomas Lehmann edited comment on JENKINS-13631 at 5/9/12 6:16 PM: -- Attached user script. Successfully tested with recent Chrome. Not tested with Firefox/Greasemonkey or Safari. Install by opening this file in your browser (browse to file:///path/to/fix-missing-slash-in-job-name.user.js). Adapt the match URL. was (Author: tholewebgods): Attached user script. Successfully tested with recent Chrome. Not tested with Firefox/Greasemonkey or Safari. Install by opening this file in your browser (browse to file:///path/to/fix-missing-slash-in-job-name.user.js). Can't manually promote build with approval parameter Key: JENKINS-13631 URL: https://issues.jenkins-ci.org/browse/JENKINS-13631 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: debian 5 Oracle JDK 1.6.0_12 Jenkins 1.461 Reporter: Aurélien Pelletier Labels: plugin Attachments: fix-missing-slash-in-job-name.user.js Promoted build plugin version 2.5, it works with version 2.4 I have a job configured with a manually approved + approval parameter promotion. When I try to promoted the build using the Approve button to pass the parameters I get an error 500 with this stack trace: java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB at hudson.maven.ModuleName.fromString(ModuleName.java:97) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117) at jenkins.model.Jenkins.getItem(Jenkins.java:2159) at jenkins.model.Jenkins.getItem(Jenkins.java:2180) at hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13631) Can't manually promote build with approval parameter
[ https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162619#comment-162619 ] Thomas Lehmann edited comment on JENKINS-13631 at 5/9/12 6:16 PM: -- Attached user script. Successfully tested with recent Chrome. Not tested with Firefox/Greasemonkey or Safari. Install by opening this file in your browser (browse to file:///path/to/fix-missing-slash-in-job-name.user.js). was (Author: tholewebgods): Successfully tested with recent Chrome. Not tested with Firefox/Greasemonkey or Safari. Install by opening this file in your browser (browse to file:///path/to/fix-missing-slash-in-job-name.user.js). Can't manually promote build with approval parameter Key: JENKINS-13631 URL: https://issues.jenkins-ci.org/browse/JENKINS-13631 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: debian 5 Oracle JDK 1.6.0_12 Jenkins 1.461 Reporter: Aurélien Pelletier Labels: plugin Attachments: fix-missing-slash-in-job-name.user.js Promoted build plugin version 2.5, it works with version 2.4 I have a job configured with a manually approved + approval parameter promotion. When I try to promoted the build using the Approve button to pass the parameters I get an error 500 with this stack trace: java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB at hudson.maven.ModuleName.fromString(ModuleName.java:97) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117) at jenkins.model.Jenkins.getItem(Jenkins.java:2159) at jenkins.model.Jenkins.getItem(Jenkins.java:2180) at hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13725) Bug encoding file
[
https://issues.jenkins-ci.org/browse/JENKINS-13725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
alexandre schossler updated JENKINS-13725:
--
Fix Version/s: current
Component/s: core
(was: maven2)
Bug encoding file
-
Key: JENKINS-13725
URL: https://issues.jenkins-ci.org/browse/JENKINS-13725
Project: Jenkins
Issue Type: Bug
Components: core
Reporter: alexandre schossler
Fix For: current
I am running on a debian server jenkins, already rolled my whole project, all
classes are in the UTF-8, but when trying to build the project occurs in the
following error
tarted by timer
Building in workspace /home/hudson/.jenkins/workspace/scuv
Updating http://192.168.3.100/svn/SCUV/trunk
At revision 226
no change for http://192.168.3.100/svn/SCUV/trunk since the previous build
Parsing POMs
[scuv] $ /home/jdk6u31/bin/java -cp
/home/hudson/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven-agent-1.2.jar:/home/maven_2.2.1/boot/classworlds-1.1.jar
hudson.maven.agent.Main /home/maven_2.2.1
/home/hudson/.jenkins/war/WEB-INF/lib/remoting-2.13.jar
/home/hudson/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven-interceptor-1.2.jar
47805
/home/hudson/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven2.1-interceptor-1.2.jar
===[JENKINS REMOTING CAPACITY]===channel started
log4j:WARN No appenders could be found for logger
(org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
Executing Maven: -B -f /home/hudson/.jenkins/workspace/scuv/pom.xml clean
install
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] SCUV
[INFO] SCUV Persistence Module
[INFO] SCUV WebService Module
[INFO] SCUV WebApp Module
[INFO]
[INFO] Building SCUV
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting directory /home/hudson/.jenkins/workspace/scuv/target
[INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
[INFO] [javadoc:jar {execution: default}]
[INFO] Not executing Javadoc as the project is not a Java classpath-capable
package
[INFO] [install:install {execution: default-install}]
[INFO] Installing /home/hudson/.jenkins/workspace/scuv/pom.xml to
/home/hudson/.m2/repository/br/com/digitaldoc/scuv/scuv/0.0.1/scuv-0.0.1.pom
[INFO] Installing
/home/hudson/.jenkins/workspace/scuv/target/scuv-0.0.1-site.xml to
/home/hudson/.m2/repository/br/com/digitaldoc/scuv/scuv/0.0.1/scuv-0.0.1-site.xml
[JENKINS] Archiving /home/hudson/.jenkins/workspace/scuv/pom.xml to
/home/hudson/.jenkins/jobs/scuv/modules/br.com.digitaldoc.scuv$scuv/builds/2012-05-09_14-46-21/archive/br.com.digitaldoc.scuv/scuv/0.0.1/scuv-0.0.1.pom
[JENKINS] Archiving
/home/hudson/.jenkins/workspace/scuv/target/scuv-0.0.1-site.xml to
/home/hudson/.jenkins/jobs/scuv/modules/br.com.digitaldoc.scuv$scuv/builds/2012-05-09_14-46-21/archive/br.com.digitaldoc.scuv/scuv/0.0.1/scuv-0.0.1-site.xml
[INFO]
[INFO] Building SCUV Persistence Module
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting directory
/home/hudson/.jenkins/workspace/scuv/scuv.persistence/target
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 58 source files to
/home/hudson/.jenkins/workspace/scuv/scuv.persistence/target/classes
[JENKINS] Archiving
/home/hudson/.jenkins/workspace/scuv/scuv.persistence/pom.xml to
/home/hudson/.jenkins/jobs/scuv/modules/br.com.digitaldoc.scuv$scuv.persistence/builds/2012-05-09_14-46-21/archive/br.com.digitaldoc.scuv/scuv.persistence/0.0.1/scuv.persistence-0.0.1.pom
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/hudson/.jenkins/workspace/scuv/scuv.persistence/src/main/java/br/com/digitaldoc/scuv/dao/ClienteDao.java:[57,67]
unmappable character for encoding ASCII
.
the character of the error that has an accent, and is a comment
/**
* Busca por todos os itens que tenham no nome e/ou email o parâmetro
* passado
*
*/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly,
[JIRA] (JENKINS-10912) Memory leak (?) in dashboard
[ https://issues.jenkins-ci.org/browse/JENKINS-10912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162620#comment-162620 ] Anoop Karollil commented on JENKINS-10912: -- This seems to happen only when using Chrome, possibly having auto-refresh enabled and leaving the tab open all the time. Memory leak (?) in dashboard Key: JENKINS-10912 URL: https://issues.jenkins-ci.org/browse/JENKINS-10912 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: windows jenkins server windows client chrome browser autorefresh is enabled Reporter: david abadir Priority: Minor leaving the dashboard webpage open (with autorefresh) will accumulate lots of memory. I left it open over the weekend and it was using over 700 MB of ram! you can watch the memory consumption increase ~3-10 MB every time it refreshes (manually or automatically). Sometimes it will decrease to the pre-refreshed amount, but it will always increase over time (instantaneous readings may/may not prove true, but long term averages will). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11853) Duplicate build numbers in the Build History
[ https://issues.jenkins-ci.org/browse/JENKINS-11853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162621#comment-162621 ] alexlombardi commented on JENKINS-11853: Seeing this issue in Jenkins 1.463 with a job that has a single build entry when running a Master-Slave setup as a Windows service. Have a single build in the folder but the entry appears twice in the Build History box (build was successful in my case though and is really old) in Jenkins about 5 seconds after I have navigated into the appplication and try to look at build details (it is NOT there immediately). Do not see this happen with any other projects but this one. Duplicate build numbers in the Build History - Key: JENKINS-11853 URL: https://issues.jenkins-ci.org/browse/JENKINS-11853 Project: Jenkins Issue Type: Bug Components: build-pipeline Environment: Operating System: Linux-CentOS gcc version: 4.4.4 Reporter: nanda kishore Priority: Critical Labels: build Attachments: duplicate_build_numbers.png I have recently upgraded hudson to latest jenkins(1.437 and later to 1.439). Ofcourse the migration went pretty smooth, but recently I started facing a problem related the existing build numbers of one particular job. In the Build history(left sidebar of any job page) I am seeing duplicate build numbers. Check the first attachment named duplicate_build_numbers. When you reload the same job page, it displays only one unique build and no duplicate builds. But after a few seconds(may be 3 or 4 secs) the duplicate build is coming up. I checked the builds directory related to that job and found only one directory related to the build. For the build mentioned in the figure I saw only one directory named: 2011-10-16_01-06-08 So is there any issue in the way Build History is shown to the users or Am I missing anything ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-3922) Slave is slow copying maven artifacts to master
[ https://issues.jenkins-ci.org/browse/JENKINS-3922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162622#comment-162622 ] David Reiss commented on JENKINS-3922: -- This issue affected us in a big way once we moved our slaves to a remote datacenter. From the descriptions, it seems like not everyone has the same problem that we did, but I'll explain how we fixed it. h3. Diagnostics - Make sure you can log into your master and run scp slave:somefile . and get the bandwidth that you expect. If not, Jenkins is not your problem. Check out http://wwwx.cs.unc.edu/~sparkst/howto/network_tuning.php if you are on a high-latency link. - Compute your bandwidth-delay product. This is the bandwidth you get from a raw scp in bytes per second times the round-trip-time you get from ping. In my case, this was about 4,000,000 (4 MB/s) * 0.06 (60ms) = 240,000 bytes (240 kB). - *If you are using ssh slaves and your BDP is greater than 16 kB, you are definitely having the same problem that we were.* This is the trilead ssh window problem. - If you are using any type of slave and your BDP is greater than 128 kB, then you are also affected by the jenkins remoting pipe window problem. h3. trilead ssh window problem The ssh-slaves-plugin uses the trilead ssh library to connect to the slaves. Unfortunately, that library uses a hard-coded 30,000-byte receive buffer, which limits the amount of in-flight data to 30,000 bytes. In practice, the algorithm it uses for updating its receive window rounds that down to a power of two, so you only get 16kB. I created a pull request at https://github.com/jenkinsci/trilead-ssh2/pull/1 to make this configurable at JVM startup time. Making this window large increased our bandwidth by a factor of almost 8. Note that two of these buffers are allocated for each slave, so turning this up can consume memory quickly if you have several slaves. In our case, we have memory to spare, so it wasn't a problem. It might be useful to switch to another ssh library that allocates window memory dynamically. Fixing this will get your BDP up to almost 128kB, but beyond that, you run into another problem. h3. jenkins remoting pipe window problem The archiving process uses a hudson.remoting.Pipe object to send the data back. This object uses flow control to avoid overwhelming the receiver. By default, it only allows 128kB of in-flight data. There is already a system property that controls this constant, but it has a space in its name, which makes it a bit complicated to set. I created a pull request at https://github.com/jenkinsci/remoting/pull/4 to fix the name. Note that this property must be set on the *slave*'s JVM, not the master's. Therefore, to set it, you must go into your ssh slave configuration, open the advanced button, find the JVM Options input, and enter -Dclass\ hudson.remoting.Channel.pipeWindowSize=1234567 (no quotes, change the number to whatever is appropriate for your environment). If my pull request is accepted, this will change to -Dhudson.remoting.Channel.pipeWindowSize=1234567. Note that this window is not preallocated, so you can make this number fairly large and excess memory will not be consumed unless the master is unable to keep up with data from the slave. Increasing both of these windows increased our bandwidth by a factor about 15, matching the 4MB/s we were getting from raw scp. h3. Good luck! Slave is slow copying maven artifacts to master --- Key: JENKINS-3922 URL: https://issues.jenkins-ci.org/browse/JENKINS-3922 Project: Jenkins Issue Type: Bug Components: master-slave Affects Versions: current Environment: Platform: All, OS: All Reporter: John McNair Assignee: Kohsuke Kawaguchi Priority: Critical Attachments: pom.xml The artifact transfer is currently a 3-4x penalty for the project that I am working on. I have reproduced the issue with a simple test pom that does nothing but jar hudson.war. I performed this test on a heterogeneous environment. Both master and slave are running Fedora 10, but the master is a faster machine. Still, it highlights the issue. Here are some stats (all stats are after caching dependencies in the local repos): Master build through Hudson: 19s Master build from command line (no Hudson): 9s Slave build through Hudson: 1m46s Slave build from command line (no Hudson): 16s To be fair we should at least add time to do a straight scp of the artifact from slave to master. The two nodes share a 100 Mbit switch: $ scp target/slow-rider-1.0.0-SNAPSHOT.jar master_node: slow-rider-1.0.0NAPSHOT.jar 100% 25MB 12.7MB/s 00:02 Of course this example exaggerates the issue to make it more clear but not by
[JIRA] (JENKINS-13726) Github plugin should work with Guthub enterprise by allowing for overriding the github URL
cangove created JENKINS-13726: - Summary: Github plugin should work with Guthub enterprise by allowing for overriding the github URL Key: JENKINS-13726 URL: https://issues.jenkins-ci.org/browse/JENKINS-13726 Project: Jenkins Issue Type: New Feature Components: github Affects Versions: current Environment: Centos 5.7 Reporter: cangove Github allows for a local github instance. However the github plugin only works with github.com. It would be nice to have the URL to use be configurable in Jenkins to allow for local github use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12644) Record fingerprints can be enabled even if artifact archiving is disabled
[ https://issues.jenkins-ci.org/browse/JENKINS-12644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162623#comment-162623 ] kenbeal commented on JENKINS-12644: --- We encountered this recently and I said I would report it. I see the bug already exists, so I'm adding this comment to report that it's actively being encountered in the field. Thanks for providing this valuable tool! Record fingerprints can be enabled even if artifact archiving is disabled - Key: JENKINS-12644 URL: https://issues.jenkins-ci.org/browse/JENKINS-12644 Project: Jenkins Issue Type: Bug Components: core Reporter: Kamil Kisiel When disabling the Archive the artifacts option the Record fingerprints of files to track usage option can remain enabled. This causes the build to fail because there's nothing to fingerprint since no artifacts are recorded. I suggest the option be automatically disabled if artifact archiving is disabled, and better yet it could be a sub-option of archive artifacts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13241) Artifact archiving from remote slave fails
[ https://issues.jenkins-ci.org/browse/JENKINS-13241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Reiss resolved JENKINS-13241. --- Resolution: Fixed See JENKINS-13202 for fix details. Artifact archiving from remote slave fails -- Key: JENKINS-13241 URL: https://issues.jenkins-ci.org/browse/JENKINS-13241 Project: Jenkins Issue Type: Bug Components: core Reporter: Vyacheslav Karpukhin Since 1.456 jenkins stopped archiving artifacts from remote slave. This affects both 1.456 and 1.457, works correctly with 1.455. ERROR: Failed to archive artifacts: build/Release/*.app/**/* hudson.util.IOException2: hudson.util.IOException2: Failed to extract /var/jenkins/workspace/NGB_Queues/build/Release/*.app/**/* at hudson.FilePath.readFromTar(FilePath.java:1817) at hudson.FilePath.copyRecursiveTo(FilePath.java:1729) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) at hudson.model.Run.run(Run.java:1435) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) Caused by: java.io.IOException: Failed to chmod /mnt/storage/.jenkins/jobs/NGB_Queues/builds/2012-03-27_03-11-27/archive/build/Release/NGB Queues.app/Contents/Frameworks/BWToolkitFramework.framework/BWToolkitFramework : No such file or directory at hudson.FilePath._chmod(FilePath.java:1248) at hudson.FilePath.readFromTar(FilePath.java:1813) ... 12 more at hudson.FilePath.copyRecursiveTo(FilePath.java:1736) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) at hudson.model.Run.run(Run.java:1435) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Pipe is already closed at hudson.remoting.Channel$2.adapt(Channel.java:714) at hudson.remoting.Channel$2.adapt(Channel.java:709) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59) at hudson.FilePath.copyRecursiveTo(FilePath.java:1732) ... 11 more Caused by: java.io.IOException: Pipe is already closed at hudson.remoting.PipeWindow.checkDeath(PipeWindow.java:83) at hudson.remoting.PipeWindow$Real.get(PipeWindow.java:171) at hudson.remoting.ProxyOutputStream._write(ProxyOutputStream.java:118) at hudson.remoting.ProxyOutputStream.write(ProxyOutputStream.java:103) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109) at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:161) at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:118) at java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:72) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105) at org.apache.tools.tar.TarBuffer.writeBlock(TarBuffer.java:410) at org.apache.tools.tar.TarBuffer.writeRecord(TarBuffer.java:351) at hudson.org.apache.tools.tar.TarOutputStream.writeEOFRecord(TarOutputStream.java:356) at hudson.org.apache.tools.tar.TarOutputStream.finish(TarOutputStream.java:137) at hudson.org.apache.tools.tar.TarOutputStream.close(TarOutputStream.java:149) at hudson.util.io.TarArchiver.close(TarArchiver.java:119) at hudson.FilePath.writeToTar(FilePath.java:1783) at hudson.FilePath.access$1000(FilePath.java:166) at hudson.FilePath$36.invoke(FilePath.java:1722)
[JIRA] (JENKINS-13727) FileNotFoundException Can't stat file with slave projects
Joshua Tharp created JENKINS-13727: -- Summary: FileNotFoundException Can't stat file with slave projects Key: JENKINS-13727 URL: https://issues.jenkins-ci.org/browse/JENKINS-13727 Project: Jenkins Issue Type: Bug Components: ivy Affects Versions: current Environment: Jenkins war running in Tomcat 6.0.29 on RHEL. Jenkins ver: 1.463 Ivy Plugin: 1.21 Reporter: Joshua Tharp Assignee: Timothy Bingaman I run a build cluster with most of my build jobs occurring on Jenkins Slaves. I have the SVN local module directory set to .. I get these stack traces in the log. On the build master there is an ivy.xml file at /home/hudson/hudson/jobs/testutils/ivy.xml, but not one at /home/hudson/hudson/jobs/testutils/workspace/ivy.xml as the error indicates. May 9, 2012 12:38:39 PM hudson.ivy.IvyMessageImpl log INFO: :: loading settings :: url = jar:file:/home/hudson/hudson/plugins/ivy/WEB- INF/lib/ivy-2.2.0.jar!/org/apache/ivy/core/settings/ivysettings.xml May 9, 2012 12:38:39 PM hudson.ivy.IvyBuildTrigger getIvy INFO: Configured Ivy using default 2.1 settings May 9, 2012 12:38:39 PM hudson.ivy.IvyBuildTrigger recomputeModuleDescriptor WARNING: Failed to access the workspace ivy file 'ivy.xml' java.io.FileNotFoundException: Can't stat file /home/hudson/hudson/jobs/testutils/workspace/ivy.xml at hudson.ivy.IvyBuildTrigger.copyFileFromWorkspaceIfNecessary(IvyBuildTrigger.java:289) at hudson.ivy.IvyBuildTrigger.recomputeModuleDescriptor(IvyBuildTrigger.java:352) at hudson.ivy.IvyBuildTrigger.getModuleDescriptor(IvyBuildTrigger.java:264) at hudson.ivy.IvyBuildTrigger.buildDependencyGraph(IvyBuildTrigger.java:449) at hudson.util.DescribableList.buildDependencyGraph(DescribableList.java:194) at hudson.model.Project.buildDependencyGraph(Project.java:174) at hudson.model.DependencyGraph.build(DependencyGraph.java:91) at jenkins.model.Jenkins.rebuildDependencyGraph(Jenkins.java:3420) at hudson.model.AbstractItem.delete(AbstractItem.java:515) at hudson.model.AbstractProject.doDoDelete(AbstractProject.java:1678) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13154) Heavy thread congestion with FingerPrint.save
[ https://issues.jenkins-ci.org/browse/JENKINS-13154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kohsuke Kawaguchi updated JENKINS-13154: Attachment: (was: threads_sample_jenkins_1.463.txt) Heavy thread congestion with FingerPrint.save - Key: JENKINS-13154 URL: https://issues.jenkins-ci.org/browse/JENKINS-13154 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: System Properties Name ↓ Value awt.toolkit sun.awt.X11.XToolkit executable-war/foobar/jenkins/jenkins.war file.encoding UTF-8 file.encoding.pkg sun.io file.separator/ guice.disable.misplaced.annotation.check true hudson.diyChunkingtrue hudson.upstreamCulprits true java.awt.graphicsenv sun.awt.X11GraphicsEnvironment java.awt.headless true java.awt.printerjob sun.print.PSPrinterJob java.class.path /foobar/jenkins/jenkins.war java.class.version51.0 java.endorsed.dirs/foobar/dist/jdk/jdk1.7.0_02/jre/lib/endorsed java.ext.dirs /foobar/dist/jdk/jdk1.7.0_02/jre/lib/ext:/usr/java/packages/lib/ext java.home /foobar/dist/jdk/jdk1.7.0_02/jre java.io.tmpdir/foobar/scratch java.library.path /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib java.runtime.name Java(TM) SE Runtime Environment java.runtime.version 1.7.0_02-b13 java.specification.name Java Platform API Specification java.specification.vendor Oracle Corporation java.specification.version1.7 java.vendor Oracle Corporationa java.vendor.url http://java.oracle.com/ java.vendor.url.bug http://bugreport.sun.com/bugreport/ java.version 1.7.0_02 java.vm.info mixed mode java.vm.name Java HotSpot(TM) 64-Bit Server VM java.vm.specification.nameJava Virtual Machine Specification java.vm.specification.vendor Oracle Corporation java.vm.specification.version 1.7 java.vm.vendorOracle Corporation java.vm.version 22.0-b10 jna.platform.library.path /usr/lib64:/lib64:/usr/lib:/lib line.separator mail.smtp.sendpartial true mail.smtps.sendpartialtrue os.arch amd64 os.name Linux os.version2.6.18-164.15.1.el5 path.separator: securerandom.source file:/dev/./urandom sun.arch.data.model 64 sun.boot.class.path /foobar/dist/jdk/jdk1.7.0_02/jre/lib/resources.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/rt.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/sunrsasign.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/jsse.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/jce.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/charsets.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/classes sun.boot.library.path /foobar/dist/jdk/jdk1.7.0_02/jre/lib/amd64 sun.cpu.endianlittle sun.cpu.isalist sun.io.unicode.encoding UnicodeLittle sun.java.command /foobar/jenkins/jenkins.war --httpPort=8088 sun.java.launcher SUN_STANDARD sun.jnu.encoding UTF-8 sun.management.compiler HotSpot 64-Bit Tiered Compilers sun.os.patch.levelunknown svnkit.http.methods Digest,Basic,NTLM,Negotiate svnkit.ssh2.persistentfalse user.country FI user.dir /foobar/jenkins user.home /foobar/baz user.language fi user.name baz user.timezone Europe/Helsinki Environment Variables Name ↓ Value G_BROKEN_FILENAMES1 HISTSIZE 1000 HOME /foobar/baz HUDSON_HOME /foobar/jenkins INPUTRC /etc/inputrc JAVA_HOME /foobar/dist/jdk/current JENKINS_HOME /foobar/jenkins JETTYENV_HOME /foobar/baz/env-jetty LANG en_US.UTF-8 LC_ADDRESSfi_FI.UTF-8 LC_ALLfi_FI.utf8 LC_CTYPE fi_FI.UTF-8 LC_IDENTIFICATION fi_FI.UTF-8 LC_MEASUREMENTfi_FI.UTF-8 LC_MONETARY fi_FI.UTF-8 LC_NAME fi_FI.UTF-8 LC_PAPER fi_FI.UTF-8 LC_TELEPHONE fi_FI.UTF-8 LESSOPEN |/usr/bin/lesspipe.sh %s LOGNAME baz LS_COLORS M2_HOME /foobar/dist/maven/current MAIL /var/spool/mail/baz MAVEN_OPTS-XX:+UseCompressedOops -Djava.security.egd=file:///dev/urandom -Xmx512m MVN /foobar/dist/maven/current/bin/mvn NLSPATH /usr/dt/lib/nls/msg/%L/%N.cat PAGER less PATH /opt/CollabNet_Subversion/bin:/opt/CollabNet_Subversion/bin:/foobar/dist/jdk/current/bin:/foobar/dist/maven/current/bin:/foobar/baz/env-jetty/bin:/foobar/baz/env-jetty/dist/jdk/current/bin:/foobar/baz/env-fab/bin:/foobar/baz/env-apache/bin:/foobar/baz/bin:/foobar/baz/python/bin:/foobar/dist/jdk/current/bin:/foobar/dist/maven/current/bin:/opt/CollabNet_Subversion/bin/:/foobar/scala-2.9.1.final/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/symcli/bin PWD /foobar/jenkins READLINK readlink -f SHELL /bin/bash SHLVL 1 SSH_TTY /dev/pts/2 TERM xterm-256color TMP /foobar/baz/scratch TMPDIR
[JIRA] (JENKINS-13178) Auto installation of ssh-slaves install the wrong version of Java. We have configured Jenkins to use Java 6 30u, but it's installing Java 6 16u on Oracle Linux (Redhat).
[ https://issues.jenkins-ci.org/browse/JENKINS-13178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Java updated JENKINS-13178: -- Environment: Windows 2008 Server master to Linux based slave. Alexey: I have the same problem with CentOS Master - CentOS slave. was:Windows 2008 Server master to Linux based slave. Component/s: slave-setup I created a new CentOS slave machine. my master Jenkins server tried installing Java there and failed: it can't parse the Oracle.com website response, which I think is asking to confirm java license before the download. and btw - it is trying to install JDK 1.6_u16 instead of the one located on the master server (1.6_u31). Auto installation of ssh-slaves install the wrong version of Java. We have configured Jenkins to use Java 6 30u, but it's installing Java 6 16u on Oracle Linux (Redhat). - Key: JENKINS-13178 URL: https://issues.jenkins-ci.org/browse/JENKINS-13178 Project: Jenkins Issue Type: Bug Components: slave-setup, ssh-slaves Affects Versions: current Environment: Windows 2008 Server master to Linux based slave. Alexey: I have the same problem with CentOS Master - CentOS slave. Reporter: Sebastien Tardif Assignee: Kohsuke Kawaguchi Auto installation of ssh-slaves via ssh install the wrong version of Java. We have configured Jenkins to use Java 6 30u, but it's installing Java 6 16u on Oracle Linux (Redhat). We see that oracle.com has the version of Java we are expecting to be installed. Log file below, please note that it's even worst, because it even fail installing the too old version of Java. [03/21/12 09:38:04] [SSH] Opening SSH connection to 172.23.8.70:22. [03/21/12 09:38:04] [SSH] Authenticating as root with C:\Users\CISERVER\.ssh\id_rsa. [03/21/12 09:38:04] [SSH] Authentication successful. [03/21/12 09:38:11] [SSH] The remote users environment is: BASH=/bin/bash BASH_ARGC=() BASH_ARGV=() BASH_EXECUTION_STRING=set BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]=3 [1]=2 [2]=25 [3]=1 [4]=release [5]=x86_64-redhat-linux-gnu) BASH_VERSION='3.2.25(1)-release' COLORS=/etc/DIR_COLORS CVS_RSH=ssh DIRSTACK=() EUID=0 GROUPS=() G_BROKEN_FILENAMES=1 HOME=/root HOSTNAME=oxgslcopsda02 HOSTTYPE=x86_64 IFS=$' \t\n' LANG=en_US.UTF-8 LESSOPEN='|/usr/bin/lesspipe.sh %s' LOGNAME=root LS_COLORS= MACHTYPE=x86_64-redhat-linux-gnu MAIL=/var/mail/root OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin PIPESTATUS=([0]=0) PPID=4006 PS4='+ ' PWD=/root SHELL=/bin/bash SHELLOPTS=braceexpand:hashall:interactive-comments SHLVL=1 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass SSH_CLIENT='172.23.8.50 65195 22' SSH_CONNECTION='172.23.8.50 65195 172.23.8.70 22' TERM=dumb UID=0 USER=root _=/etc/bashrc consoletype=serial tmpid=0 [03/21/12 09:38:11] [SSH] Checking java version of java [03/21/12 09:40:20] [SSH] java -version returned 1.4.2. [03/21/12 09:40:20] [SSH] Checking java version of /usr/bin/java [03/21/12 09:40:20] [SSH] /usr/bin/java -version returned 1.4.2. [03/21/12 09:40:20] [SSH] Checking java version of /usr/java/default/bin/java Couldn't figure out the Java version of /usr/java/default/bin/java bash: /usr/java/default/bin/java: No such file or directory [03/21/12 09:40:20] [SSH] Checking java version of /usr/java/latest/bin/java Couldn't figure out the Java version of /usr/java/latest/bin/java bash: /usr/java/latest/bin/java: No such file or directory [03/21/12 09:40:20] [SSH] Checking java version of /usr/local/bin/java Couldn't figure out the Java version of /usr/local/bin/java bash: /usr/local/bin/java: No such file or directory [03/21/12 09:40:20] [SSH] Checking java version of /usr/local/java/bin/java Couldn't figure out the Java version of /usr/local/java/bin/java bash: /usr/local/java/bin/java: No such file or directory [03/21/12 09:40:21] [SSH] Checking java version of /jenkinsslave/jdk/bin/java Couldn't figure out the Java version of /jenkinsslave/jdk/bin/java bash: /jenkinsslave/jdk/bin/java: No such file or directory Linux oxgslcopsda02 2.6.32-300.10.1.el5uek #1 SMP Wed Feb 22 17:37:40 EST 2012 x86_64 x86_64 x86_64 GNU/Linux Installing JDK6u16 hudson.util.IOException2: Could not find any known supported java version in [java, /usr/bin/java, /usr/java/default/bin/java, /usr/java/latest/bin/java, /usr/local/bin/java, /usr/local/java/bin/java, /jenkinsslave/jdk/bin/java], and we also failed to install JDK as a fallback at hudson.plugins.sshslaves.SSHLauncher.resolveJava(SSHLauncher.java:350) at
[JIRA] (JENKINS-13178) slave setup tries to install the wrong JDK version and fails to parse oracle.com website response
[ https://issues.jenkins-ci.org/browse/JENKINS-13178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Java updated JENKINS-13178: -- Summary: slave setup tries to install the wrong JDK version and fails to parse oracle.com website response (was: Auto installation of ssh-slaves install the wrong version of Java. We have configured Jenkins to use Java 6 30u, but it's installing Java 6 16u on Oracle Linux (Redhat).) slave setup tries to install the wrong JDK version and fails to parse oracle.com website response - Key: JENKINS-13178 URL: https://issues.jenkins-ci.org/browse/JENKINS-13178 Project: Jenkins Issue Type: Bug Components: slave-setup, ssh-slaves Affects Versions: current Environment: Windows 2008 Server master to Linux based slave. Alexey: I have the same problem with CentOS Master - CentOS slave. Reporter: Sebastien Tardif Assignee: Kohsuke Kawaguchi Auto installation of ssh-slaves via ssh install the wrong version of Java. We have configured Jenkins to use Java 6 30u, but it's installing Java 6 16u on Oracle Linux (Redhat). We see that oracle.com has the version of Java we are expecting to be installed. Log file below, please note that it's even worst, because it even fail installing the too old version of Java. [03/21/12 09:38:04] [SSH] Opening SSH connection to 172.23.8.70:22. [03/21/12 09:38:04] [SSH] Authenticating as root with C:\Users\CISERVER\.ssh\id_rsa. [03/21/12 09:38:04] [SSH] Authentication successful. [03/21/12 09:38:11] [SSH] The remote users environment is: BASH=/bin/bash BASH_ARGC=() BASH_ARGV=() BASH_EXECUTION_STRING=set BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]=3 [1]=2 [2]=25 [3]=1 [4]=release [5]=x86_64-redhat-linux-gnu) BASH_VERSION='3.2.25(1)-release' COLORS=/etc/DIR_COLORS CVS_RSH=ssh DIRSTACK=() EUID=0 GROUPS=() G_BROKEN_FILENAMES=1 HOME=/root HOSTNAME=oxgslcopsda02 HOSTTYPE=x86_64 IFS=$' \t\n' LANG=en_US.UTF-8 LESSOPEN='|/usr/bin/lesspipe.sh %s' LOGNAME=root LS_COLORS= MACHTYPE=x86_64-redhat-linux-gnu MAIL=/var/mail/root OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin PIPESTATUS=([0]=0) PPID=4006 PS4='+ ' PWD=/root SHELL=/bin/bash SHELLOPTS=braceexpand:hashall:interactive-comments SHLVL=1 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass SSH_CLIENT='172.23.8.50 65195 22' SSH_CONNECTION='172.23.8.50 65195 172.23.8.70 22' TERM=dumb UID=0 USER=root _=/etc/bashrc consoletype=serial tmpid=0 [03/21/12 09:38:11] [SSH] Checking java version of java [03/21/12 09:40:20] [SSH] java -version returned 1.4.2. [03/21/12 09:40:20] [SSH] Checking java version of /usr/bin/java [03/21/12 09:40:20] [SSH] /usr/bin/java -version returned 1.4.2. [03/21/12 09:40:20] [SSH] Checking java version of /usr/java/default/bin/java Couldn't figure out the Java version of /usr/java/default/bin/java bash: /usr/java/default/bin/java: No such file or directory [03/21/12 09:40:20] [SSH] Checking java version of /usr/java/latest/bin/java Couldn't figure out the Java version of /usr/java/latest/bin/java bash: /usr/java/latest/bin/java: No such file or directory [03/21/12 09:40:20] [SSH] Checking java version of /usr/local/bin/java Couldn't figure out the Java version of /usr/local/bin/java bash: /usr/local/bin/java: No such file or directory [03/21/12 09:40:20] [SSH] Checking java version of /usr/local/java/bin/java Couldn't figure out the Java version of /usr/local/java/bin/java bash: /usr/local/java/bin/java: No such file or directory [03/21/12 09:40:21] [SSH] Checking java version of /jenkinsslave/jdk/bin/java Couldn't figure out the Java version of /jenkinsslave/jdk/bin/java bash: /jenkinsslave/jdk/bin/java: No such file or directory Linux oxgslcopsda02 2.6.32-300.10.1.el5uek #1 SMP Wed Feb 22 17:37:40 EST 2012 x86_64 x86_64 x86_64 GNU/Linux Installing JDK6u16 hudson.util.IOException2: Could not find any known supported java version in [java, /usr/bin/java, /usr/java/default/bin/java, /usr/java/latest/bin/java, /usr/local/bin/java, /usr/local/java/bin/java, /jenkinsslave/jdk/bin/java], and we also failed to install JDK as a fallback at hudson.plugins.sshslaves.SSHLauncher.resolveJava(SSHLauncher.java:350) at hudson.plugins.sshslaves.SSHLauncher.launch(SSHLauncher.java:288) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at
[JIRA] (JENKINS-8617) cannot customize security group to launch slaves into
[ https://issues.jenkins-ci.org/browse/JENKINS-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162627#comment-162627 ] mwhudson commented on JENKINS-8617: --- I'm not sure really -- and I'm not administering Jenkins myself any more, so I'm might not to be able to contribute any useful thinking here. IIRC, one of the reasons I wanted to put it onto the cloud was that I wanted to be able to count the instances Jenkins has launched by checking the security group. We've had issues where Jenkins has refused to launch instances because there have been other instances launched by the same account and they are currently counted against the cap. If the jenkins-launched instances had a distinct security group, a more accurate count of how many instances have been launched by jenkins would be possible.' cannot customize security group to launch slaves into - Key: JENKINS-8617 URL: https://issues.jenkins-ci.org/browse/JENKINS-8617 Project: Jenkins Issue Type: Improvement Components: ec2 Reporter: mwhudson Assignee: mwhudson Priority: Minor It's slightly inconvenient to have to use the 'default' security group for our slaves. It's only slightly inconvenient, but it seems that this should be pretty easy to fix, too. I may even try myself! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11267) no (easy) way to make a sonar analysis on maven released version
[ https://issues.jenkins-ci.org/browse/JENKINS-11267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162628#comment-162628 ] Sedat Guclu commented on JENKINS-11267: --- Hi, Is there a chance to see this case taken into account in a future release? no (easy) way to make a sonar analysis on maven released version Key: JENKINS-11267 URL: https://issues.jenkins-ci.org/browse/JENKINS-11267 Project: Jenkins Issue Type: Improvement Components: sonar Affects Versions: current Reporter: Sedat Guclu Assignee: sonarteam There is no way to invoke the sonar plugin on a new maven released version (from freestyle/maven jobs, and even from the m2 release plugin): the sonar plugin uses the pom file found for the previous job steps and not the released one ( found in target/checkout by default). Even -f or --file parameters on sonar plugin config are ignored because they are set after the previous one, and perform's checkoutDirectory cannot be set on the workspace dir. It is very annoying because, in my organisation, we want to set release job templates with automatic sonar invokation on the released version on a same job (which, in my mind, is an absolute need for customer delivered components). The generate report shows then the next development version in sonar. Additionally, we do not want to put sonar configs in pom or other because the sonar instances' configs are better centralized then in jenkins. The only (VERY ugly) workaround I found was to use the M2 extra steps plugin and override the workspace's root pom by the released one before the sonar invokation... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9658) Get NPE when trying to add user in matrix-based security
[ https://issues.jenkins-ci.org/browse/JENKINS-9658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] evernat resolved JENKINS-9658. -- Resolution: Duplicate It appears to be a duplicate of JENKINS-9520 which is fixed. So resolving as duplicate. Please reopen if not. Get NPE when trying to add user in matrix-based security Key: JENKINS-9658 URL: https://issues.jenkins-ci.org/browse/JENKINS-9658 Project: Jenkins Issue Type: Bug Components: security Affects Versions: current Environment: Windows server 2003 enterprise edition. Running Jenkins 1.411 in Tomcat 7.0.8 Reporter: raj n In /jenkins/configure. Under access control Jenkin's own database Authorization Matrix-based security enter MyUser click add. The following error is thrown. HTTP 500 javax.servlet.ServletException: java.lang.NullPointerException org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:603) org.kohsuke.stapler.Stapler.invoke(Stapler.java:646) org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:233) org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561) org.kohsuke.stapler.Stapler.invoke(Stapler.java:646) org.kohsuke.stapler.Stapler.invoke(Stapler.java:477) org.kohsuke.stapler.Stapler.service(Stapler.java:159) javax.servlet.http.HttpServlet.service(HttpServlet.java:722) hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94) hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86) hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) root cause java.lang.NullPointerException hudson.security.GlobalMatrixAuthorizationStrategy$DescriptorImpl.doCheckName(GlobalMatrixAuthorizationStrategy.java:291) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) java.lang.reflect.Method.invoke(Unknown Source) org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282) org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149) org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88) org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:103) org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561) org.kohsuke.stapler.Stapler.invoke(Stapler.java:646) org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:233) org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561) org.kohsuke.stapler.Stapler.invoke(Stapler.java:646) org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)
[JIRA] (JENKINS-8916) Allowing same type of parameter for triggered build more than once seems redundant
[ https://issues.jenkins-ci.org/browse/JENKINS-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162630#comment-162630 ] SCM/JIRA link daemon commented on JENKINS-8916: --- Code changed in jenkins User: Fred G Path: src/main/resources/hudson/plugins/parameterizedtrigger/BlockableBuildTriggerConfig/config.jelly src/main/resources/hudson/plugins/parameterizedtrigger/BuildTriggerConfig/config.jelly http://jenkins-ci.org/commit/parameterized-trigger-plugin/3f6097a82679a76d8b0b03498d9c9a392b77f6fc Log: [FIXED JENKINS-8916] Allowing same type of parameter for triggered build more than once seems redundant It requires Jenkins core version 1.463 to work, but it's fully backwards compatible. Allowing same type of parameter for triggered build more than once seems redundant -- Key: JENKINS-8916 URL: https://issues.jenkins-ci.org/browse/JENKINS-8916 Project: Jenkins Issue Type: Bug Components: parameterized-trigger Affects Versions: current Reporter: Fred G Assignee: Fred G Priority: Minor While working on [JENKINS-7377] I noticed that it's redundant and confusing to allow the same type of parameter for a triggered build more than once. For example, right now it's possible to specify Current Build Parameters, or Subversion Revision two or more times. The only type where it might make sense is Parameters from properties file. I think for every type of parameters a simple checkbox is sufficient. I'll try to make the necessary changes and open a pull request, but appreciate comments or criticism. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8916) Allowing same type of parameter for triggered build more than once seems redundant
[ https://issues.jenkins-ci.org/browse/JENKINS-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-8916. --- Resolution: Fixed Allowing same type of parameter for triggered build more than once seems redundant -- Key: JENKINS-8916 URL: https://issues.jenkins-ci.org/browse/JENKINS-8916 Project: Jenkins Issue Type: Bug Components: parameterized-trigger Affects Versions: current Reporter: Fred G Assignee: Fred G Priority: Minor While working on [JENKINS-7377] I noticed that it's redundant and confusing to allow the same type of parameter for a triggered build more than once. For example, right now it's possible to specify Current Build Parameters, or Subversion Revision two or more times. The only type where it might make sense is Parameters from properties file. I think for every type of parameters a simple checkbox is sufficient. I'll try to make the necessary changes and open a pull request, but appreciate comments or criticism. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8916) Allowing same type of parameter for triggered build more than once seems redundant
[ https://issues.jenkins-ci.org/browse/JENKINS-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162631#comment-162631 ] SCM/JIRA link daemon commented on JENKINS-8916: --- Code changed in jenkins User: Fred G Path: src/main/resources/hudson/plugins/parameterizedtrigger/BlockableBuildTriggerConfig/config.jelly src/main/resources/hudson/plugins/parameterizedtrigger/BuildTriggerConfig/config.jelly http://jenkins-ci.org/commit/parameterized-trigger-plugin/6e80ae37591b708b321b27a80a8d32012949f6a0 Log: Merge pull request #20 from fredg02/master [FIXED JENKINS-8916] Allowing same type of parameter for triggered build more than once seems redundant Compare: https://github.com/jenkinsci/parameterized-trigger-plugin/compare/76d4c9b...6e80ae3 Allowing same type of parameter for triggered build more than once seems redundant -- Key: JENKINS-8916 URL: https://issues.jenkins-ci.org/browse/JENKINS-8916 Project: Jenkins Issue Type: Bug Components: parameterized-trigger Affects Versions: current Reporter: Fred G Assignee: Fred G Priority: Minor While working on [JENKINS-7377] I noticed that it's redundant and confusing to allow the same type of parameter for a triggered build more than once. For example, right now it's possible to specify Current Build Parameters, or Subversion Revision two or more times. The only type where it might make sense is Parameters from properties file. I think for every type of parameters a simple checkbox is sufficient. I'll try to make the necessary changes and open a pull request, but appreciate comments or criticism. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-850) search box should match non-casesensitively
[ https://issues.jenkins-ci.org/browse/JENKINS-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] garethbowles reopened JENKINS-850: -- Assignee: dogfood Still not working for me in Jenkins 1.462, which was release on 4/30/12 (well after the fix was committed). search box should match non-casesensitively --- Key: JENKINS-850 URL: https://issues.jenkins-ci.org/browse/JENKINS-850 Project: Jenkins Issue Type: Improvement Components: www Affects Versions: current Environment: Platform: All, OS: All Reporter: gradopado Assignee: dogfood The search box would be even more useful if it would match text non-casesensitively. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13719) CVS Updates are not reflected
[ https://issues.jenkins-ci.org/browse/JENKINS-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mitesh shah resolved JENKINS-13719. --- Resolution: Not A Defect CVS Updates are not reflected - Key: JENKINS-13719 URL: https://issues.jenkins-ci.org/browse/JENKINS-13719 Project: Jenkins Issue Type: Bug Components: cvs Environment: Fedora -15 , 32-bit Reporter: Mitesh shah I used a Test Project in which I changed some files and committed into CVS(Set up on local machine). On cvs console it shows new revision number. But when I do build it doesn't show any changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12664) Can't start jenkins after upgrade from 1.441 to 1.450
[ https://issues.jenkins-ci.org/browse/JENKINS-12664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162633#comment-162633 ] ng at commented on JENKINS-12664: - I have similar problem when i install a new plugin Here how i solved the problem 1. goto jenkins home cd /var/lib/jenkins 2. move all the files into tmp directory mkdir tmp mv plugins *.xml *.key tmp 3. start jenkins 4. after that move one by one xml from tmp see which causing the problem Can't start jenkins after upgrade from 1.441 to 1.450 - Key: JENKINS-12664 URL: https://issues.jenkins-ci.org/browse/JENKINS-12664 Project: Jenkins Issue Type: Bug Components: ssh Affects Versions: current Environment: FreeBSD 8.2, jvm version 1.6.0_24-b07, tomcat 7.0.22 Reporter: Bruno Ribeiro da Silva Priority: Critical After deploy the new version of jenkins, I got an error while jenkins was starting, looking at catalina.out I got this: INFO: Deploying web application archive jenkins.war Jenkins home directory: /usr/home/jenkins found at: System.getProperty(JENKINS_HOME) Feb 7, 2012 9:43:56 AM org.apache.catalina.core.ApplicationContext log INFO: HTMLManager: list: Listing contexts for virtual host 'localhost' Feb 7, 2012 9:43:57 AM jenkins.InitReactorRunner$1 onAttained INFO: Started initialization Feb 7, 2012 9:43:57 AM jenkins.InitReactorRunner$1 onAttained INFO: Listed all plugins Feb 7, 2012 9:43:57 AM jenkins.InitReactorRunner$1 onAttained INFO: Prepared all plugins SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder. SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. Feb 7, 2012 9:44:02 AM jenkins.InitReactorRunner$1 onAttained INFO: Started all plugins Feb 7, 2012 9:44:02 AM jenkins.InitReactorRunner$1 onAttained INFO: Augmented all extensions Feb 7, 2012 9:44:02 AM jenkins.InitReactorRunner$1 onAttained INFO: Loaded all jobs Feb 7, 2012 9:44:02 AM jenkins.InitReactorRunner$1 onTaskFailed SEVERE: Failed SSHD.init java.lang.Error: java.lang.reflect.InvocationTargetException at hudson.init.InitializerFinder.invoke(InitializerFinder.java:124) at hudson.init.InitializerFinder$TaskImpl.run(InitializerFinder.java:184) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at jenkins.model.Jenkins$5.runTask(Jenkins.java:812) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94) 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) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at hudson.init.InitializerFinder.invoke(InitializerFinder.java:120) ... 8 more Caused by: java.lang.NullPointerException at org.apache.mina.core.service.SimpleIoProcessorPool.dispose(SimpleIoProcessorPool.java:289) at org.apache.mina.core.service.SimpleIoProcessorPool.init(SimpleIoProcessorPool.java:229) at org.apache.mina.core.service.SimpleIoProcessorPool.init(SimpleIoProcessorPool.java:123) at org.apache.mina.core.polling.AbstractPollingIoAcceptor.init(AbstractPollingIoAcceptor.java:125) at org.apache.mina.transport.socket.nio.NioSocketAcceptor.init(NioSocketAcceptor.java:78) at org.apache.sshd.SshServer.createAcceptor(SshServer.java:392) at org.apache.sshd.SshServer.start(SshServer.java:338) at org.jenkinsci.main.modules.sshd.SSHD.start(SSHD.java:102) at org.jenkinsci.main.modules.sshd.SSHD.init(SSHD.java:133) ... 13 more Feb 7, 2012 9:44:02 AM hudson.WebAppMain$2 run SEVERE: Failed to initialize Jenkins org.jvnet.hudson.reactor.ReactorException: java.lang.Error: java.lang.reflect.InvocationTargetException at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246) at jenkins.InitReactorRunner.run(InitReactorRunner.java:43) at jenkins.model.Jenkins.executeReactor(Jenkins.java:823) at jenkins.model.Jenkins.init(Jenkins.java:735) at hudson.model.Hudson.init(Hudson.java:81) at hudson.model.Hudson.init(Hudson.java:77) at hudson.WebAppMain$2.run(WebAppMain.java:217) Caused by: java.lang.Error:
