[JIRA] (JENKINS-14288) thinBackup doesn't put back the current shutdown flag after backing up
Thomas Fürer commented on JENKINS-14288 thinBackup doesnt put back the current shutdown flag after backing up I'm a bit confused. Please correct me if I am wrong. Your problem is that jenkins is set to shutdown not via thinbackup but some mechanism outside of thinbackup (e.g. manually, as you describted in your last post), and you would have jenkins still be in shutdown also after a successful backup. Am I right? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14497) Can't start emulator with new Android SDK Tools rev. 20.0.1
Simon Strauch
commented on JENKINS-14497
Cant start emulator with new Android SDK Tools rev. 20.0.1
I tried applying the Integer.parseInt() and the fall-back with the RegEx to the String "16" of this change. It works, both return the number 16.
java.util.regex.Pattern REVISION = java.util.regex.Pattern.compile("(\\d+)(?:\\.\\d+){0,2}");
java.util.regex.Matcher m = REVISION.matcher("16");
m.matches(); // return true
String num = m.group(1); // num is "16"
return Integer.parseInt(num); // returns 16
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14288) thinBackup doesn't put back the current shutdown flag after backing up
Thomas Fürer started work on JENKINS-14288 thinBackup doesnt put back the current shutdown flag after backing up Change By: Thomas Fürer (25/Jul/12 8:33 AM) Status: Open InProgress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14214) Scm-Sync-Configuration should commit things asynchronously
Frédéric Camblor started work on JENKINS-14214 Scm-Sync-Configuration should commit things asynchronously Change By: Frédéric Camblor (25/Jul/12 8:34 AM) Status: Open InProgress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13613) scm_sync_configuration may commit bulk changes in one change set
Frédéric Camblor started work on JENKINS-13613 scm_sync_configuration may commit bulk changes in one change set Change By: Frédéric Camblor (25/Jul/12 8:38 AM) Status: Open InProgress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13619) Add ability to throttle number of concurrent builds of matrix configurations per node
Adam PAPAI commented on JENKINS-13619 Add ability to throttle number of concurrent builds of matrix configurations per node Do we have any improvements on this? We also need no throttle our matrix jobs. Is there something I can help? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14288) thinBackup doesn't put back the current shutdown flag after backing up
Thomas Fürer resolved JENKINS-14288 as Fixed thinBackup doesnt put back the current shutdown flag after backing up Change By: Thomas Fürer (25/Jul/12 8:49 AM) Status: InProgress Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-2548) Node does not come back online after disk space cleared
Marc Günther commented on JENKINS-2548 Node does not come back online after disk space cleared @kolos: we are using swarm clients, and all I need to do is press the "bring this node back online" button. I have to do this all the time, and I never had to restart Jenkins. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14288) thinBackup doesn't put back the current shutdown flag after backing up
Thomas Fürer commented on JENKINS-14288 thinBackup doesnt put back the current shutdown flag after backing up In reply to comment #5: That's correct. sorry for the delay. I was simply confused, but it was a simple fix. I just committed a change. I will also try to push a new release but I need to do some testing before. so please hold on. thomas This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13613) scm_sync_configuration may commit bulk changes in one change set
Frédéric Camblor commented on JENKINS-13613 scm_sync_configuration may commit bulk changes in one change set I'm going to refactor the way the plugin is behaving concerning commits. For the moment, it detects a change on a Saveable object and, each time, make a commit on the file concerned by this change. You have to note that a Saveable is always attached to a file, but a file can be concerned by several Saveable (ie: descriptors) This is the reason why, when, for instance, you persist the jenkins system configuration screen, lots of commit will be made : every plugin which has a Descriptor on system configuration data, will be saved separately = each save will make a commit. This is the point of the issue. What I'm going to do to address this problem : I'll implement a PluginServletFilter that will initialize, for every requests, an empty Changeset in the beginning of the request. This Changeset will be stored in a ThreadLocal. Then, request will be processed normally Then, when request process ends, the PluginServletFilter will look at the Changeset and, if it isn't empy, it will commit every changes in this one, in only one commit. Now, some more technical inputs : Everytime a Saveable will be saved, instead of synchronizing the underlying file, current Saveable's file content will be added into the ThreadLocal's Changeset A Changeset will be made of a MapfilePath, contentOfFile. Thus, if multiple Saveable work in the same file, they will override same Changeset entry each time the Saveable is saved. I hope the byte[] won't consume too much memory... This Changeset representation will avoid collision on file save : 2 users edit the global jenkins configuration page 1st user submit the page, it takes a long time to synchronize... 2nd user submit the page, it modifies the config.xml before synchronization of 1st user is finished = changes of 2nd user will be commited during 1st user commit Commit could then be made asynchronously, but this is another point (see JENKINS-14214) I think by doing such a refactoring, I could fix problems like JENKINS-10967 and JENKINS-9166 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13613) scm_sync_configuration may commit bulk changes in one change set
Frédéric Camblor updated JENKINS-13613 scm_sync_configuration may commit bulk changes in one change set Change By: Frédéric Camblor (25/Jul/12 9:03 AM) Priority: Minor Major This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12825) Allow expansion of environment variables in the configuration
Rainer Weinhold commented on JENKINS-12825 Allow expansion of environment variables in the configuration +1 Would love to have this. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14103) Grails 2.0.4 not listed in installer doropdown
Jeroen Wesbeek commented on JENKINS-14103 Grails 2.0.4 not listed in installer doropdown Any progress on this, as this is a blocking issue for everybody using Grails with Jenkins? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14103) Grails 2.0.4 not listed in installer doropdown
Jeroen Wesbeek edited a comment on JENKINS-14103 Grails 2.0.4 not listed in installer doropdown Any progress on this, as this is a blocking issue for everybody using Grails with Jenkins? The latest Grails release (2.1.0) is also missing... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14103) Grails 2.0.4 not listed in installer doropdown
Jeroen Wesbeek edited a comment on JENKINS-14103 Grails 2.0.4 not listed in installer doropdown Any progress on this? This is a blocking issue for everybody using Grails with Jenkins? The latest Grails release (2.1.0) is also missing... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12098) FileNotFoundException causes backup process to terminate
Thomas Fürer resolved JENKINS-12098 as Fixed FileNotFoundException causes backup process to terminate Change By: Thomas Fürer (25/Jul/12 10:41 AM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13906) Android emulator plugin doesn't work if multiple ABI's are installed
Christopher Orr closed JENKINS-13906 as Fixed Android emulator plugin doesnt work if multiple ABIs are installed Version 2.3 of the plugin has been released, which fixes this issue. Change By: Christopher Orr (25/Jul/12 10:56 AM) Status: Resolved Closed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14497) Can't start emulator with new Android SDK Tools rev. 20.0.1
Christopher Orr closed JENKINS-14497 as Fixed Cant start emulator with new Android SDK Tools rev. 20.0.1 Version 2.3 of the plugin has been released, which fixes this issue. Change By: Christopher Orr (25/Jul/12 10:56 AM) Status: Resolved Closed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14103) Grails 2.0.4 not listed in installer doropdown
Jeroen Wesbeek edited a comment on JENKINS-14103 Grails 2.0.4 not listed in installer doropdown Any progress on this? This is a blocking issue for everybody using Grails with Jenkins? The latest Grails release (2.1.0) is also missing... Temporary workaround on the server running Jenkins: Pull request which disables logging to get rid of the 'severe' and 'warning' messages. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14103) Grails 2.0.4 not listed in installer doropdown
Jeroen Wesbeek edited a comment on JENKINS-14103 Grails 2.0.4 not listed in installer doropdown Any progress on this? This is a blocking issue for everybody using Grails with Jenkins? The latest Grails release (2.1.0) is also missing... Temporary workaround on the server running Jenkins: tomcat@nmcdsp ~ $ cd /tmp tomcat@nmcdsp /tmp $ wget --no-check-certificate https://raw.github.com/4np/backend-crawler/master/grails.groovy ... tomcat@nmcdsp /tmp $ groovy grails.groovy ~/.jenkins/updates/com.g2one.hudson.grails.GrailsInstaller Pull request which disables logging to get rid of the 'severe' and 'warning' messages. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14103) Grails 2.0.4 not listed in installer doropdown
Jeroen Wesbeek edited a comment on JENKINS-14103 Grails 2.0.4 not listed in installer doropdown Any progress on this? This is a blocking issue for everybody using Grails with Jenkins? The latest Grails release (2.1.0) is also missing... Temporary workaround on the server running Jenkins: tomcat@nmcdsp ~ $ cd /tmp tomcat@nmcdsp /tmp $ wget --no-check-certificate https://raw.github.com/4np/backend-crawler/master/grails.groovy ... tomcat@nmcdsp /tmp $ groovy grails.groovy ~/.jenkins/updates/com.g2one.hudson.grails.GrailsInstaller And configure the new Grails version in your jenkins configuration. Pull request which disables logging to get rid of the 'severe' and 'warning' messages. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14103) Grails 2.0.4 not listed in installer doropdown
Jeroen Wesbeek edited a comment on JENKINS-14103 Grails 2.0.4 not listed in installer doropdown Any progress on this? This is a blocking issue for everybody using Grails with Jenkins. The latest Grails release (2.1.0) is also missing... Temporary workaround on the server running Jenkins: tomcat@nmcdsp ~ $ cd /tmp tomcat@nmcdsp /tmp $ wget --no-check-certificate https://raw.github.com/4np/backend-crawler/master/grails.groovy ... tomcat@nmcdsp /tmp $ groovy grails.groovy ~/.jenkins/updates/com.g2one.hudson.grails.GrailsInstaller And configure the new Grails version in your jenkins configuration. Pull request which disables logging to get rid of the 'severe' and 'warning' messages. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10747) Search result limit hard-coded to 20
SCM/JIRA link daemon commented on JENKINS-10747 Search result limit hard-coded to 20 Code changed in jenkins User: Nicolas De Loof Path: core/src/main/java/hudson/search/Search.java core/src/main/java/hudson/search/SearchResult.java core/src/main/resources/hudson/search/Search/search-failed.jelly http://jenkins-ci.org/commit/jenkins/45a3886760999c13fc963babc7a25ebacb63e123 Log: FIXED JENKINS-10747 notify user some results have been truncated provide link to get more results This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10747) Search result limit hard-coded to 20
SCM/JIRA link daemon resolved JENKINS-10747 as Fixed Search result limit hard-coded to 20 Change By: SCM/JIRA link daemon (25/Jul/12 11:35 AM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-2907) Search should provide way to navigate to all search results
Nicolas De Loof resolved JENKINS-2907 as Fixed Search should provide way to navigate to all search results see JENKINS-10747 fixed in 1.477 Change By: Nicolas De Loof (25/Jul/12 11:39 AM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12173) thinBackup does not include build results for matrix projects when nodes axis is used
Thomas Fürer started work on JENKINS-12173 thinBackup does not include build results for matrix projects when nodes axis is used Change By: Thomas Fürer (25/Jul/12 11:45 AM) Status: Open InProgress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14564) Stop SCM Sync Configuration if error
Julien Carsique created JENKINS-14564 Stop SCM Sync Configuration if error Issue Type: Improvement Assignee: Frédéric Camblor Components: scm-sync-configuration Created: 25/Jul/12 11:53 AM Description: As explained in JENKINS-14506, when the URL fails at login (not for commit but for pull/push), the Jenkins server becomes unresponsive (I had to manually kill the git processes). The plugin should stop its commits resistivity in case of such a failure. Project: Jenkins Priority: Major Reporter: Julien Carsique This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14565) Please add support for Cloudbees folder structure
Roger Myung created JENKINS-14565 Please add support for Cloudbees folder structure Issue Type: Improvement Assignee: Unassigned Components: build-pipeline Created: 25/Jul/12 11:56 AM Description: We are using Cloudbees folders. I tried using the Build Pipeline plugin. I'm able to select my job from the drop-down, but the pipeline view does not show any of the downstream jobs, unless I create all the jobs at the base level (not in a folder). Project: Jenkins Priority: Major Reporter: Roger Myung This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14566) Missing configuration in SCM Sync Configuration
Julien Carsique created JENKINS-14566 Missing configuration in SCM Sync Configuration Issue Type: Bug Assignee: Frédéric Camblor Components: scm-sync-configuration Created: 25/Jul/12 11:58 AM Description: As explained in JENKINS-14506, in some cases, the available configuration from the Jenkins administration screen is not enough. I had to manually set user.email and user.name values on the local repository created by the plugin, being logged on the master server. It should be configurable from Jenkins UI. Moreover, that issue means we have to undergo with a first recursive issue (see JENKINS-14564) for the repository being created before being able to manually fix it. Project: Jenkins Priority: Major Reporter: Julien Carsique This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14566) Missing configuration in SCM Sync Configuration
Julien Carsique assigned JENKINS-14566 to Bertrand Paquet Missing configuration in SCM Sync Configuration Change By: Julien Carsique (25/Jul/12 11:59 AM) Assignee: FrédéricCamblor BertrandPaquet This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14564) Stop SCM Sync Configuration if error
Julien Carsique assigned JENKINS-14564 to Bertrand Paquet Stop SCM Sync Configuration if error Change By: Julien Carsique (25/Jul/12 11:59 AM) Assignee: FrédéricCamblor BertrandPaquet This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14567) Add a test button to SCM Sync Configuration
Julien Carsique created JENKINS-14567 Add a test button to SCM Sync Configuration Issue Type: New Feature Assignee: Frédéric Camblor Components: scm-sync-configuration Created: 25/Jul/12 12:01 PM Description: Add a "test" button in the configuration to avoid starting initialization with repetitive failures. Project: Jenkins Priority: Minor Reporter: Julien Carsique This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14506) SCM Sync Configuration mess with Git authentication
Julien Carsique commented on JENKINS-14506 SCM Sync Configuration mess with Git authentication Created related issues. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13754) Error when compiling a plugin against jenkins version 1.463
Shai Ben-Hur commented on JENKINS-13754 Error when compiling a plugin against jenkins version 1.463 Also an issue in Jenkins 1.475 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
UNSUBSCRIBE
Martin Schoepf - Software Testing TTTech Computertechnik AG - Ensuring Reliable Networks Commercial Reg. No.: 165 664z, Commercial Court Vienna Schoenbrunner Strasse 7, A-1040 Vienna, Austria Phone: +43 1 585 34 34-46, Fax: +43 1 585 34 34-90 martin.scho...@tttech.com, http://www.tttech.com ___ CONFIDENTIALITY: The contents of this e-mail are confidential and intended only for the above addressee(s). If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, copying or delivering it to anyone else or using it in any unauthorized manner is prohibited and may be unlawful. If you receive this e-mail by mistake, please notify the sender and the systems administrator at straym...@tttech.com immediately.
[JIRA] (JENKINS-14506) SCM Sync Configuration mess with Git authentication
Frédéric Camblor commented on JENKINS-14506 SCM Sync Configuration mess with Git authentication @Julien I think you're right concerning the lack of extractScmCredentials() implementation. Problem is known by Bertrand. Authentication is mostly one of the more difficult part in implementing a new SCM implementation in scm-sync-configuration. Even I, with subversion implementation, am not able to fulfill every cases (see JENKINS-8871) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10747) Search result limit hard-coded to 20
dogfood commented on JENKINS-10747 Search result limit hard-coded to 20 Integrated in jenkins_main_trunk #1817 FIXED JENKINS-10747 (Revision 45a3886760999c13fc963babc7a25ebacb63e123) Result = UNSTABLE Nicolas De Loof : 45a3886760999c13fc963babc7a25ebacb63e123 Files : core/src/main/resources/hudson/search/Search/search-failed.jelly core/src/main/java/hudson/search/Search.java core/src/main/java/hudson/search/SearchResult.java This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-4029) Maven 2 Extra Steps does not use private Maven repository if set on project
radaczynski commented on JENKINS-4029 Maven 2 Extra Steps does not use private Maven repository if set on project @abayer: why then there is a checkbox in the UI for the pre build steps that says "Use private Maven repository". I think the checkbox should be either removed or made to work. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-4029) Maven 2 Extra Steps does not use private Maven repository if set on project
radaczynski reopened JENKINS-4029 Maven 2 Extra Steps does not use private Maven repository if set on project as per comment - there is still a checkbox in the ui that states "use private maven repository", which should be removed. Change By: radaczynski (25/Jul/12 12:33 PM) Resolution: WontFix Status: Closed Reopened This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14568) Improve commit messages from SCM Sync Configuration
Frédéric Camblor commented on JENKINS-14568 Improve commit messages from SCM Sync Configuration Displaying the job name will be complicated since I am unaware of Saveable implementation current file is related on. I could add the file path in the commit message, but would it be really useful ? Afterall, if you're seeing the commit message, you should be able to see the changeset related to this commit isn't it ? Moreover, it will collide with JENKINS-13613 since I'm going to change scm-sync-configuration commit policy if future release : instead of having 1 file modification change = 1 commit, I'll have several modification changes on several files = 1 commit. So, dusplaying modified file in commit message will be totally useless. WDYT ? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14568) Improve commit messages from SCM Sync Configuration
Frédéric Camblor edited a comment on JENKINS-14568 Improve commit messages from SCM Sync Configuration Displaying the job name will be complicated since I am unaware of Saveable implementation current file is related on. I could add the file path in the commit message, but would it be really useful ? Afterall, if you're seeing the commit message, you should be able to see the changeset related to this commit shouldn't you ? Moreover, it will collide with JENKINS-13613 since I'm going to change scm-sync-configuration commit policy in future release : instead of having 1 file modification change = 1 commit, I'll have several modification changes on several files = 1 commit. So, displaying modified file(s) in commit message will be totally useless. WDYT ? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-6624) Add an option in the configuration of a job to not participate th the relationship between jobs (maven projects)
drautureau commented on JENKINS-6624 Add an option in the configuration of a job to not participate th the relationship between jobs (maven projects) Yes, you're right This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7501) POST'ing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc)
jglick commented on JENKINS-7501 POSTing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc) Confirmed that this is broken in Jenkins dev for both creating and modifying jobs, though they seem to use different code paths: curl -d @config.xml -H 'Content-Type: text/xml' 'http://localhost:8080/createItem?name=new' curl -d @config.xml http://localhost:8080/job/existing/config.xml This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7501) POST'ing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc)
jglick edited a comment on JENKINS-7501 POSTing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc) Confirmed that this is broken in Jenkins dev for both creating and modifying jobs, though they seem to use different code paths: curl -d @config.xml -H 'Content-Type: text/xml' 'http://localhost:8080/createItem?name=new' curl -d @config.xml http://localhost:8080/job/existing/config.xml This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14568) Improve commit messages from SCM Sync Configuration
Julien Carsique commented on JENKINS-14568 Improve commit messages from SCM Sync Configuration The file path is enough (and contains the job's name). It would be really useful: I'm working with about 400 jobs (https://qa.nuxeo.org/jenkins/). With so much jobs, developers need the ability to configure jobs themselves, even if I may have to review them latter. I setup an email notification on the Git repository dedicated to SCM Sync Conf (but the readability issue is also true when directly looking at the repository commits history). Because of the current generic message, I cannot quickly review changes: the commits history gives no information and the emails are all threaded together per user (since it's the only information which varies); I have to look at the details for every commit to know which job is involved, that allows unperceived changes on sensible jobs. If I properly understood JENKINS-13613, it will still build a changeset per file/job gathering related Saveable objects instead of generating a commit per object. So it doesn't collide with the current issue: we'll still need to distinguish changesets thanks to their commit message and the related file will be the same for a given changeset (as you wrote: A Changeset will be made of a MapfilePath, contentOfFile. Thus, if multiple Saveable work in the same file, they will override same Changeset entry each time the Saveable is saved.). What do you mean with several modification changes on several files = 1 commit ? If I misunderstood and you plan to build a unique changeset for multiple changes on multiple jobs, I guess it makes no sense and reduces readability: what about if we need to revert some change on a job or if some people are responsible of reviewing changes on a given group of jobs? Avoiding multiple commits for a single change on a given job is a nice improvement though. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7501) POST'ing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc)
jglick resolved JENKINS-7501 as Not A Defect POSTing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc) In fact Jenkins is working fine. The problem is in your script: you need to use -data-binary rather than -data. Change By: jglick (25/Jul/12 1:11 PM) Status: Open Resolved Resolution: NotADefect This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14465) Buttons and lists don't work as expected
Eyal Zfira commented on JENKINS-14465 Buttons and lists dont work as expected Also happening in 'Publish Over SSH', 'Sectioned View' 'Promoted builds' plugins Very annoying... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14114) CPU on 100% when sending mail
Cees Bos commented on JENKINS-14114 CPU on 100% when sending mail Lately we did not face this issue anymore. We faced this issue with a very large sync-merge (after a very large drop-merge of another team). The commit message of the sync-merge drop-merge contained all committed in the branch. The size of the commit message was more the 1Mb. I guess that change history XML is parsed and that took a lot of time. Maybe it is possible to create a change XML without commit messages itself (only committer info). That makes parsing of the XML much faster. We use SVN. Only thread information I have is in the screenshot attached to this ticket. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14552) Cannot plublish cobertura reports if org.codehaus.mojo:cobertura-maven-plugin is not invoked
Miguel Almeida commented on JENKINS-14552 Cannot plublish cobertura reports if org.codehaus.mojo:cobertura-maven-plugin is not invoked This might be related, but in 1.5 the plugin is not producing the reports. Details: Multi-module project Maven project Goal: install Post-steps: cobertura:cobertura Result: No coverage report produced (xml is in the workspace) 1 Same setup, plugin version 1.3: Coverage report produced correctly 2 1 INFO Cobertura Report generation was successful. INFO Cobertura 1.9.4.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file Cobertura: Loaded information on 53 classes. Report time: 1670ms INFO Cobertura Report generation was successful. INFO INFO Reactor Summary: INFO INFO Parent .. SUCCESS 2.882s INFO Model .. SUCCESS 5.370s INFO Web . SUCCESS 33.970s INFO INFO BUILD SUCCESS INFO INFO Total time: 2:40.478s INFO Finished at: Wed Jul 25 13:08:43 WEST 2012 INFO Final Memory: 14M/35M INFO Archiving workspace Deleting old workspace snapshot from #412. Skipping Cobertura coverage report as mojo did not run. Finished: SUCCESS 2 INFO Cobertura Report generation was successful. INFO Cobertura 1.9.4.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file Cobertura: Loaded information on 53 classes. Report time: 2237ms INFO Cobertura Report generation was successful. INFO INFO Reactor Summary: INFO INFO Parent .. SUCCESS 6.470s INFO Model ... SUCCESS 5.247s INFO Web . SUCCESS 28.529s INFO INFO BUILD SUCCESS INFO INFO Total time: 2:28.671s INFO Finished at: Wed Jul 25 14:35:39 WEST 2012 INFO Final Memory: 14M/36M INFO Archiving workspace Deleting old workspace snapshot from #413. Publishing Cobertura coverage report... Publishing Cobertura coverage results... Finished: SUCCESS This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14552) Cannot plublish cobertura reports if org.codehaus.mojo:cobertura-maven-plugin is not invoked
Miguel Almeida edited a comment on JENKINS-14552 Cannot plublish cobertura reports if org.codehaus.mojo:cobertura-maven-plugin is not invoked I don't know what the OP meant with "the cobertura-maven-plugin is not invoked:". However, in 1.5 the plugin is not producing the reports for a multi-module maven project of mine. Details: Multi-module project Maven project Goal: install Post-steps: cobertura:cobertura Result: No coverage report produced (xml is in the workspace) 1 Same setup, plugin version 1.3: Coverage report produced correctly 2 1 INFO Cobertura Report generation was successful. INFO Cobertura 1.9.4.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file Cobertura: Loaded information on 53 classes. Report time: 1670ms INFO Cobertura Report generation was successful. INFO INFO Reactor Summary: INFO INFO Parent .. SUCCESS 2.882s INFO Model .. SUCCESS 5.370s INFO Web . SUCCESS 33.970s INFO INFO BUILD SUCCESS INFO INFO Total time: 2:40.478s INFO Finished at: Wed Jul 25 13:08:43 WEST 2012 INFO Final Memory: 14M/35M INFO Archiving workspace Deleting old workspace snapshot from #412. Skipping Cobertura coverage report as mojo did not run. Finished: SUCCESS 2 INFO Cobertura Report generation was successful. INFO Cobertura 1.9.4.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file Cobertura: Loaded information on 53 classes. Report time: 2237ms INFO Cobertura Report generation was successful. INFO INFO Reactor Summary: INFO INFO Parent .. SUCCESS 6.470s INFO Model ... SUCCESS 5.247s INFO Web . SUCCESS 28.529s INFO INFO BUILD SUCCESS INFO INFO Total time: 2:28.671s INFO Finished at: Wed Jul 25 14:35:39 WEST 2012 INFO Final Memory: 14M/36M INFO Archiving workspace Deleting old workspace snapshot from #413. Publishing Cobertura coverage report... Publishing Cobertura coverage results... Finished: SUCCESS This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14343) URL for ViewVC/ViewCVS contains portion of CVSROOT
g g updated JENKINS-14343 URL for ViewVC/ViewCVS contains portion of CVSROOT Change By: g g (25/Jul/12 1:55 PM) Priority: Minor Major This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14569) PATH is not being injected correctly
Krzysztof Malinowski
created JENKINS-14569
PATH is not being injected correctly
Issue Type:
Bug
Affects Versions:
current
Assignee:
Gregory Boissinot
Components:
envinject
Created:
25/Jul/12 1:59 PM
Description:
On a node level there is PATH environment variable set:
D:\cygwin\bin;${VS71COMNTOOLS}..\IDE;${windir}\Microsoft.NET\Framework\v4.0.30319;${PATH}
Job has been set to set environments variable before SCM checkout with both 'Keep Jenkins Environment Variables' and 'Keep Jenkins Build Variables' checked.
In the build step I put 'echo %PATH%'. It shows that the original PATH is set (without D:\cygwin\bin;${VS71COMNTOOLS}..\IDE;${windir}\Microsoft.NET\Framework\v4.0.30319; part). At the same time in Injected Environment Variables tab I see that PATH was correctly enhanced with settings from node.
The issue did not happen before EnvInject installation and setup. Previously 'echo %PATH%' at build step showed correct path.
Environment:
Jenkins 1.472 on RHEL5 x86_64, Windows Server 2003 slave
Project:
Jenkins
Priority:
Major
Reporter:
Krzysztof Malinowski
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14474) Multi-configuration jobs disappear from the list when Jenkins configuration is reloaded from disk
Jayme Deffenbaugh updated JENKINS-14474 Multi-configuration jobs disappear from the list when Jenkins configuration is reloaded from disk Change By: Jayme Deffenbaugh (25/Jul/12 2:03 PM) Labels: mac matrixwindows Environment: Windows7 MacOSX10.7.4 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14568) Improve commit messages from SCM Sync Configuration
Frédéric Camblor commented on JENKINS-14568 Improve commit messages from SCM Sync Configuration You misunderstood the "several modification changes on several files = 1 commit" Once JENKINS-13613 will be implemented, the commit changeset will be made of files modified during the http request of form submission. When you configure a job, only file jobs/foo/config.xml is modified 1, then, only config.xml will be commited. Whereas you're not able to modify several job config files in 1 http request, you won't have more than 1 config.xml file per commit. 1 I simplified the case here to be more clear. In fact, during the jobs form submission, every plugin which plugged themselves on "job-centric" extension point, will have their Saveable.save() method called. Generally, most of them are working into a chunk of the jobs/xxx/config.xml file. Thus, when Saveable.save() is called on 1 plugin, the config.xml is saved on filesystem with new plugin state (and I commit this config.xml state in pre-JENKINS-13613, which explains why we have several commits on same file during a job configuration form submission). Sometimes, the plugins are not working into config.xml file, but in their own xml file. This is the reason why I say we could have multiple files commited during a HTTP request (if some plugin involved are not persisting their data into config.xml file). Note that I always spoke about jobs, but in scm-sync-configuration I never manipulate "jobs" but "saveables" that are a more generic class (a User is a Saveable for instance). That's why we cannot make the jobs workflow a general workflow case. The general workflow case is : Someone submit a form on jenkins Lots of Saveable.save() are called. They modify 1..* files on filesystem. I track these modifications. Once http request is done, scm sync config commit every changed files But everything occurs during 1 http request. When Saveable.save() is not called during a http request (on batches for instance), I won't be able (for the moment) to identify clearly the changesets. Thus, in that particular cases, I'll have to fallback into "pre" JENKINS-13613 behaviour : 1 commit per Saveable.save() In your particular case, wouldn't JENKINS-13613 simplify your life so much that you won't need file path in commit message anymore ? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13613) scm_sync_configuration may commit bulk changes in one change set
Frédéric Camblor edited a comment on JENKINS-13613 scm_sync_configuration may commit bulk changes in one change set I'm going to refactor the way the plugin is behaving concerning commits. For the moment, it detects a change on a Saveable object and, each time, make a commit on the file concerned by this change. You have to note that a Saveable is always attached to a file, but a file can be concerned by several Saveable (ie: descriptors) This is the reason why, when, for instance, you persist the jenkins system configuration screen, lots of commit will be made : every plugin which has a Descriptor on system configuration data, will be saved separately = each save will make a commit. This is the point of the issue. What I'm going to do to address this problem : I'll implement a PluginServletFilter that will initialize, for every requests, an empty Changeset in the beginning of the request. This Changeset will be stored in a ThreadLocal. Then, request will be processed normally Then, when request process ends, the PluginServletFilter will look at the Changeset and, if it isn't empy, it will commit every changes in this one, in only one commit. Now, some more technical inputs : Everytime a Saveable will be saved, instead of synchronizing the underlying file, current Saveable's file content will be added into the ThreadLocal's Changeset A Changeset will be made of a MapfilePath, contentOfFile. Thus, if multiple Saveable work in the same file, they will override same Changeset entry each time the Saveable is saved. I hope the byte[] won't consume too much memory... This Changeset representation will avoid collision on file save : 2 users edit the global jenkins configuration page 1st user submit the page, it takes a long time to synchronize... 2nd user submit the page, it modifies the config.xml before synchronization of 1st user is finished = changes of 2nd user will be commited during 1st user commit Commit could then be made asynchronously, but this is another point (see JENKINS-14214) When Saveable.save() is called "outside" an http request (triggerd by jenkins himself for instance), I won't be able to identify (for the moment) clearly a "transaction". Thus, I'll have to keep the "pre" JENKINS-13613 behaviour as a fallback : 1 commit per Saveable.save(). On this point, though, maybe could I ask Kohsuke if he has a good entry point for batched jenkins task when I could say "hey, transaction starts here, start to track changesets on Saveable.save()" I think by doing such a refactoring, I could fix problems like JENKINS-10967 and JENKINS-9166 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14552) Cannot plublish cobertura reports if org.codehaus.mojo:cobertura-maven-plugin is not invoked
drautureau commented on JENKINS-14552 Cannot plublish cobertura reports if org.codehaus.mojo:cobertura-maven-plugin is not invoked Miguel: I guess you are having the issue because you run cobertura:cobertura in a post action of the build. That's why you are having the message Skipping Cobertura coverage report as mojo did not run. in the log. I guess that if you add "cobertura:cobertura" in the goal of the main step you will not run into this issue anymore. Adding it I solved the issue but I consider this as a workaround for my case because grails uses the cobertura library and not the cobertura-maven-plugin. I should have said "Cannot plublish cobertura reports if org.codehaus.mojo:cobertura-maven-plugin is not invoked in the main step of a maven build". This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14569) PATH is not being injected correctly
Krzysztof Malinowski commented on JENKINS-14569 PATH is not being injected correctly OK, now I got similar error on a different project which does not even have EnvInject set. The project used standard 'set environment variables' setting to override PATH and it stopped working once EnvInject was installed. Original PATH setting has been used instead. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14568) Improve commit messages from SCM Sync Configuration
Julien Carsique
commented on JENKINS-14568
Improve commit messages from SCM Sync Configuration
The planned behavior of JENKINS-13613 sounds perfect.
Current issue JENKINS-14568 is still needed: even with JENKINS-13613, I'll have tens of changesets with the same message (or emails within the same thread: one thread per user).
Thinking about the job name, the file paths are always of the form jobs/jobName/.../someFile.xml (when configuring jobs) so you could split on slashes ("/") and extract the word after jobs to get the job name.
When there is not such a pattern, that means the configuration change wasn't done on a job but on a global config and so the whole file path is nice in that case.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-6124) git - optional control to disable fetching tags?
algoRhythm99 commented on JENKINS-6124 git - optional control to disable fetching tags? Pull request to simply remove the -t option from the fetch: https://github.com/jenkinsci/git-plugin/pull/77 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14568) Improve commit messages from SCM Sync Configuration
Frédéric Camblor commented on JENKINS-14568 Improve commit messages from SCM Sync Configuration I can test "if(currentSaveable instanceof AbstractBuild)" and then cast the Saveable into AbstractBuild when I can retrieve job name (which is more simpler ) But I'm not a big fan of making glitches in code just for this. Isn't your problem due to your user too ? Who doesn't enter any commit message in message prompt ? Eventually, I wouldn't be against a configuration flag allowing to make commit message mandatory if checked. WDYT ? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12877) Problem to configure perforce plugin and maven release plugin
Hugo Lassiège commented on JENKINS-12877 Problem to configure perforce plugin and maven release plugin I have more time to investigate on that this week ^^ So, the problem is that every P4 variables are not exported to the environment for post build actions. All variables declared in the perforce section are not exposed in the environment when the maven command is runned. So we end up with several errors due to P4CHARSET, P4CLIENT, P4USER not known. It fails even if I add a pre build step to set this variable through a shell script. I guess the pre build script is not runned on the same environnement and so my EXPORT commands are useless for post build actions. So the question is, is it possible for the jenkins perforce plugin to expose these variables to the build when maven is invoked ? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8708) Progress bar link on Jenkins front page goes to an invalid URL
evernat resolved JENKINS-8708 as Duplicate Progress bar link on Jenkins front page goes to an invalid URL Indeed, this is a duplicate. Change By: evernat (25/Jul/12 2:57 PM) Status: Open Resolved Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14568) Improve commit messages from SCM Sync Configuration
Frédéric Camblor edited a comment on JENKINS-14568 Improve commit messages from SCM Sync Configuration I can test "if(currentSaveable instanceof AbstractBuild)" and then cast the Saveable into AbstractBuild where I can retrieve job name (which is more simpler ) But I'm not a big fan of making glitches in code just for this. Isn't your problem due to your user too ? Who doesn't enter any commit message in message prompt ? Eventually, I wouldn't be against a configuration flag allowing to make commit message mandatory if checked. WDYT ? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14568) Improve commit messages from SCM Sync Configuration
Julien Carsique commented on JENKINS-14568 Improve commit messages from SCM Sync Configuration I guess it's "also" a good idea and I would obviously set that option on. Anyway, I prefer having a reliable information set by the plugin rather than rely on the user's commit message (which is only a bonus, even if mandatory). The instanceof solution seems effectively simpler and is not a glitch at all Note I'm not always asked for a commit message and I didn't check the option to not being bothered anymore by it (I didn't fill an issue for that, nor searched for an existing one). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14552) Cannot plublish cobertura reports if org.codehaus.mojo:cobertura-maven-plugin is not invoked
Miguel Almeida commented on JENKINS-14552 Cannot plublish cobertura reports if org.codehaus.mojo:cobertura-maven-plugin is not invoked @drautureau - that would be true if it had the same behaviour in 1.3. However, in 1.3 the coverage reports are added as expected... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12173) thinBackup does not include build results for matrix projects when nodes axis is used
Thomas Fürer commented on JENKINS-12173 thinBackup does not include build results for matrix projects when nodes axis is used Integrated in thinBackup #47 JENKINS-12173: thinBackup does not include build results for matrix projects when nodes axis is used (Revision 40679) Result = FAILURE tofuatjava : 40679 Files : /trunk/hudson/plugins/thinBackup/src/main/java/org/jvnet/hudson/plugins/thinbackup/backup/HudsonBackup.java /trunk/hudson/plugins/thinBackup/src/test/java/org/jvnet/hudson/plugins/thinbackup/HudsonDirectoryStructureSetup.java /trunk/hudson/plugins/thinBackup/src/test/java/org/jvnet/hudson/plugins/thinbackup/TestHelper.java /trunk/hudson/plugins/thinBackup/src/test/java/org/jvnet/hudson/plugins/thinbackup/backup/TestBackupMatrixJob.java /trunk/hudson/plugins/thinBackup/src/test/java/org/jvnet/hudson/plugins/thinbackup/backup/TestBackupZipping.java /trunk/hudson/plugins/thinBackup/src/test/java/org/jvnet/hudson/plugins/thinbackup/backup/TestHudsonBackup.java /trunk/hudson/plugins/thinBackup/src/test/java/org/jvnet/hudson/plugins/thinbackup/restore/TestHudsonRestore.java This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14288) thinBackup doesn't put back the current shutdown flag after backing up
Thomas Fürer commented on JENKINS-14288 thinBackup doesnt put back the current shutdown flag after backing up Integrated in thinBackup #47 JENKINS-14288: thinBackup doesn't put back the current shutdown flag after backing up (Revision 40678) Result = FAILURE tofuatjava : 40678 Files : /trunk/hudson/plugins/thinBackup/src/main/java/org/jvnet/hudson/plugins/thinbackup/ThinBackupPeriodicWork.java /trunk/hudson/plugins/thinBackup/src/main/java/org/jvnet/hudson/plugins/thinbackup/utils/Utils.java This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13980) The archive folder gets lost if you also backup archives for builds
Thomas Fürer commented on JENKINS-13980 The archive folder gets lost if you also backup archives for builds Integrated in thinBackup #47 JENKINS-13980: archives will be back-uped for the differential back-up only if changes are detected (like all other files) (Revision 40624) JENKINS-13980: fix missing archive folder but the archive gets backuped also for each DIFF regardless if the archive was changed (Revision 40623) Result = FAILURE tofuatjava : 40624 Files : /trunk/hudson/plugins/thinBackup/src/main/java/org/jvnet/hudson/plugins/thinbackup/backup/HudsonBackup.java alienllama : 40623 Files : /trunk/hudson/plugins/thinBackup/src/main/java/org/jvnet/hudson/plugins/thinbackup/backup/HudsonBackup.java This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14570) Warnings plugin tries to load wrong compiler-warnings.xml file
Viktor Bekesi created JENKINS-14570 Warnings plugin tries to load wrong compiler-warnings.xml file Issue Type: Bug Assignee: Ulli Hafner Attachments: Dashboard.png, hudson.plugins.warnings.WarningsPublisher.xml, ScreenshotC++.png Components: warnings Created: 25/Jul/12 3:26 PM Description: The plugin stopped loading source codes properly. I see the files in the builds/date-time/workspace-files folder, but some of them 0 bytes long. But the interesting thing is, that an exception is raised whenever i try to click on any warning in the list, saying for example: WARNING: Failed to load D:\Jenkins\jobs\myjobname\builds\2012-07-24_02-49-57\compiler-7-warnings.xml java.io.FileNotFoundException: D:\Jenkins\jobs\myjobname\builds\2012-07-24_02-49-57\compiler-7-warnings.xml (The system cannot find the file specified) Of course there is no "compiler-7-warnings.xml" file in that folder only "compiler-warnings.xml", "compiler-1-warnings.xml" and "compiler-2-warnings.xml". And this happens for every builds in jobs in my system since one or two weeks. Before today (before I updated to 4.13) at least the listing of the warnings worked, I could see how many warnings the plugin found, and i could switched between folders, files, detailed, etc. Only the source display was broken. From today the build page and the dashboard applet displays the number of warnings, but when I clicked on the link, the list of warnings is empty (attached screenshot) There is another bug, I don't know whether they are related: I sarted with one customized C++ parser, I did not like the default MSBuild parser, i wanted to exclude the link warnings, etc, and the plugin listed the warnings just fine. Then I added two more custom parsers, one for C# and another one for DoxyGen (please see the attached WarningsPublisher.xml file) and things started to be strange... On the build report pages it shows that there are zero warnings for C# and Doxygen, though i can see in the log, that there are. The configuration of the parsers with the regular _expression_ should be ok, at least according to the the test on the configuration page. Then if you see Dashoboard.png, the first job of C# and Doxgen table has the same number of warnings that the fist one of C++ table has, and if you click on the numbers of any table, you always find yourself in the C++ warnings page. Also it is strange that there are always as many fixed warnings as new ones. And the Compiler warnings trend graph shows only the number of this one job instead of a real total. Project: Jenkins Priority: Major Reporter: Viktor Bekesi This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14568) Improve commit messages from SCM Sync Configuration
Frédéric Camblor edited a comment on JENKINS-14568 Improve commit messages from SCM Sync Configuration You misunderstood the "several modification changes on several files = 1 commit" Once JENKINS-13613 will be implemented, the commit changeset will be made of files modified during the http request of form submission. When you configure a job, only file jobs/foo/config.xml is modified 1, then, only config.xml will be commited. Unless you're not able to modify several job config files in 1 http request, you won't have more than 1 config.xml file per commit. 1 I simplified the case here to be more clear. In fact, during the jobs form submission, every plugin which plugged themselves on "job-centric" extension point, will have their Saveable.save() method called. Generally, most of them are working into a chunk of the jobs/xxx/config.xml file. Thus, when Saveable.save() is called on 1 plugin, the config.xml is saved on filesystem with new plugin state (and I commit this config.xml state in pre-JENKINS-13613, which explains why we have several commits on same file during a job configuration form submission). Sometimes, the plugins are not working into config.xml file, but in their own xml file. This is the reason why I say we could have multiple files commited during a HTTP request (if some plugin involved are not persisting their data into config.xml file). Note that I always spoke about jobs, but in scm-sync-configuration I never manipulate "jobs" but "saveables" that are a more generic class (a User is a Saveable for instance). That's why we cannot make the jobs workflow a general workflow case. The general workflow case is : Someone submit a form on jenkins Lots of Saveable.save() are called. They modify 1..* files on filesystem. I track these modifications. Once http request is done, scm sync config commit every changed files But everything occurs during 1 http request. When Saveable.save() is not called during a http request (on batches for instance), I won't be able (for the moment) to identify clearly the changesets. Thus, in that particular cases, I'll have to fallback into "pre" JENKINS-13613 behaviour : 1 commit per Saveable.save() In your particular case, wouldn't JENKINS-13613 simplify your life so much that you won't need file path in commit message anymore ? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14288) thinBackup doesn't put back the current shutdown flag after backing up
Thomas Fürer commented on JENKINS-14288 thinBackup doesnt put back the current shutdown flag after backing up Integrated in thinBackup #50 JENKINS-14288: thinBackup doesn't put back the current shutdown flag after backing up (Revision 40678) Result = FAILURE tofuatjava : 40678 Files : /trunk/hudson/plugins/thinBackup/src/main/java/org/jvnet/hudson/plugins/thinbackup/ThinBackupPeriodicWork.java /trunk/hudson/plugins/thinBackup/src/main/java/org/jvnet/hudson/plugins/thinbackup/utils/Utils.java This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13980) The archive folder gets lost if you also backup archives for builds
Thomas Fürer commented on JENKINS-13980 The archive folder gets lost if you also backup archives for builds Integrated in thinBackup #50 JENKINS-13980: archives will be back-uped for the differential back-up only if changes are detected (like all other files) (Revision 40624) JENKINS-13980: fix missing archive folder but the archive gets backuped also for each DIFF regardless if the archive was changed (Revision 40623) Result = FAILURE tofuatjava : 40624 Files : /trunk/hudson/plugins/thinBackup/src/main/java/org/jvnet/hudson/plugins/thinbackup/backup/HudsonBackup.java alienllama : 40623 Files : /trunk/hudson/plugins/thinBackup/src/main/java/org/jvnet/hudson/plugins/thinbackup/backup/HudsonBackup.java This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12173) thinBackup does not include build results for matrix projects when nodes axis is used
Thomas Fürer commented on JENKINS-12173 thinBackup does not include build results for matrix projects when nodes axis is used Integrated in thinBackup #50 JENKINS-12173: thinBackup does not include build results for matrix projects when nodes axis is used (Revision 40679) Result = FAILURE tofuatjava : 40679 Files : /trunk/hudson/plugins/thinBackup/src/main/java/org/jvnet/hudson/plugins/thinbackup/backup/HudsonBackup.java /trunk/hudson/plugins/thinBackup/src/test/java/org/jvnet/hudson/plugins/thinbackup/HudsonDirectoryStructureSetup.java /trunk/hudson/plugins/thinBackup/src/test/java/org/jvnet/hudson/plugins/thinbackup/TestHelper.java /trunk/hudson/plugins/thinBackup/src/test/java/org/jvnet/hudson/plugins/thinbackup/backup/TestBackupMatrixJob.java /trunk/hudson/plugins/thinBackup/src/test/java/org/jvnet/hudson/plugins/thinbackup/backup/TestBackupZipping.java /trunk/hudson/plugins/thinBackup/src/test/java/org/jvnet/hudson/plugins/thinbackup/backup/TestHudsonBackup.java /trunk/hudson/plugins/thinBackup/src/test/java/org/jvnet/hudson/plugins/thinbackup/restore/TestHudsonRestore.java This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13715) User email suffixes are getting overwritten with the with the subversion repo UUID
David Pattison commented on JENKINS-13715 User email suffixes are getting overwritten with the with the subversion repo UUID i disabled the git plugin and now it works!!! Thanks! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14329) SCM Sync Configuration plugin conflicts with Parameterized Trigger plugin. (stuck on waiting for the completion of OtherBuild)
peter_schuetze commented on JENKINS-14329 SCM Sync Configuration plugin conflicts with Parameterized Trigger plugin. (stuck on waiting for the completion of OtherBuild) At least for now I will not upgrade to SCM Sync 0.0.5. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12173) thinBackup does not include build results for matrix projects when nodes axis is used
Thomas Fürer resolved JENKINS-12173 as Fixed thinBackup does not include build results for matrix projects when nodes axis is used Change By: Thomas Fürer (25/Jul/12 4:23 PM) Status: InProgress Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14329) SCM Sync Configuration plugin conflicts with Parameterized Trigger plugin. (stuck on waiting for the completion of OtherBuild)
Ben Dean updated JENKINS-14329 SCM Sync Configuration plugin conflicts with Parameterized Trigger plugin. (stuck on waiting for the completion of OtherBuild) Updated environment to include Jenkins version 1.475, I tested and the bug still exists there (same versions of the two plugins). Change By: Ben Dean (25/Jul/12 4:32 PM) Environment: OS:WindowsServer2008R2Jenkins:1.461,1.470,1.473 ,1.475 JenkinsParameterizedTriggerplugin:2.15SCMSyncConfigurationPlugin:0.0.5 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10061) http://JENKINS/pluginManager/checkUpdates does not work without GUI / javascript
Kelvin Luck commented on JENKINS-10061 http://JENKINS/pluginManager/checkUpdates does not work without GUI / _javascript_ This is also making it impossible for me to have automated unattended installs. Especially since it also doesn't seem to work when I use the complete URL to the plugin e.g. The following URL gives no errors but the plugin isn't installed when I check in the web interface: jenkins-cli -s http://localhost:8080 install-plugin http://updates.jenkins-ci.org/download/plugins/greenballs/1.12/greenballs.hpi -restart This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13619) Add ability to throttle number of concurrent builds of matrix configurations per node
Adam PAPAI edited a comment on JENKINS-13619 Add ability to throttle number of concurrent builds of matrix configurations per node Do we have any improvements on this? We also need to throttle our matrix jobs. Is there something I can help? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14573) getting the error returned status code 128: ssh_exchange_identification: Connection closed by remote host from github
Rob Saul created JENKINS-14573 getting the error returned status code 128: ssh_exchange_identification: Connection closed by remote host from github Issue Type: Bug Affects Versions: current Assignee: Nicolas De Loof Components: git Created: 25/Jul/12 6:12 PM Description: I've seen this issue raised in JENKINS-11576 and a solution there. However, we're getting this Fetching upstream changes from g...@github.com:company/repo.git ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway hudson.plugins.git.GitException: Error performing command: /usr/bin/git fetch -t g...@github.com:company/repo.git +refs/heads/:refs/remotes/origin/ Command "/usr/bin/git fetch -t g...@github.com:company/repo.git +refs/heads/:refs/remotes/origin/" returned status code 128: ssh_exchange_identification: Connection closed by remote host fatal: The remote end hung up unexpectedly at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:776) at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:741) at hudson.plugins.git.GitAPI.fetch(GitAPI.java:190) at hudson.plugins.git.GitAPI.fetch(GitAPI.java:978) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:765) at hudson.plugins.git.GitSCM.access$100(GitSCM.java:80) at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1003) at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:970) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2196) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) Caused by: hudson.plugins.git.GitException: Command "/usr/bin/git fetch -t g...@github.com:company/repo.git +refs/heads/:refs/remotes/origin/" returned status code 128: ssh_exchange_identification: Connection closed by remote host fatal: The remote end hung up unexpectedly on a regular basis. As this is an interaction with GitHub the solution mentioned in JENKINS-11576 isn't an option. Attempting the build will often, but not always, resolve the problem. This, however, wastes time. Would it be possible to add a configurable retry to the code that executes the fetch? Environment: Fedora release 11 ( Linux 2.6.30.10-105.2.23.fc11.i586 ) java version 1.6.0_18 (OpenJDK Runtime Environment (IcedTea6 1.8) (fedora-35.b18.fc11-i386)) Project: Jenkins Priority: Major Reporter: Rob Saul This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14574) Failed to parse form data
Pedro Larroy
created JENKINS-14574
Failed to parse form data
Issue Type:
Bug
Assignee:
Unassigned
Components:
www
Created:
25/Jul/12 6:16 PM
Description:
Failed to parse form data. Please report this problem as a bug
JSON={"":"","builder":{"command":"set -e\nunset TMP TMPDIR TEMP TEMPDIR\nexport TMP='.'\n./build.sh\nscripts/ci/test-mmcc-berlin.py","kind":"hudson.tasks.Shell","stapler-class":"hudson.tasks.Shell"},"core:apply":"","description":"","displayNameOrNull":"","hudson-plugins-build_timeout-BuildTimeoutWrapper":{"failBuild":true,"timeoutMinutes":"30"},"hudson-triggers-SCMTrigger":{"scmpoll_spec":"# PLEASE KEEP THIS PLACEHOLDER AS IT IS\n@yearly"},"logrotate":{"logrotate_artifact_days":"","logrotate_artifact_nums":"","logrotate_days":"","logrotate_nums":"10"},"name":"mcf-berlin","properties":{"hudson-model-ParametersDefinitionProperty":{},"hudson-plugins-throttleconcurrents-ThrottleJobProperty":{"maxConcurrentPerNode":"0","maxConcurrentTotal":"0","throttleEnabled":false,"throttleOption":"project"},"stapler-class-bag":"true"},"publisher":[{"artifacts":"_mmcc_stats_out/*.cdt,build/release/mmcc,build/release/most","excludes":"","kind":"hudson.tasks.ArtifactArchiver","latestOnly":false,"stapler-class":"hudson.tasks.ArtifactArchiver"},{"childProjects":"mcf-world_f8,mcf-world_f6","kind":"hudson.tasks.BuildTrigger","stapler-class":"hudson.tasks.BuildTrigger","threshold":"SUCCESS"},{"kind":"hudson.plugins.plot.PlotPublisher","plots":[{"csvFileName":"2142092486.csv","group":"mmcc","numBuilds":"100","series":{"file":"_mmcc_stats_out/peak_mb_f6"},{"file":"_mmcc_stats_out/peak_mb_f8"},"style":"line","title":"Peak memory usage","useDescr":false,"yaxis":"MB"},{"csvFileName":"164505283.csv","group":"mmcc","numBuilds":"100","series":{"file":"_mmcc_stats_out/cdt_mb_f6"},{"file":"_mmcc_stats_out/cdt_mb_f8"},"style":"line","title":"CDT size","useDescr":false,"yaxis":"MB"},{"csvFileName":"1474549102.csv","group":"mmcc","numBuilds":"100","series":{"file":"_mmcc_stats_out/time_s_f6"},{file:_mmcc_stats_out/time_s_f8,fileType:{label:format 8,value:properties}},"style":"line","title":"Compile time","useDescr":false,"yaxis":"s"}],"stapler-class":"hudson.plugins.plot.PlotPublisher"},{"kind":"hudson.tasks.Mailer","mailer_notifyEveryUnstableBuild":true,"mailer_recipients":"pedro.lar...@nokia.com frank.gell...@nokia.com nunzio.visci...@nokia.com stefano.pett...@nokia.com arsen.dramb...@nokia.com peter.sinia...@nokia.com ","mailer_sendToIndividuals":false,"stapler-class":"hudson.tasks.Mailer"}],"scm":{"":"3","branch":"default","browser":{"stapler-class":"hudson.plugins.mercurial.browser.HgWeb","url":"https://source.nokia.com/mos_map_compiler/hg/production/"},"clean":true,"modules":"","source":"http://bfmapcomp01.europe.nokia.com/sources_jenkins/mos_map_compiler/production/","subdir":"","value":"1"}}
net.sf.json.JSONException: null object
at net.sf.json.JSONObject.verifyIsNull(JSONObject.java:2428)
at net.sf.json.JSONObject.element(JSONObject.java:1486)
at net.sf.json.JSONObject.element(JSONObject.java:1469)
at net.sf.json.JSONObject.put(JSONObject.java:2065)
at hudson.plugins.plot.SeriesFactory.createSeries(SeriesFactory.java:27)
at hudson.plugins.plot.SeriesFactory.createSeriesList(SeriesFactory.java:43)
at hudson.plugins.plot.PlotPublisher$DescriptorImpl.bindPlot(PlotPublisher.java:231)
at hudson.plugins.plot.PlotPublisher$DescriptorImpl.newInstance(PlotPublisher.java:224)
at hudson.plugins.plot.PlotPublisher$DescriptorImpl.newInstance(PlotPublisher.java:202)
at hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:912)
at hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:899)
at hudson.util.DescribableList.rebuildHetero(DescribableList.java:184)
at hudson.model.Project.submit(Project.java:203)
at hudson.model.Job.doConfigSubmit(Job.java:990)
at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:665)
at sun.reflect.GeneratedMethodAccessor1001.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
[JIRA] (JENKINS-14154) Groovy script can not resolve import classes like hudson.scm.SubversionSCM
João Antunes commented on JENKINS-14154 Groovy script can not resolve import classes like hudson.scm.SubversionSCM the same happens with me, is this normal? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14154) Groovy script can not resolve import classes like hudson.scm.SubversionSCM
João Antunes commented on JENKINS-14154 Groovy script can not resolve import classes like hudson.scm.SubversionSCM so, running the import on the ssh -p port localhost groovysh i get: groovy:000 import hudson.scm.SubversionSCM groovy:000 ERROR java.lang.IncompatibleClassChangeError: the number of constructors during runtime and compile time for java.lang.Exception do not match. Expected 5 but got 4 at java_lang_Runnable$run.call (Unknown Source) at hudson.cli.GroovyshCommand.main (GroovyshCommand.java:70) at org.jenkinsci.main.modules.sshd.CLICommandAdapter$1.run (CLICommandAdapter.java:34) at org.jenkinsci.main.modules.sshd.AsynchronousCommand$1.run (AsynchronousCommand.java:104) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14154) Groovy script can not resolve import classes like hudson.scm.SubversionSCM
João Antunes commented on JENKINS-14154 Groovy script can not resolve import classes like hudson.scm.SubversionSCM actually, this also happens when I do just a purge: fenix-ashes:~/JenkinsSVNScripts# ssh -p 1414 jenkins@localhost groovysh Groovy Shell (1.8.5, JVM: 1.6.0_22) Type 'help' or '\h' for help. --- groovy:000 purge groovy:000 ERROR java.lang.IncompatibleClassChangeError: the number of constructors during runtime and compile time for java.lang.Exception do not match. Expected 5 but got 4 at java_lang_Runnable$run.call (Unknown Source) at hudson.cli.GroovyshCommand.main (GroovyshCommand.java:70) at org.jenkinsci.main.modules.sshd.CLICommandAdapter$1.run (CLICommandAdapter.java:34) at org.jenkinsci.main.modules.sshd.AsynchronousCommand$1.run (AsynchronousCommand.java:104) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14154) Groovy script can not resolve import classes like hudson.scm.SubversionSCM
João Antunes commented on JENKINS-14154 Groovy script can not resolve import classes like hudson.scm.SubversionSCM so, according to http://stackoverflow.com/questions/7826967/geb-incompatibleclasschangeerror Java 7 seems to be the issue.. I'm thinking on recompilink jenkins with Java 7 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14154) Groovy script can not resolve import classes like hudson.scm.SubversionSCM
João Antunes commented on JENKINS-14154 Groovy script can not resolve import classes like hudson.scm.SubversionSCM ok, so, I was running jenkins with Java 6, switched to run it with Java 7, and the purge now works, but the import gives me the error: groovy:000 import jenkins.scm.SubversionSCM ERROR org.codehaus.groovy.tools.shell.CommandException: Invalid import definition: 'import jenkins.scm.SubversionSCM'; reason: startup failed: script13432436404381481316699.groovy: 1: unable to resolve class jenkins.scm.SubversionSCM @ line 1, column 1. import jenkins.scm.SubversionSCM ^ 1 error This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14575) SCM checkout retry count not working
Łukasz Nowak created JENKINS-14575 SCM checkout retry count not working Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: plugin Created: 25/Jul/12 8:08 PM Description: From time to time I reveive error when getting SCM changes from Git repository and the option "SCM checkout retry count" (I have set it to 3) is not working. ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway hudson.plugins.git.GitException: Command "git fetch -t g...@github.com:xxx/xxx +refs/heads/:refs/remotes/origin/" returned status code 128: stdout: stderr: ssh_exchange_identification: Connection closed by remote host fatal: The remote end hung up unexpectedly at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:818) at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:780) at hudson.plugins.git.GitAPI.fetch(GitAPI.java:196) at hudson.plugins.git.GitAPI.fetch(GitAPI.java:1026) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:812) at hudson.plugins.git.GitSCM.access$100(GitSCM.java:90) at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1096) at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1064) at hudson.FilePath.act(FilePath.java:842) at hudson.FilePath.act(FilePath.java:824) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1064) at org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:117) at hudson.model.AbstractProject.checkout(AbstractProject.java:1249) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494) at hudson.model.Run.execute(Run.java:1488) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) ERROR: Could not fetch from any repository FATAL: Could not fetch from any repository hudson.plugins.git.GitException: Could not fetch from any repository at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1103) at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1064) at hudson.FilePath.act(FilePath.java:842) at hudson.FilePath.act(FilePath.java:824) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1064) at org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:117) at hudson.model.AbstractProject.checkout(AbstractProject.java:1249) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494) at hudson.model.Run.execute(Run.java:1488) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Environment: Jenkins 1.473 on Debian Project: Jenkins Priority: Blocker Reporter: Łukasz Nowak This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-6124) git - optional control to disable fetching tags?
Douglas Beatty commented on JENKINS-6124 git - optional control to disable fetching tags? For a standard source code repository, this is not a significant performance wise and we have not notice this issue on our source code repositories. However, in general, it is not good that is is fetching references and therefore objects that are not required by the build. It is just inefficient. However, as stated, for source code repositories it is not significant enough that we have noticed. I have created a new issue that targets the scenario for our specific issue JENKINS-14572. Where we have noticed it is in the Git repositories we are using to deploy our web applications which are large repositories of binary files. We create each deployment image as an orphan commit, tag it, and push the tag not the branch back to our Git server. This way we can delete the tags after a holding period which causes those commits to be unreferenced and eligible for garbage collection. We have the Jenkins plug-in configured to pull down an 'empty' branch by specifying a refspec. When all of the tags are fetched, then a large number of unneeded objects are pulled down from the repository greatly increasing the size of the repositories on the Jenkins slaves. Having said all of that, if you want to build a specific tag, why not specify it in the refspec? The refspec can use build parameters also. Why fetch all tags when you only need one? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-6124) git - optional control to disable fetching tags?
Douglas Beatty edited a comment on JENKINS-6124 git - optional control to disable fetching tags? For a standard source code repository, this is not significant performance wise and we have not noticed this issue on our source code repositories. However, in general, it is not good that it is fetching references and therefore objects that are not required by the build. It is just inefficient. However, as stated, for source code repositories it is not significant enough that we have noticed. I have created a new issue that targets the scenario for our specific issue JENKINS-14572. Where we have noticed it is in the Git repositories we are using to deploy our web applications which are large repositories of binary files. We create each deployment image as an orphan commit, tag it, and push the tag not the branch back to our Git server. This way we can delete the tags after a holding period causing those commits to be unreferenced and eligible for garbage collection. We have the Jenkins plug-in configured to pull down an 'empty' branch by specifying a refspec. When all of the tags are fetched, then a large number of unneeded objects are pulled down from the repository greatly increasing the size of the repositories on the Jenkins slaves. Having said all of that, if you want to build a specific tag, why not specify it in the refspec? The refspec can use build parameters also. Why fetch all tags when you only need one? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14572) Git plug-in fetches all tags even when refspec is provided
Douglas Beatty commented on JENKINS-14572 Git plug-in fetches all tags even when refspec is provided Copied the following comment from JENKINS-6124 as it is relevant here as well For a standard source code repository, this is not significant performance wise and we have not noticed this issue on our source code repositories. However, in general, it is not good that it is fetching references and therefore objects that are not required by the build. It is just inefficient. However, as stated, for source code repositories it is not significant enough that we have noticed. I have created a new issue that targets the scenario for our specific issue JENKINS-14572. Where we have noticed it is in the Git repositories we are using to deploy our web applications which are large repositories of binary files. We create each deployment image as an orphan commit, tag it, and push the tag not the branch back to our Git server. This way we can delete the tags after a holding period causing those commits to be unreferenced and eligible for garbage collection. We have the Jenkins plug-in configured to pull down an 'empty' branch by specifying a refspec. When all of the tags are fetched, then a large number of unneeded objects are pulled down from the repository greatly increasing the size of the repositories on the Jenkins slaves. Having said all of that, if you want to build a specific tag, why not specify it in the refspec? The refspec can use build parameters also. Why fetch all tags when you only need one? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14576) NullPointerException in hudson.plugins.repo.ChangeLogEntry when using Jenkins API
Zack Elan created JENKINS-14576 NullPointerException in hudson.plugins.repo.ChangeLogEntry when using Jenkins API Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: repo Created: 25/Jul/12 9:52 PM Description: Steps to reproduce: Have a build job that uses the repo plugin Run that job such that it pulls down changes where one or more commits had no files changed (these seem to be merge commits in our case) Access that job through the Jenkins API Behavior: Going directly to the build's page in Jenkins works as I expect. However, I'm using a script that accesses Jenkins through its API. When I tack on '/api/json' or '/api/xml' to the URL, I get the following exception: Caused by: java.lang.NullPointerException at hudson.plugins.repo.ChangeLogEntry$1.size(ChangeLogEntry.java:296) at java.util.AbstractList$Itr.hasNext(AbstractList.java:339) at org.kohsuke.stapler.export.Property.writeValue(Property.java:180) at org.kohsuke.stapler.export.Property.writeValue(Property.java:136) at org.kohsuke.stapler.export.Property.writeTo(Property.java:113) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:179) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:176) at org.kohsuke.stapler.export.Property.writeValue(Property.java:231) at org.kohsuke.stapler.export.Property.writeValue(Property.java:168) at org.kohsuke.stapler.export.Property.writeValue(Property.java:136) at org.kohsuke.stapler.export.Property.writeTo(Property.java:113) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:179) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:176) at org.kohsuke.stapler.export.Property.writeValue(Property.java:231) at org.kohsuke.stapler.export.Property.writeValue(Property.java:136) at org.kohsuke.stapler.export.Property.writeTo(Property.java:113) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:179) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:176) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:176) at org.kohsuke.stapler.export.Model.writeTo(Model.java:152) at org.kohsuke.stapler.ResponseImpl.serveExposedBean(ResponseImpl.java:200) at hudson.model.Api.doJson(Api.java:181) at sun.reflect.GeneratedMethodAccessor980.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:203) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) Looking at the code (git rev 3fb046cc), I see line 296 is
[JIRA] (JENKINS-14576) NullPointerException in hudson.plugins.repo.ChangeLogEntry when using Jenkins API
Zack Elan
updated JENKINS-14576
NullPointerException in hudson.plugins.repo.ChangeLogEntry when using Jenkins API
Change By:
Zack Elan
(25/Jul/12 10:18 PM)
Description:
Stepstoreproduce:-Haveabuildjobthatusestherepoplugin-Runthatjob
suchthatitpullsdownchanges
whereoneormore
commitshadnofileschanged(theseseemtobemergecommitsinourcase)
projectswereadded/removedfromthemanifest
-AccessthatjobthroughtheJenkinsAPIBehavior:-GoingdirectlytothebuildspageinJenkinsworksasIexpect.However,ImusingascriptthataccessesJenkinsthroughitsAPI.WhenItackon/api/jsonor/api/xmltotheURL,Igetthefollowingexception:Causedby:java.lang.NullPointerExceptionathudson.plugins.repo.ChangeLogEntry$1.size(ChangeLogEntry.java:296)atjava.util.AbstractList$Itr.hasNext(AbstractList.java:339)atorg.kohsuke.stapler.export.Property.writeValue(Property.java:180)atorg.kohsuke.stapler.export.Property.writeValue(Property.java:136)atorg.kohsuke.stapler.export.Property.writeTo(Property.java:113)atorg.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:179)atorg.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:176)atorg.kohsuke.stapler.export.Property.writeValue(Property.java:231)atorg.kohsuke.stapler.export.Property.writeValue(Property.java:168)atorg.kohsuke.stapler.export.Property.writeValue(Property.java:136)atorg.kohsuke.stapler.export.Property.writeTo(Property.java:113)atorg.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:179)atorg.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:176)atorg.kohsuke.stapler.export.Property.writeValue(Property.java:231)atorg.kohsuke.stapler.export.Property.writeValue(Property.java:136)atorg.kohsuke.stapler.export.Property.writeTo(Property.java:113)atorg.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:179)atorg.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:176)atorg.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:176)atorg.kohsuke.stapler.export.Model.writeTo(Model.java:152)atorg.kohsuke.stapler.ResponseImpl.serveExposedBean(ResponseImpl.java:200)athudson.model.Api.doJson(Api.java:181)atsun.reflect.GeneratedMethodAccessor980.invoke(UnknownSource)atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)atjava.lang.reflect.Method.invoke(Method.java:597)atorg.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288)atorg.kohsuke.stapler.Function.bindAndInvoke(Function.java:151)atorg.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90)atorg.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111)atorg.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659)atorg.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:203)atorg.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659)atorg.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659)atorg.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)atorg.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659)atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:488)atorg.kohsuke.stapler.Stapler.service(Stapler.java:162)atjavax.servlet.http.HttpServlet.service(HttpServlet.java:820)Lookingatthecode(gitrev3fb046cc),Iseeline296isreturnmodifiedFiles.size()inthismethod: @Override publicCollectionStringgetAffectedPaths(){ returnnewAbstractListString(){ @Override publicStringget(finalintindex){returnmodifiedFiles.get(index).getPath(); } @Override publicintsize(){returnmodifiedFiles.size(); } }; }IfmodifiedFilesisnull,itwouldcausethebehaviorImseeing.
InChangeLog.javathereappeartobe2placeswherenullispassedinasthemodifiedFilesofChangeLogEntry-lines125and133,handlingmanifestaddsandremovals.
[JIRA] (JENKINS-14577) Plugin should not set name on Sauce Job if test has set name
Ross Rowe created JENKINS-14577 Plugin should not set name on Sauce Job if test has set name Issue Type: Bug Assignee: Ross Rowe Components: sauce-ondemand Created: 26/Jul/12 12:33 AM Description: The plugin will invoke the Sauce REST API to set the name on the job, however the plugin should only do this if a name hasn't been set by the tests Project: Jenkins Priority: Major Reporter: Ross Rowe This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13330) Jenkins slave hangs in post build phase
Stephen Morrison commented on JENKINS-13330 Jenkins slave hangs in post build phase I have seen the same thing. One job of type A hanging (because of a problem in the script) causes all other jobs of type A to hang on completion. This only happens for me when all the Job As were triggered from the same Job B. i.e. Job B triggers 8 Job As. One Job A hangs. All the other Job As will also hang even though they have completed successfully. I think that's a bug, jobs should be able to run in parallel without having dependencies on the success (or otherwise) of other jobs of the same type. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14578) The plugin Copy To Slave Plugin can't work!
MS FLY created JENKINS-14578 The plugin Copy To Slave Plugin cant work! Issue Type: Bug Assignee: Daniel Petisme Attachments: slaveconfig.jpg Components: copy-to-slave Created: 26/Jul/12 3:16 AM Description: I installed the "Copy To Slave Plugin 1.4" at Jenkins 1.472. there are some jobs which build at slave. i want to copy the build result from slave to master. but the plugin can't work,it can't copy the specify files. I can find the jar package at the slave path "D:/jenkins/data/workspace/slave/target/mavendemo-0.0.1-SNAPSHOT.jar",but it cann't copy to master. the log file is like this: copy-to-slave Copying 'D:/jenkins/data/workspace/slave/target/mavendemo-0.0.1-SNAPSHOT.jar', excluding nothing, from 'file:/D:/jenkins/data/workspace/slave/' on 'hudson.slaves.DumbSlave@a48b92b1' to 'file:/D:/jenkins/data/jobs/slave/workspace/' on the master. Finished: SUCCESS Due Date: 26/Jul/12 12:00 AM Environment: Jenkins ver. 1.472 Copy To Slave Plugin 1.4 Project: Jenkins Priority: Blocker Reporter: MS FLY This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10904) Include test case step and test case scenario variables when retrieving information of a Test Case
SCM/JIRA link daemon resolved JENKINS-10904 as Fixed Include test case step and test case scenario variables when retrieving information of a Test Case Change By: SCM/JIRA link daemon (26/Jul/12 5:23 AM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10904) Include test case step and test case scenario variables when retrieving information of a Test Case
SCM/JIRA link daemon commented on JENKINS-10904 Include test case step and test case scenario variables when retrieving information of a Test Case Code changed in jenkins User: Bruno P. Kinoshita Path: pom.xml src/main/java/hudson/plugins/testlink/TestLinkBuilder.java src/main/java/hudson/plugins/testlink/TestLinkSite.java src/main/java/hudson/plugins/testlink/result/AbstractJUnitResultSeeker.java src/main/java/hudson/plugins/testlink/result/AbstractTestNGResultSeeker.java src/main/java/hudson/plugins/testlink/result/JUnitCaseClassNameResultSeeker.java src/main/java/hudson/plugins/testlink/result/JUnitCaseNameResultSeeker.java src/main/java/hudson/plugins/testlink/result/JUnitMethodNameResultSeeker.java src/main/java/hudson/plugins/testlink/result/JUnitSuiteNameResultSeeker.java src/main/java/hudson/plugins/testlink/result/TAPFileNameResultSeeker.java src/main/java/hudson/plugins/testlink/result/TestCaseWrapper.java src/main/java/hudson/plugins/testlink/result/TestNGClassNameResultSeeker.java src/main/java/hudson/plugins/testlink/result/TestNGMethodNameDataProviderNameResultSeeker.java src/main/java/hudson/plugins/testlink/result/TestNGMethodNameResultSeeker.java src/main/java/hudson/plugins/testlink/result/TestNGSuiteNameResultSeeker.java src/main/java/hudson/plugins/testlink/testng/TestNGParser.java src/main/java/hudson/plugins/testlink/util/TestLinkHelper.java src/main/webapp/help-iterativeBuildSteps.html src/main/webapp/help-iterativeBuildSteps_es.html src/main/webapp/help-iterativeBuildSteps_fr.html src/main/webapp/help-iterativeBuildSteps_pt.html src/test/java/hudson/plugins/testlink/TestLinkSiteFake.java src/test/java/hudson/plugins/testlink/TestReportSummary.java src/test/java/hudson/plugins/testlink/result/TestTestNGClassNameResultSeeker.java src/test/java/hudson/plugins/testlink/result/TestTestNGMethodNameResultSeeker.java src/test/java/hudson/plugins/testlink/result/TestTestNGSuiteNameResultSeeker.java src/test/java/hudson/plugins/testlink/result/issue10849/TestPerformance10849.java src/test/java/hudson/plugins/testlink/result/issue11894/TestIssue11894.java src/test/java/hudson/plugins/testlink/result/issue12969/TestIssue12969.java src/test/java/hudson/plugins/testlink/result/issue9054/TestPlatformSupport.java src/test/java/hudson/plugins/testlink/result/issue9229/TestIssue9229.java src/test/java/hudson/plugins/testlink/result/issue9672/TestIssue9672.java src/test/java/hudson/plugins/testlink/result/issue9672/TestTestResultSeekerTAP.java src/test/java/hudson/plugins/testlink/util/TestTestLinkHelper.java http://jenkins-ci.org/commit/testlink-plugin/14362baf8ea138c3a1c99f6620bf9406d45bae8a Log: FIXED JENKINS-10904 As this issue was fixed in testlink-java-api, we had to update its version in pom.xml. And as some of its objects were updated, we partially broke backward compatibility. Users will lose their old data (graphs will be blank, no information in summary in the build action, etc). But no warnings or exceptions. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10904) Include test case step and test case scenario variables when retrieving information of a Test Case
Bruno P. Kinoshita closed JENKINS-10904 as Fixed Include test case step and test case scenario variables when retrieving information of a Test Case Fixed in 3.1.5 Change By: Bruno P. Kinoshita (26/Jul/12 5:28 AM) Status: Resolved Closed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
