[JIRA] (JENKINS-13348) EnvInject overriding WORKSPACE variable
[ https://issues.jenkins-ci.org/browse/JENKINS-13348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161593#comment-161593 ] gbois commented on JENKINS-13348: - Any update? EnvInject overriding WORKSPACE variable --- Key: JENKINS-13348 URL: https://issues.jenkins-ci.org/browse/JENKINS-13348 Project: Jenkins Issue Type: Bug Components: envinject Affects Versions: current Reporter: Jim Searle Assignee: gbois Priority: Blocker I upgraded Jenkins to 1.458 and envinject from 1.36 to 1.44. After the upgrade all my jobs that did not use envinject were getting their WORKSPACE variable set to another jobs that did use envinject WORKSPACE. Downgraded envinject to 1.36 and the problem went away. Here's an edited log that shows initially the workspace is correct, even after EnvInject line, but when the shell script runs, it is wrong. Also, I don't know why EnvInject is even being run for this job since it is not enabled anywhere... [EnvInject] - Preparing an environment for the build. Building on master in workspace --correct-workspace-- Updating http://svn At revision 36652 no change for http://svn since the previous build No emails were triggered. [bronze-bin] $ /bin/sh -xe /tmp/hudson6983282044770433158.sh + echo --some-other-jobs-workspace-- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13360) Envinject fails with UnsupportedMediaException
[ https://issues.jenkins-ci.org/browse/JENKINS-13360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois closed JENKINS-13360. --- Resolution: Cannot Reproduce I'm closing the issue because I can't reproduce it. Envinject fails with UnsupportedMediaException -- Key: JENKINS-13360 URL: https://issues.jenkins-ci.org/browse/JENKINS-13360 Project: Jenkins Issue Type: Bug Components: envinject Environment: JBOSS 7.1.1, FreeBSD 8.2, openjdk 6 Reporter: Radim Kolar Assignee: gbois Priority: Critical Attachments: 1.zip It does this in all cases, even if property file does not exists. [EnvInject] - Preparing an environment for the build. [EnvInject] - [ERROR] - SEVERE ERROR occurs: com/sun/xml/internal/ws/server/UnsupportedMediaException Archiving artifacts EnvInject 1.44 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11839) Do not update mantis entry for all downstream jobs
[ https://issues.jenkins-ci.org/browse/JENKINS-11839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161594#comment-161594 ] sogabe commented on JENKINS-11839: -- Does the downstream project have a mantis-id? Do not update mantis entry for all downstream jobs -- Key: JENKINS-11839 URL: https://issues.jenkins-ci.org/browse/JENKINS-11839 Project: Jenkins Issue Type: Bug Components: mantis Affects Versions: current Environment: Jenkins 1.440 Mantis-Plugin 0.20 Mantis: 1.2.8 Reporter: Jens H Assignee: sogabe I do have a set of jobs depending on each other. If I have a Mantis-ID in a commit message in Project A the Mantis issue is updated correctly from this project. But all other projects depending on Project A will also update this Mantis issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13453) Report passed TODO tests
Bruno P. Kinoshita created JENKINS-13453: Summary: Report passed TODO tests Key: JENKINS-13453 URL: https://issues.jenkins-ci.org/browse/JENKINS-13453 Project: Jenkins Issue Type: Improvement Components: tap Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita It would be good if the plug-in had options to control the behavior with TODO's. It also may need some rework parsing TAP to remove # or other characters to help the user. Moreover, it may not be necessarily a failure, having a TODO test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13454) Optimize the plugin manager
evernat created JENKINS-13454: - Summary: Optimize the plugin manager Key: JENKINS-13454 URL: https://issues.jenkins-ci.org/browse/JENKINS-13454 Project: Jenkins Issue Type: Improvement Components: update-center Environment: Jenkins 1.459, Oracle JDK 1.7, Windows XP Reporter: evernat Assignee: evernat Attachments: monitoring.png In Manage Jenkins, the plugin manager (aka update center) is rather slow. Slow is about 3 to 6 seconds on my windows laptop. The http requests of the plugin manager are mostly the slowest of all, as can be seen in the joined screenshot of the monitoring plugin. The screenshot also shows that those http requests have a high cpu usage. The cause of the issue is that for each plugin, the UpdateSite.getPlugin(String) and getData() methods read and parse all the plugins data from the updates/default.json file each time. So the more plugins are available, the slower it is. I will submit a pull request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13454) Optimize the plugin manager
[ https://issues.jenkins-ci.org/browse/JENKINS-13454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13454 started by evernat. Optimize the plugin manager --- Key: JENKINS-13454 URL: https://issues.jenkins-ci.org/browse/JENKINS-13454 Project: Jenkins Issue Type: Improvement Components: update-center Environment: Jenkins 1.459, Oracle JDK 1.7, Windows XP Reporter: evernat Assignee: evernat Attachments: monitoring.png In Manage Jenkins, the plugin manager (aka update center) is rather slow. Slow is about 3 to 6 seconds on my windows laptop. The http requests of the plugin manager are mostly the slowest of all, as can be seen in the joined screenshot of the monitoring plugin. The screenshot also shows that those http requests have a high cpu usage. The cause of the issue is that for each plugin, the UpdateSite.getPlugin(String) and getData() methods read and parse all the plugins data from the updates/default.json file each time. So the more plugins are available, the slower it is. I will submit a pull request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13448) Guice injector failure can cause failure of whole Jenkins
[ https://issues.jenkins-ci.org/browse/JENKINS-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-13448. Resolution: Fixed Guice injector failure can cause failure of whole Jenkins - Key: JENKINS-13448 URL: https://issues.jenkins-ci.org/browse/JENKINS-13448 Project: Jenkins Issue Type: Bug Components: core Reporter: vjuranek Priority: Critical When Guice fails to create injector (e.g. because some extension point is optional and therefore missing), it can break other plugins and eventually crash whole Jenkins, see e.g. JENKINS-12970, JENKINS-13385, JENKINS-13381. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13448) Guice injector failure can cause failure of whole Jenkins
[ https://issues.jenkins-ci.org/browse/JENKINS-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161595#comment-161595 ] SCM/JIRA link daemon commented on JENKINS-13448: Code changed in jenkins User: Vojtech Juranek Path: core/src/main/java/hudson/ExtensionFinder.java http://jenkins-ci.org/commit/jenkins/6788f82a2c9f8e3580440913c2d39f1d1dc3ad70 Log: [FIXED JENKINS-13448] Added additional checks if Guice will be able to create injector to exclude missing extension poins. Guice injector failure can cause failure of whole Jenkins - Key: JENKINS-13448 URL: https://issues.jenkins-ci.org/browse/JENKINS-13448 Project: Jenkins Issue Type: Bug Components: core Reporter: vjuranek Priority: Critical When Guice fails to create injector (e.g. because some extension point is optional and therefore missing), it can break other plugins and eventually crash whole Jenkins, see e.g. JENKINS-12970, JENKINS-13385, JENKINS-13381. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-1555) Remote triggering of builds requires anonymous user Read permission
[ https://issues.jenkins-ci.org/browse/JENKINS-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161596#comment-161596 ] Herbert Vojčík commented on JENKINS-1555: - Hi, it does not work for me, too (1.458, freebsd). Strange is, IIRC it worked on 1.454 or so, I did not give anonymous any access and it worked. Now, it is problem unless I goive anonymous overall read as well as job read. Remote triggering of builds requires anonymous user Read permission --- Key: JENKINS-1555 URL: https://issues.jenkins-ci.org/browse/JENKINS-1555 Project: Jenkins Issue Type: Bug Components: security Affects Versions: current Environment: Platform: All, OS: All Reporter: subbaer Priority: Minor Attachments: hudson-active-dir-build-anonymous.jpg I stepwise tried to harden my local hudson installation. Security realm is set to Active Directory. From the Anonymous user I removed all Authorization rights. This broke triggering hudson builds using URL with token. To make it work again I had to assign the Overall - read right to the Anonymous user. Actually, I didn't wanted to have Anonymous users see project details. Could the current behavior be changed by checking the Job - Build right prior to triggered builds? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13416) On demand slave provisioning is starting all available slaves
[ https://issues.jenkins-ci.org/browse/JENKINS-13416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161597#comment-161597 ] SCM/JIRA link daemon commented on JENKINS-13416: Code changed in jenkins User: Bruno Meneguello Path: core/src/main/java/hudson/slaves/RetentionStrategy.java http://jenkins-ci.org/commit/jenkins/5a32eca331bf1d5652ab908c356f0ed64de82c6f Log: [FIXED JENKINS-13416] On demand slave provisioning is starting all available slaves On demand slave provisioning is starting all available slaves - Key: JENKINS-13416 URL: https://issues.jenkins-ci.org/browse/JENKINS-13416 Project: Jenkins Issue Type: Bug Components: slave-setup Affects Versions: current Reporter: Bruno Meneguello Assignee: Kohsuke Kawaguchi Priority: Minor Attachments: jenkins-1.459.diff I'm using on demand slaves (on amazon) started by a shell script. When starting a job with all slaves disconnected, all my slaves are started together. When in debug, I'd noticed that RetentionStrategy Demand is testing Computer.getDemandStartMilliseconds() to connect the slave, but all slaves (that 'll take some time to wake up) pass in test. Shouldn't this strategy take in account if there are executor enough and nodes starting? I,ve made a change in RetentionStrategy that solves the problem. Anyone see any problem with this solution? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13416) On demand slave provisioning is starting all available slaves
[ https://issues.jenkins-ci.org/browse/JENKINS-13416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-13416. Resolution: Fixed On demand slave provisioning is starting all available slaves - Key: JENKINS-13416 URL: https://issues.jenkins-ci.org/browse/JENKINS-13416 Project: Jenkins Issue Type: Bug Components: slave-setup Affects Versions: current Reporter: Bruno Meneguello Assignee: Kohsuke Kawaguchi Priority: Minor Attachments: jenkins-1.459.diff I'm using on demand slaves (on amazon) started by a shell script. When starting a job with all slaves disconnected, all my slaves are started together. When in debug, I'd noticed that RetentionStrategy Demand is testing Computer.getDemandStartMilliseconds() to connect the slave, but all slaves (that 'll take some time to wake up) pass in test. Shouldn't this strategy take in account if there are executor enough and nodes starting? I,ve made a change in RetentionStrategy that solves the problem. Anyone see any problem with this solution? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13448) Guice injector failure can cause failure of whole Jenkins
[ https://issues.jenkins-ci.org/browse/JENKINS-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161598#comment-161598 ] dogfood commented on JENKINS-13448: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/yellow.png! [jenkins_main_trunk #1658|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1658/] [FIXED JENKINS-13448] Added additional checks if Guice will be able to create injector to exclude missing extension poins. (Revision 6788f82a2c9f8e3580440913c2d39f1d1dc3ad70) Result = UNSTABLE Vojtech Juranek : [6788f82a2c9f8e3580440913c2d39f1d1dc3ad70|https://github.com/jenkinsci/jenkins/commit/6788f82a2c9f8e3580440913c2d39f1d1dc3ad70] Files : * core/src/main/java/hudson/ExtensionFinder.java Guice injector failure can cause failure of whole Jenkins - Key: JENKINS-13448 URL: https://issues.jenkins-ci.org/browse/JENKINS-13448 Project: Jenkins Issue Type: Bug Components: core Reporter: vjuranek Priority: Critical When Guice fails to create injector (e.g. because some extension point is optional and therefore missing), it can break other plugins and eventually crash whole Jenkins, see e.g. JENKINS-12970, JENKINS-13385, JENKINS-13381. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13454) Optimize the plugin manager
[ https://issues.jenkins-ci.org/browse/JENKINS-13454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161599#comment-161599 ] evernat commented on JENKINS-13454: --- The pull request is at: https://github.com/jenkinsci/jenkins/pull/441 It will reduce the execution time of the http requests from several seconds to around 100 ms (on my windows laptop). Optimize the plugin manager --- Key: JENKINS-13454 URL: https://issues.jenkins-ci.org/browse/JENKINS-13454 Project: Jenkins Issue Type: Improvement Components: update-center Environment: Jenkins 1.459, Oracle JDK 1.7, Windows XP Reporter: evernat Assignee: evernat Attachments: monitoring.png In Manage Jenkins, the plugin manager (aka update center) is rather slow. Slow is about 3 to 6 seconds on my windows laptop. The http requests of the plugin manager are mostly the slowest of all, as can be seen in the joined screenshot of the monitoring plugin. The screenshot also shows that those http requests have a high cpu usage. The cause of the issue is that for each plugin, the UpdateSite.getPlugin(String) and getData() methods read and parse all the plugins data from the updates/default.json file each time. So the more plugins are available, the slower it is. I will submit a pull request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12250) Critical block can not be added into conditional step
[ https://issues.jenkins-ci.org/browse/JENKINS-12250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161600#comment-161600 ] domi commented on JENKINS-12250: did you try again? Critical block can not be added into conditional step - Key: JENKINS-12250 URL: https://issues.jenkins-ci.org/browse/JENKINS-12250 Project: Jenkins Issue Type: Bug Components: conditional-buildstep, exclusion Environment: Jenkins 1.445 Jenkins Exclusion Plug-in 0.6 conditional-buildstep 0.2 Reporter: Oleksandr Popov Assignee: Anthony Roux Priority: Critical Attachments: critical-block.PNG I'm not able to add critical block into conditional step. See screen-shot for details -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11839) Do not update mantis entry for all downstream jobs
[ https://issues.jenkins-ci.org/browse/JENKINS-11839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161602#comment-161602 ] Jens H commented on JENKINS-11839: -- All projekts are connected to the mantis installation. The Trigger-Commit-Message is only in the upstream project. Do not update mantis entry for all downstream jobs -- Key: JENKINS-11839 URL: https://issues.jenkins-ci.org/browse/JENKINS-11839 Project: Jenkins Issue Type: Bug Components: mantis Affects Versions: current Environment: Jenkins 1.440 Mantis-Plugin 0.20 Mantis: 1.2.8 Reporter: Jens H Assignee: sogabe I do have a set of jobs depending on each other. If I have a Mantis-ID in a commit message in Project A the Mantis issue is updated correctly from this project. But all other projects depending on Project A will also update this Mantis issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11839) Do not update mantis entry for all downstream jobs
[ https://issues.jenkins-ci.org/browse/JENKINS-11839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161603#comment-161603 ] sogabe commented on JENKINS-11839: -- Try http://bacons.ddo.jp/download/mantis.hpi . If it's ok, I'll release it. Do not update mantis entry for all downstream jobs -- Key: JENKINS-11839 URL: https://issues.jenkins-ci.org/browse/JENKINS-11839 Project: Jenkins Issue Type: Bug Components: mantis Affects Versions: current Environment: Jenkins 1.440 Mantis-Plugin 0.20 Mantis: 1.2.8 Reporter: Jens H Assignee: sogabe I do have a set of jobs depending on each other. If I have a Mantis-ID in a commit message in Project A the Mantis issue is updated correctly from this project. But all other projects depending on Project A will also update this Mantis issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13455) when a submodule can't be checked out an exception is thrown
frew schmidt created JENKINS-13455:
--
Summary: when a submodule can't be checked out an exception is
thrown
Key: JENKINS-13455
URL: https://issues.jenkins-ci.org/browse/JENKINS-13455
Project: Jenkins
Issue Type: Bug
Components: git
Affects Versions: current
Reporter: frew schmidt
Assignee: Nicolas De Loof
Sometimes developers accidentally forget to push a submodule and thus make it
impossible to check out their changes completely. This causes jenkins to throw
an exception and on the next build it merely tries again and will inevitably
fail. Maybe we should make an option for failed submodules to fail the build
and move on instead of throwing an exception. I'll paste in the console output
when this happened to me here.
The first time:
{noformat}
Started by an SCM change
Building in workspace /var/lib/jenkins/jobs/Lynx/workspace
Checkout:workspace / /var/lib/jenkins/jobs/Lynx/workspace -
hudson.remoting.LocalChannel@aa0ff27
Using strategy: Default
Last Built Revision: Revision 15f062624b185b08d695a0949ede1431fe75bdd5
(origin/feature/LXS-1289-ip.plx-redux)
Fetching changes from 1 remote Git repository
Fetching upstream changes from cs:lynx
Pruning obsolete local branches
Seen branch in repository origin/HEAD
Seen branch in repository origin/LXS/000-dbic-error
Seen branch in repository origin/bug/LXS-000-WebIcons-Pass2Frew
Seen branch in repository origin/bug/LXS-1053-Check-in-Primary
Seen branch in repository origin/bug/LXS-1093-user-password
Seen branch in repository origin/bug/LXS-1094-Account-cleanup
Seen branch in repository origin/bug/LXS-1139-crash
Seen branch in repository origin/bug/LXS-1327-incorrect-sms-errors
Seen branch in repository origin/bug/LXS-1352-snpp-strip-newlines-and-unicode
Seen branch in repository origin/bug/LXS-432-Type-Macro
Seen branch in repository origin/bug/LXS-504-Excel-Openings
Seen branch in repository origin/bug/LXS-774-Shared-RO
Seen branch in repository origin/bug/LXS-948-Log-Shows-Dest-twice
Seen branch in repository origin/bug/LXS-948-log-duplication
Seen branch in repository origin/bug/LXS-971-D-Drive
Seen branch in repository origin/bug/LXS-976-Excel-Button
Seen branch in repository origin/feature/LXS-1060-Active-Dir-SubUsers
Seen branch in repository origin/feature/LXS-1064-Remove-AD-Import
Seen branch in repository origin/feature/LXS-1093-User-Edits
Seen branch in repository origin/feature/LXS-1094-Account-Cleanup
Seen branch in repository origin/feature/LXS-1096-ReadOnly
Seen branch in repository origin/feature/LXS--New-WebIcon
Seen branch in repository origin/feature/LXS--Web-Icon
Seen branch in repository origin/feature/LXS--jason-fix
Seen branch in repository origin/feature/LXS--web-icon-group
Seen branch in repository origin/feature/LXS-1145-remove-theme-and-news
Seen branch in repository origin/feature/LXS-1146-remove-find-Lynxnet
Seen branch in repository origin/feature/LXS-1196-client-database
Seen branch in repository origin/feature/LXS-1198-client-testing
Seen branch in repository origin/feature/LXS-1214-AlarmState
Seen branch in repository origin/feature/LXS-1289-ip.plx-redux
Seen branch in repository origin/feature/LXS-1316-macro-wildcards
Seen branch in repository origin/feature/LXS-1329-database-refactor
Seen branch in repository origin/feature/LXS-1344-ldap-improvements
Seen branch in repository origin/feature/LXS-1349-improved-failover
Seen branch in repository origin/feature/LXS-1353-snpp-logging
Seen branch in repository origin/feature/LXS-1357-apache-2.4.1
Seen branch in repository origin/feature/LXS-865-Excel-Link
Seen branch in repository origin/merge/users
Seen branch in repository origin/merge/webicons
Seen branch in repository origin/preview
Seen branch in repository origin/release
Commencing build of Revision 2cf960767f0bcdcbab95a998aa0d953f3b29db1d
(origin/LXS/000-dbic-error)
Checking out Revision 2cf960767f0bcdcbab95a998aa0d953f3b29db1d
(origin/LXS/000-dbic-error)
Trying to fetch ClientUpdates into
/var/lib/jenkins/jobs/Lynx/workspace/lynx/ClientUpdates
Fetching upstream changes from cs:lynx-client-updates
Trying to fetch Lynxnet into /var/lib/jenkins/jobs/Lynx/workspace/lynx/Lynxnet
Fetching upstream changes from cs:lynx-net
Trying to fetch TrueUpdate into
/var/lib/jenkins/jobs/Lynx/workspace/lynx/TrueUpdate
Fetching upstream changes from cs:lynx-trueupdate
FATAL: Command git submodule update returned status code 1:
stdout: Cloning into ClientUpdates...
Submodule path 'ClientUpdates': checked out
'ae2f708d6d69a30e6a54c77b01f0085ab9305000'
stderr: fatal: reference is not a tree: 371a927a4268afc72316e31f9111ad5463305af9
Unable to checkout '371a927a4268afc72316e31f9111ad5463305af9' in submodule path
'cgi/exe'
hudson.plugins.git.GitException: Command git submodule update returned status
code 1:
stdout: Cloning into ClientUpdates...
Submodule path
[JIRA] (JENKINS-8663) Parsing of POM happens before SNAPSHOT-Parents are updated
[ https://issues.jenkins-ci.org/browse/JENKINS-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161604#comment-161604 ] SCM/JIRA link daemon commented on JENKINS-8663: --- Code changed in jenkins User: Vincent Latombe Path: changelog.html maven-plugin/src/main/java/hudson/maven/MavenEmbedderRequest.java maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java maven-plugin/src/main/java/hudson/maven/MavenUtil.java http://jenkins-ci.org/commit/jenkins/1421ca15d5a36706214476e613eeab789b9066df Log: [FIXED JENKINS-8663] Flag -U is not used during the parsing step of a Maven Job If the -U flag is specified in the goals/options of the build step of a Maven job, it should be used as well in the parsing step. Parsing of POM happens before SNAPSHOT-Parents are updated -- Key: JENKINS-8663 URL: https://issues.jenkins-ci.org/browse/JENKINS-8663 Project: Jenkins Issue Type: Bug Components: maven2 Affects Versions: current Environment: Hudson 1.394 Reporter: Stephan Pauxberger Priority: Blocker Given the following constellation. Project A 1.0-SNAPSHOT (POM only) Project B 1.0-SNAPSHOT (Jar, has A as parent) Both jobs use private Maven repositories. Both projects have a separate job. Change something in project A, commit. Job A builds and deploys to repository Change something in project B that dependes on changes in project A. Commit. Job B starts an resolves the POM using the old parent POM, potentially leading to a broken build. For example: B declares a dependency WITH a version. Now remove the version from B and enter a dependencyManagement entry into A. Commit A, later B. Result: B fails because pom validation has no valid version for the dependency. Only solution (since private repositories are used): Clean workspace of B via Webinterface, the rebuild B. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8663) Parsing of POM happens before SNAPSHOT-Parents are updated
[ https://issues.jenkins-ci.org/browse/JENKINS-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161605#comment-161605 ] SCM/JIRA link daemon commented on JENKINS-8663: --- Code changed in jenkins User: Olivier Lamy Path: changelog.html maven-plugin/src/main/java/hudson/maven/MavenEmbedderRequest.java maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java maven-plugin/src/main/java/hudson/maven/MavenUtil.java http://jenkins-ci.org/commit/jenkins/f0130bf1b2410807fccf4f0c9af259201151228a Log: Merge pull request #442 from Vlatombe/JENKINS-8663 [FIXED JENKINS-8663] Flag -U is not used during the parsing step of a Maven Job good catch ! Compare: https://github.com/jenkinsci/jenkins/compare/0f08dc0...f0130bf Parsing of POM happens before SNAPSHOT-Parents are updated -- Key: JENKINS-8663 URL: https://issues.jenkins-ci.org/browse/JENKINS-8663 Project: Jenkins Issue Type: Bug Components: maven2 Affects Versions: current Environment: Hudson 1.394 Reporter: Stephan Pauxberger Priority: Blocker Given the following constellation. Project A 1.0-SNAPSHOT (POM only) Project B 1.0-SNAPSHOT (Jar, has A as parent) Both jobs use private Maven repositories. Both projects have a separate job. Change something in project A, commit. Job A builds and deploys to repository Change something in project B that dependes on changes in project A. Commit. Job B starts an resolves the POM using the old parent POM, potentially leading to a broken build. For example: B declares a dependency WITH a version. Now remove the version from B and enter a dependencyManagement entry into A. Commit A, later B. Result: B fails because pom validation has no valid version for the dependency. Only solution (since private repositories are used): Clean workspace of B via Webinterface, the rebuild B. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11839) Do not update mantis entry for all downstream jobs
[ https://issues.jenkins-ci.org/browse/JENKINS-11839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161609#comment-161609 ] Jens H commented on JENKINS-11839: -- I will try on monday. Before that I have no access to the system. Thanks for the fix. Do not update mantis entry for all downstream jobs -- Key: JENKINS-11839 URL: https://issues.jenkins-ci.org/browse/JENKINS-11839 Project: Jenkins Issue Type: Bug Components: mantis Affects Versions: current Environment: Jenkins 1.440 Mantis-Plugin 0.20 Mantis: 1.2.8 Reporter: Jens H Assignee: sogabe I do have a set of jobs depending on each other. If I have a Mantis-ID in a commit message in Project A the Mantis issue is updated correctly from this project. But all other projects depending on Project A will also update this Mantis issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13105) allow j/k navigation for search results
[ https://issues.jenkins-ci.org/browse/JENKINS-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161611#comment-161611 ] dogfood commented on JENKINS-13105: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_main_trunk #1660|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1660/] [JENKINS-13105] for keyboard shortcuts plugin, allow j/k navigation for search results (Revision 5a0f1aa3a4da962bf29ebca6a4556f1617045005) Result = SUCCESS Jesse Farinacci : [5a0f1aa3a4da962bf29ebca6a4556f1617045005|https://github.com/jenkinsci/jenkins/commit/5a0f1aa3a4da962bf29ebca6a4556f1617045005] Files : * core/src/main/resources/hudson/search/Search/search-failed.jelly allow j/k navigation for search results --- Key: JENKINS-13105 URL: https://issues.jenkins-ci.org/browse/JENKINS-13105 Project: Jenkins Issue Type: New Feature Components: keyboard-shortcuts Reporter: jieryn Assignee: jieryn e.g. results page for :: http://ci.jenkins-ci.org/view/Plugins/search/?q=perforce -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8663) Parsing of POM happens before SNAPSHOT-Parents are updated
[ https://issues.jenkins-ci.org/browse/JENKINS-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161610#comment-161610 ] dogfood commented on JENKINS-8663: -- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_main_trunk #1660|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1660/] [FIXED JENKINS-8663] Flag -U is not used during the parsing step of a (Revision 1421ca15d5a36706214476e613eeab789b9066df) Result = SUCCESS Vincent Latombe : [1421ca15d5a36706214476e613eeab789b9066df|https://github.com/jenkinsci/jenkins/commit/1421ca15d5a36706214476e613eeab789b9066df] Files : * maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java * changelog.html * maven-plugin/src/main/java/hudson/maven/MavenEmbedderRequest.java * maven-plugin/src/main/java/hudson/maven/MavenUtil.java Parsing of POM happens before SNAPSHOT-Parents are updated -- Key: JENKINS-8663 URL: https://issues.jenkins-ci.org/browse/JENKINS-8663 Project: Jenkins Issue Type: Bug Components: maven2 Affects Versions: current Environment: Hudson 1.394 Reporter: Stephan Pauxberger Priority: Blocker Given the following constellation. Project A 1.0-SNAPSHOT (POM only) Project B 1.0-SNAPSHOT (Jar, has A as parent) Both jobs use private Maven repositories. Both projects have a separate job. Change something in project A, commit. Job A builds and deploys to repository Change something in project B that dependes on changes in project A. Commit. Job B starts an resolves the POM using the old parent POM, potentially leading to a broken build. For example: B declares a dependency WITH a version. Now remove the version from B and enter a dependencyManagement entry into A. Commit A, later B. Result: B fails because pom validation has no valid version for the dependency. Only solution (since private repositories are used): Clean workspace of B via Webinterface, the rebuild B. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
