[JIRA] [master-slave] (JENKINS-18205) Archiving Artifacts slow with Windows JNLP Slave
Sven Amann created JENKINS-18205 Archiving Artifacts slow with Windows JNLP Slave Issue Type: Bug Assignee: Unassigned Components: master-slave Created: 05/Jun/13 7:28 AM Description: We hoped to see improvements after JENKINS-7813 was closed, but after we moved to 1.509 our buildjobs still need over 10 minutes to archive the ~100MB of our 15 artifacts. Does anyone else still experience this problem? Is this related to the slave connecting over JNLP (I don't see this setup mentioned in the referenced issue)? Environment: Host is Ubuntu 12.04 (running Jenkins 1.509) Slave is Windows XP (running in VM on the host) Project: Jenkins Priority: Major Reporter: Sven Amann 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-15720) Deploy Artifacts to Maven Repository only resolves Repository ID against POM, not settings.xml
Sven Amann commented on JENKINS-15720 Deploy Artifacts to Maven Repository only resolves Repository ID against POM, not settings.xml There is no deploy war/ear to container component... how is it called? 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-15720) Deploy Artifacts to Maven Repository only resolves Repository ID against POM, not settings.xml
Sven Amann created JENKINS-15720 Deploy Artifacts to Maven Repository only resolves Repository ID against POM, not settings.xml Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: deploy, maven Created: 05/Nov/12 1:29 PM Description: The "Deploy artifacts to maven repository" action allows for specification of the repository id to name the deploy target. If a respective repository is specified in the projects pom, the id is successfully resolved to the corresponding URL an deploy succeeds. If, however, the repository is specified only in the (global or user) settings.xml file, it is resolved. I see that there is an acceptable workaround and repository URL tend not to change to often, but it would still be nice not to have to retype it for every job. And if you ever have to migrate to a new server, as I just did, it would save some annoyance with correcting the URL in each and every job! Environment: Platform independent Project: Jenkins Priority: Minor Reporter: Sven Amann 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-15503) Test results lost on all past builds
Sven Amann resolved JENKINS-15503 as Fixed Test results lost on all past builds The issue has vanished for me as of version 1.487 (stable till 1.489), I consider this as resolved. Change By: Sven Amann (05/Nov/12 1:34 PM) Status: Open Resolved Fix Version/s: current 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-15503) Test results lost on all past builds
Sven Amann commented on JENKINS-15503 Test results lost on all past builds For us the bug disappeared with upgrade to 467. Unfortunately now there is JENKINS-15601 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-15503) Test results lost on all past builds
Sven Amann edited a comment on JENKINS-15503 Test results lost on all past builds For us the bug disappeared with upgrade to 467. Unfortunately now there is JENKINS-15601 (just so you know in case you consider an update) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15503) Test results lost on all past builds
Sven Amann commented on JENKINS-15503 Test results lost on all past builds Ups, sure do! Sorry for the typo! 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-15503) Test results lost on all past builds
Sven Amann commented on JENKINS-15503 Test results lost on all past builds I made a downgrade to 1.484 due to other issues and all missing results are back again, so, no actual data loss is experienced! Unfortunately though, the "missing" test results messed up some unstable/stable states. 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-15503) Test results lost on all past builds
Sven Amann created JENKINS-15503 Test results lost on all past builds Issue Type: Bug Affects Versions: current Assignee: Unassigned Attachments: Screen Shot 2012-10-12 at 09.33.38.png Components: core Created: 12/Oct/12 7:44 AM Description: Test results are missing on all but the last build, i.e., the build and test result overview page still displays the number of failed tests, but the concrete tests are not listed/linked (see attachment and our build server). Environment: Jenkins on Ubuntu Lucid Lynx with build slave on Windows XP Project: Jenkins Labels: testreport testing Priority: Critical Reporter: Sven Amann 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-15292) RedeployPublisher no longer falls back to $M2_HOME/conf/settings.xml
Sven Amann commented on JENKINS-15292 RedeployPublisher no longer falls back to $M2_HOME/conf/settings.xml From the respective changeset I take that maven default settings are considered automatically if MVN_HOME is set, right? The error occurs in case the user-wise maven config doesn't exist, because the code tries to copy the file anyways what results in FNF. Therefore, if the code doesn't need to fall back to the maven default config, because that happens automatically, you should just avoid the copy in case the target file is missing? I'm not sure about how the config files behave 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-15292) RedeployPublisher no longer falls back to $M2_HOME/conf/settings.xml
Sven Amann created JENKINS-15292 RedeployPublisher no longer falls back to $M2_HOME/conf/settings.xml Issue Type: Bug Affects Versions: current Assignee: Gregory Boissinot Components: artifactdeployer Created: 25/Sep/12 6:29 AM Description: Commit 51d5220f6c19c4e7d5c35a07b62219472b2a7870 changed the RedeployPublisher such that the global Maven settings are no longer checked as fallback, if no per user configuration is found. The Build Slave is running as a service and thus as no user. Hence, the RedeployPublisher requires the configuration to be in C:\.m2\. As a result I have to copy the settings.xml to this location, and maintain both identical files in order to have it available for the service as well as when I log in to the machine manually. Environment: Build Master on Ubuntu, Build Slave on Windows XP as a service Project: Jenkins Priority: Major Reporter: Sven Amann 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-15292) RedeployPublisher no longer falls back to $M2_HOME/conf/settings.xml
Sven Amann updated JENKINS-15292 RedeployPublisher no longer falls back to $M2_HOME/conf/settings.xml Change By: Sven Amann (25/Sep/12 6:45 AM) Component/s: maven2 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-6122) Analysis plugins should recognize non-changed modules in multimodule builds
Sven Amann commented on JENKINS-6122 Analysis plugins should recognize non-changed modules in multimodule builds We're experiencing the same behavior, that immensely hinders our struggle to reduce build times in our Maven multi-module project, while getting the most out of the great static analysis features. Are there any suggestions how to work around this issue for now? Jenkins 1.470 Static Analysis Utilities 1.42 Static Analysis Collector Plug-in 1.28 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
