[JIRA] (JENKINS-16045) Subversion plugin doesn't adhere getAffectedPaths() contract
kutzi commented on JENKINS-16045 Subversion plugin doesnt adhere getAffectedPaths() contract Unfortunately, the contract of getAffectedPath() and getAffectedFiles() is not very clear (at least to me). https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/scm/ChangeLogSet.java In fact, it implies that paths should be relative to workspace root, but doesn't say so explicitely. Also getAffectedFiles() seems to be differ substantially in the svn implementation, because - AFAI can see - it doesn't use the preparePath method. This seems to be a big mess. However, unfortunately I cannot see, how to change this without severely breaking backwards compatibility. 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-16198) Redeploy Artifacts functionality add ability to change build's status according to redeploy status.
kutzi commented on JENKINS-16198 Redeploy Artifacts functionality add ability to change builds status according to redeploy status. By 'fixed', I've meant that a build's result can't and shouldn't be changed after a certain stage in the build's run and certainly not after the build completed. This would literally open a can of worms IMHO. For example there are several 'reporters' (e.g. emailing build results) depending on the fact that the build status is fixed at a certain point in time. I'm not sure about the 'can't' part as you've certainly tried that changing the build status later works for you, right? But I'm positive about the 'shouldn't' part for the reasons mentioned above. I'm wondering why it's a problem for you that the build stays red after successful redeploying? 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-16198) Redeploy Artifacts functionality add ability to change build's status according to redeploy status.
kutzi
edited a comment on JENKINS-16198
Redeploy Artifacts functionality add ability to change builds status according to redeploy status.
BTW: this is the implementation of setResult() in AbstractBuild (resp. Run) which basically says that changing the build status later and also changing the build status to the better is not possible:
public void setResult(Result r) {
// state can change only when we are building
assert state==State.BUILDING;
// result can only get worse
if(result==null) {
result = r;
LOGGER.log(FINE, toString()+" : result is set to "+r,new Exception());
} else {
if(r.isWorseThan(result)) {
LOGGER.log(FINE, toString()+" : result is set to "+r,new Exception());
result = r;
}
}
}
Have you really tried your patch?
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16198) Redeploy Artifacts functionality add ability to change build's status according to redeploy status.
kutzi commented on JENKINS-16198 Redeploy Artifacts functionality add ability to change builds status according to redeploy status. I've already understood why the build is failing. I still stand by my assessment that - even if it would work - it would be a bad idea to change the build result after the build completed - for the reasons mentioned above. Your build managers just being 'frustrated' because of this is IMHO not a valid reason to change this behaviour. If that's really an issue for you, you can try to find other ways around it. For example: restarting the whole build split the build into 2 (compile and deploy) builds and only restart the deploy build, if deployment failed 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-16198) Redeploy Artifacts functionality add ability to change build's status according to redeploy status.
kutzi edited a comment on JENKINS-16198 Redeploy Artifacts functionality add ability to change builds status according to redeploy status. So - as I've understood your last comment - you've not actually confirmed that your patch will work as intended, right? According to the implementation of setResult() it wouldn't work anyway or what would you say? 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-16198) Redeploy Artifacts functionality add ability to change build's status according to redeploy status.
kutzi commented on JENKINS-16198 Redeploy Artifacts functionality add ability to change builds status according to redeploy status. As stated before, changing the build result after a given point (i.e. before the notifiers run) and especially after the build completed, is a bad idea. This would raise all kinds of questions, which you don't really like to have to answer. E.g.: should notifiers run again? what if the 1st redeploy is successful and the 2nd redeploy fails - should the result be set to failure, again? 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-16198) Redeploy Artifacts functionality add ability to change build's status according to redeploy status.
kutzi resolved JENKINS-16198 as Wont Fix Redeploy Artifacts functionality add ability to change builds status according to redeploy status. Closing as Won't Fix for the reasons mentioned. Feel free to start a discussion about this on the developers list or the IRC channel, if you still disagree. Change By: kutzi (28/Dec/12 12:40 PM) Status: Open Resolved Resolution: WontFix 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-16183) Jabber Plugin does not work with Openfire 3.7.1
kutzi updated JENKINS-16183 Jabber Plugin does not work with Openfire 3.7.1 Change By: kutzi (28/Dec/12 12:46 PM) Due Date: 14/Jan/13 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-16226) Tools.jar is not included in classpath of maven project
kutzi resolved JENKINS-16226 as Not A Defect Tools.jar is not included in classpath of maven project Change By: kutzi (29/Dec/12 9:10 PM) Status: InProgress 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-16226) Tools.jar is not included in classpath of maven project
kutzi commented on JENKINS-16226 Tools.jar is not included in classpath of maven project According to your output JAVA_HOME seems to point to an JRE instead of a JDK: java.home = /var/lib/jenkins/tools/hudson.model.JDK/Sun_JDK/jre This seems more like a configuration problem than a bug. Please use the users mailing list for such 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-16232) !build abort works even if bot doesn't have cancel permissions
kutzi commented on JENKINS-16232 !build abort works even if bot doesnt have cancel permissions Thanks for pointing this out! Can you append the message where the bot complains that it couldn't abort the build? I couldn't see any permission checking there and wonder where this message comes from. 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-16232) !build abort works even if bot doesn't have cancel permissions
kutzi commented on JENKINS-16232 !build abort works even if bot doesnt have cancel permissions Thanks, that pointed me to another minor bug that the bug would always print this - regardless if the abort succeeded or not. 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-16163) NullPointerException when sending post build emails - all triggers appear to be impacted
kutzi commented on JENKINS-16163 NullPointerException when sending post build emails - all triggers appear to be impacted If there were changes in core which can break plugins in such a way, is there a bug reported against core already? 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-16181) Jenkins does not try to resend a failed e-mail
kutzi commented on JENKINS-16181 Jenkins does not try to resend a failed e-mail IMHO Jenkins is not responsible for reliable e-mail delivery (if you want such thing, you should make your e-mail infrastructure reliable). But some - not too many! - retries probably won't hurt! But remember that this may needlessly delay the completion of jobs if the e-mail server continues to be unavailable. 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-16163) NullPointerException when sending post build emails - all triggers appear to be impacted
kutzi commented on JENKINS-16163 NullPointerException when sending post build emails - all triggers appear to be impacted Then maybe we should reopen this and assign this to core? The split-out of the Mailer should be transparent to all plugins relying on it. If it's not that's clearly a bug in core. 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-11154) Repository_depth_option variable is missing from Source Code Managments
kutzi resolved JENKINS-11154 as Fixed Repository_depth_option variable is missing from Source Code Managments Fixed with JENKINS-777 Change By: kutzi (02/Jan/13 10:30 PM) Status: Open Resolved Assignee: KohsukeKawaguchi kutzi 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-8334) maven-plugin insists on Surefire to run tests
kutzi assigned JENKINS-8334 to kutzi maven-plugin insists on Surefire to run tests Change By: kutzi (03/Jan/13 1:01 PM) Assignee: kutzi 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-8334) maven-plugin insists on Surefire to run tests
kutzi commented on JENKINS-8334 maven-plugin insists on Surefire to run tests Why not just check for junit xml files after all the plugins have executed? That's just not how the Maven jobs work and it would mean a major refactoring to change that - and I'm not even positive that this is a desirable change. 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-8334) maven-plugin insists on Surefire to run tests
kutzi commented on JENKINS-8334 maven-plugin insists on Surefire to run tests Using a startup switch - like hhuynh - is maybe not a good solution as this would AFAIK mean that every executed mojo (not just test mojos) is handled by the SurefireArchiver - which could mean a significant overhead. 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-8334) maven-plugin insists on Surefire to run tests
kutzi commented on JENKINS-8334 maven-plugin insists on Surefire to run tests Sounds reasonable. I'll look into it. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8334) maven-plugin insists on Surefire to run tests
kutzi commented on JENKINS-8334 maven-plugin insists on Surefire to run tests I've created a pull request with a proposed fix: https://github.com/jenkinsci/jenkins/pull/668 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-13188) Recognize test results from com.github.searls:jasmine-maven-plugin
kutzi resolved JENKINS-13188 as Duplicate Recognize test results from com.github.searls:jasmine-maven-plugin Change By: kutzi (05/Jan/13 10:27 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-12046) TestNG shouldn't look for result files if build was aborted
kutzi commented on JENKINS-12046 TestNG shouldnt look for result files if build was aborted 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-8334) maven-plugin insists on Surefire to run tests
kutzi commented on JENKINS-8334 maven-plugin insists on Surefire to run tests I you like to test the pull request on a 'real' Jenkins environment - which would be great - here's a link to a build: http://dl.dropbox.com/u/25863594/subversion.hpi 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-12127) Maven incremental build doesn't work when changes are in svn:externals
kutzi commented on JENKINS-12127 Maven incremental build doesnt work when changes are in svn:externals @Tom A.: you're using Hudson or 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-8334) maven-plugin insists on Surefire to run tests
kutzi commented on JENKINS-8334 maven-plugin insists on Surefire to run tests Sorry, I was confusing this with another issue I'm working on. 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-8334) maven-plugin insists on Surefire to run tests
kutzi edited a comment on JENKINS-8334 maven-plugin insists on Surefire to run tests I you like to test the pull request on a 'real' Jenkins environment - which would be great - here's a link to a build (deleted) 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-12127) Maven incremental build doesn't work when changes are in svn:externals
kutzi commented on JENKINS-12127 Maven incremental build doesnt work when changes are in svn:externals So I wonder why you post this question in the Jenkins JIRA instead of the Hudson issue tracker. 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-12127) Maven incremental build doesn't work when changes are in svn:externals
kutzi commented on JENKINS-12127 Maven incremental build doesnt work when changes are in svn:externals Almost all of the current Jenkins plugins won't work with Hudson. 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-16311) Feature to display contributory upstream job changes in downstream builds
kutzi commented on JENKINS-16311 Feature to display contributory upstream job changes in downstream builds I cannot see how this is related to the Downstream-Ext plugin This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16311) Feature to display contributory upstream job changes in downstream builds
kutzi updated JENKINS-16311 Feature to display contributory upstream job changes in downstream builds Change By: kutzi (12/Jan/13 4:43 PM) Assignee: kutzi Component/s: core Component/s: downstream-ext 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-16183) Jabber Plugin does not work with Openfire 3.7.1
kutzi resolved JENKINS-16183 as Incomplete Jabber Plugin does not work with Openfire 3.7.1 No response from reporter = closing Change By: kutzi (12/Jan/13 4:50 PM) Status: Open Resolved Resolution: Incomplete 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-16376) BuildStepMonitor.BUILD makes concurrent builds wait, could be changed to BuildStepMonitor.NONE?
kutzi commented on JENKINS-16376 BuildStepMonitor.BUILD makes concurrent builds wait, could be changed to BuildStepMonitor.NONE? IMO we actually do need BuildStepMonitor.BUILD - e.g. if a 'fixed' trigger is used. Otherwise you couldn't determin if a build is a fix for the previous 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-16376) BuildStepMonitor.BUILD makes concurrent builds wait, could be changed to BuildStepMonitor.NONE?
kutzi commented on JENKINS-16376 BuildStepMonitor.BUILD makes concurrent builds wait, could be changed to BuildStepMonitor.NONE? What we could do is: check if we have a trigger which needs the previous build's result (fixed, still xyz) and only then require BuildStepMonitor.BUILD. But I'm not sure if this would be worth the effort and not being more unintuitive to use. 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-16383) add option for SSL connection instead of SASL
kutzi commented on JENKINS-16383 add option for SSL connection instead of SASL The plugin should transparently support legacy style SSL. Have you actually tried if it works? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16112) Provide option to either suppress commit or collapse changes into a single commit
kutzi updated JENKINS-16112 Provide option to either suppress commit or collapse changes into a single commit Change By: kutzi (16/Jan/13 11:04 PM) Issue Type: Bug NewFeature Priority: Major Minor This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16383) add option for SSL connection instead of SASL
kutzi resolved JENKINS-16383 as Not A Defect add option for SSL connection instead of SASL Change By: kutzi (16/Jan/13 11:10 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-15440) Emailing users at the end of a failed build very slow for big Jenkins instance using subversion
kutzi commented on JENKINS-15440 Emailing users at the end of a failed build very slow for big Jenkins instance using subversion This just completely killed our server, because this also seems to be triggered by requests to //job/JOBNAME/api/json I have to figure out where these request come from, but generally I think that this resolving 'feature' is after all a very bad idea. I'd really like to remove it altogether as I cannot really think of any scenario where this would have been actually useful (given the legacy state of the previously used hard-coded svn repositories) 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-16389) Emailing users at the end of a failed build very slow for big Jenkins instance using CVS
kutzi updated JENKINS-16389 Emailing users at the end of a failed build very slow for big Jenkins instance using CVS Change By: kutzi (17/Jan/13 12:37 PM) Environment: Jenkins1.447LTS Subversion1.35AlthoughbothJenkinsandsubversionpluginarenotlatestversion,IhavebrowsedgithubforlatestversionsandIbelievethisissuetostillbepresent. Component/s: cvs Component/s: subversion 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-16389) Emailing users at the end of a failed build very slow for big Jenkins instance using CVS
kutzi updated JENKINS-16389 Emailing users at the end of a failed build very slow for big Jenkins instance using CVS Change By: kutzi (17/Jan/13 12:37 PM) Description: Attheendofafailingbuild,thehudson.tasks.MailSender.buildCulpritListdetermineswhotoemail.Theproblemcomeswhenhudson.scm. SubversionMailAddressResolverImpl MailAddressResolverImpl .findMailAddressFordeterminestheemailaddressoftheuserbyfindingallbuildsauserhascommittedto.ThisisdonebyiteratingovereverysingleJenkinsproject(hudson.model.User.getProjects()firstfindsallprojectsandthenusesAbstractProject.hasParticipant-whichreadsthechangelogtoseeiftheuserparticipated).Foralargesystem(wehavetensofthousandsofbuilds),thisisnotatallefficient.UnfortunatelyfindMailAddressFortakesauserandnotaproject(astheobviousimplementationwouldbetoworkouttheemailaddressfromthecommit).Also,theresultsarentcachedandsothisisrunforeveryusereverytime.Imnotsureifthiscanberesolvedwithjustafixtothesubversion-plugin This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16389) Emailing users at the end of a failed build very slow for big Jenkins instance using CVS
kutzi created JENKINS-16389 Emailing users at the end of a failed build very slow for big Jenkins instance using CVS Issue Type: Bug Affects Versions: current Assignee: kutzi Components: subversion Created: 17/Jan/13 12:36 PM Description: At the end of a failing build, the hudson.tasks.MailSender.buildCulpritList determines who to email. The problem comes when hudson.scm.SubversionMailAddressResolverImpl.findMailAddressFor determines the email address of the user by finding all builds a user has committed to. This is done by iterating over every single Jenkins project (hudson.model.User.getProjects() first finds all projects and then uses AbstractProject.hasParticipant - which reads the changelog to see if the user participated). For a large system (we have tens of thousands of builds), this is not at all efficient. Unfortunately findMailAddressFor takes a user and not a project (as the obvious implementation would be to work out the email address from the commit). Also, the results aren't cached and so this is run for every user every time. I'm not sure if this can be resolved with just a fix to the subversion-plugin Environment: Jenkins 1.447 LTS Subversion 1.35 Although both Jenkins and subversion plugin are not latest version, I have browsed github for latest versions and I believe this issue to still be present. Project: Jenkins Labels: performance Priority: Minor Reporter: kutzi 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-16389) Emailing users at the end of a failed build very slow for big Jenkins instance using CVS
kutzi updated JENKINS-16389 Emailing users at the end of a failed build very slow for big Jenkins instance using CVS Change By: kutzi (17/Jan/13 12:39 PM) Description: BasicallythesameissueasJENKINS-15440,onlyforCVS.Descriptionwasmainlycopiedfromthere. Attheendofafailingbuild,thehudson.tasks.MailSender.buildCulpritListdetermineswhotoemail.Theproblemcomeswhenhudson.scm.MailAddressResolverImpl.findMailAddressFordeterminestheemailaddressoftheuserbyfindingallbuildsauserhascommittedto.ThisisdonebyiteratingovereverysingleJenkinsproject(hudson.model.User.getProjects()firstfindsallprojectsandthenusesAbstractProject.hasParticipant-whichreadsthechangelogtoseeiftheuserparticipated).Foralargesystem(wehavetensofthousandsofbuilds),thisisnotatallefficient.UnfortunatelyfindMailAddressFortakesauserandnotaproject(astheobviousimplementationwouldbetoworkouttheemailaddressfromthecommit).Also,theresultsarentcachedandsothisisrunforeveryusereverytime. Imnotsureifthiscanberesolvedwithjustafixtothesubversion-plugin This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15763) Publisher hudson.tasks.Mailer aborted due to exception
kutzi commented on JENKINS-15763 Publisher hudson.tasks.Mailer aborted due to exception @christopeM: no, it isn't 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-16394) Subversion polling broken
kutzi created JENKINS-16394 Subversion polling broken Issue Type: Bug Assignee: Unassigned Components: subversion Created: 17/Jan/13 3:01 PM Description: Repository polling is borken in the (not yet released) version 1.45 This seems to be related to this commit: https://github.com/jenkinsci/subversion-plugin/blob/a3583f4378576d8932eaeb9514799df6225c7e60/src/main/java/hudson/scm/DefaultSVNLogFilter.java Subversion Polling Log Started on Jan 17, 2013 2:51:36 PM FATAL: Unable to serialize hudson.scm.SubversionSCM$1@785d4fe4 java.io.IOException: Unable to serialize hudson.scm.SubversionSCM$1@785d4fe4 at hudson.remoting.UserRequest.serialize(UserRequest.java:166) at hudson.remoting.UserRequest.init(UserRequest.java:62) at hudson.remoting.Channel.call(Channel.java:667) at hudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1274) at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:355) at hudson.scm.SCM.poll(SCM.java:372) at hudson.model.AbstractProject.poll(AbstractProject.java:1324) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.NotSerializableException: hudson.scm.DefaultSVNLogFilter at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) at hudson.remoting.UserRequest._serialize(UserRequest.java:155) at hudson.remoting.UserRequest.serialize(UserRequest.java:164) ... 15 more Done. Took 1.6 sec No changes Project: Jenkins Priority: Blocker Reporter: kutzi 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-16394) Subversion polling broken
kutzi assigned JENKINS-16394 to Brent Atkinson Subversion polling broken Change By: kutzi (17/Jan/13 3:01 PM) Assignee: BrentAtkinson 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-16394) Subversion polling broken
kutzi updated JENKINS-16394 Subversion polling broken Change By: kutzi (17/Jan/13 3:01 PM) Description: Repositorypollingis borken broken inthe(notyetreleased)version1.45Thisseemstoberelatedtothiscommit:https://github.com/jenkinsci/subversion-plugin/blob/a3583f4378576d8932eaeb9514799df6225c7e60/src/main/java/hudson/scm/DefaultSVNLogFilter.javaSubversionPollingLogStartedonJan17,20132:51:36PMFATAL:Unabletoserializehudson.scm.SubversionSCM$1@785d4fe4java.io.IOException:Unabletoserializehudson.scm.SubversionSCM$1@785d4fe4 athudson.remoting.UserRequest.serialize(UserRequest.java:166) athudson.remoting.UserRequest.init(UserRequest.java:62) athudson.remoting.Channel.call(Channel.java:667) athudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1274) athudson.scm.SCM._compareRemoteRevisionWith(SCM.java:355) athudson.scm.SCM.poll(SCM.java:372) athudson.model.AbstractProject.poll(AbstractProject.java:1324) athudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420) athudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449) athudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) atjava.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) atjava.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) atjava.util.concurrent.FutureTask.run(FutureTask.java:138) atjava.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) atjava.lang.Thread.run(Thread.java:662)Causedby:java.io.NotSerializableException:hudson.scm.DefaultSVNLogFilter atjava.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164) atjava.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) atjava.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) atjava.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) atjava.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) atjava.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) atjava.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) atjava.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) atjava.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) atjava.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) athudson.remoting.UserRequest._serialize(UserRequest.java:155) athudson.remoting.UserRequest.serialize(UserRequest.java:164) ...15moreDone.Took1.6secNochanges 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-16394) Subversion polling broken
kutzi
updated JENKINS-16394
Subversion polling broken
Change By:
kutzi
(17/Jan/13 3:10 PM)
Description:
Repositorypollingisbrokeninthe(notyetreleased)version1.45Thisseemstoberelatedtothiscommit:https://github.com/jenkinsci/subversion-plugin/blob/a3583f4378576d8932eaeb9514799df6225c7e60/src/main/java/hudson/scm/DefaultSVNLogFilter.java
{code}
SubversionPollingLogStartedonJan17,20132:51:36PMFATAL:Unabletoserializehudson.scm.SubversionSCM$1@785d4fe4java.io.IOException:Unabletoserializehudson.scm.SubversionSCM$1@785d4fe4 athudson.remoting.UserRequest.serialize(UserRequest.java:166) athudson.remoting.UserRequest.init(UserRequest.java:62) athudson.remoting.Channel.call(Channel.java:667) athudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1274) athudson.scm.SCM._compareRemoteRevisionWith(SCM.java:355) athudson.scm.SCM.poll(SCM.java:372) athudson.model.AbstractProject.poll(AbstractProject.java:1324) athudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420) athudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449) athudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) atjava.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) atjava.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) atjava.util.concurrent.FutureTask.run(FutureTask.java:138) atjava.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) atjava.lang.Thread.run(Thread.java:662)Causedby:java.io.NotSerializableException:hudson.scm.DefaultSVNLogFilter atjava.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164) atjava.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) atjava.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) atjava.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) atjava.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) atjava.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) atjava.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) atjava.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) atjava.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) atjava.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) athudson.remoting.UserRequest._serialize(UserRequest.java:155) athudson.remoting.UserRequest.serialize(UserRequest.java:164) ...15moreDone.Took1.6secNochanges
{code}
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-16394) Subversion polling broken
kutzi assigned JENKINS-16394 to kutzi Subversion polling broken Change By: kutzi (17/Jan/13 4:27 PM) Assignee: BrentAtkinson kutzi 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-16342) asynchPeople very slow when using Gravatar Subversion plugins
kutzi commented on JENKINS-16342 asynchPeople very slow when using Gravatar Subversion plugins SubversionMailAddressResolverImpl should probably be rewritten to perform its calculations in a long-running process and cache them. Or maybe this should just be deleted and the problem solved in a different way. Absolutely +1 for deleting this - as well as in all other SCM plugin where something analogue is implemented! These MailAddressResolvers are implemented in a so ridiculous inefficient way and their usefulness is IMHO very very limited. 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-16389) Emailing users at the end of a failed build very slow for big Jenkins instance using CVS
kutzi assigned JENKINS-16389 to Unassigned Emailing users at the end of a failed build very slow for big Jenkins instance using CVS Change By: kutzi (18/Jan/13 3:40 PM) Assignee: kutzi 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-16099) Not able to enter correct SVN credentials
kutzi assigned JENKINS-16099 to Kohsuke Kawaguchi Not able to enter correct SVN credentials Change By: kutzi (19/Jan/13 8:19 AM) Assignee: kutzi KohsukeKawaguchi 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-11277) Fix MavenMultiModuleTest.testEstimatedDurationForIncrementalMultiModMaven test
kutzi commented on JENKINS-11277 Fix MavenMultiModuleTest.testEstimatedDurationForIncrementalMultiModMaven test The unit test is still there but disabled. 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-16121) maven-soapui-plugin configurable outputFolder
kutzi assigned JENKINS-16121 to kutzi maven-soapui-plugin configurable outputFolder Change By: kutzi (20/Jan/13 10:55 AM) Assignee: kutzi 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-16121) maven-soapui-plugin configurable outputFolder
kutzi resolved JENKINS-16121 as Fixed maven-soapui-plugin configurable outputFolder Should also be fixed by fix for JENKINS-8334 https://github.com/jenkinsci/jenkins/commit/79fbe28bb4920d397847f52800f59d0c355038b5 Change By: kutzi (20/Jan/13 10:56 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-13678) Maven test failures hide more important errors
kutzi commented on JENKINS-13678 Maven test failures hide more important errors Do you have any test project to reproduce this 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-13678) Maven test failures hide more important errors
kutzi assigned JENKINS-13678 to kutzi Maven test failures hide more important errors Change By: kutzi (20/Jan/13 11:01 AM) Assignee: KohsukeKawaguchi kutzi 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-13678) Maven test failures hide more important errors
kutzi updated JENKINS-13678 Maven test failures hide more important errors Change By: kutzi (20/Jan/13 11:02 AM) Due Date: 17/Feb/13 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-5130) NPE during Surefire execution of a Maven project without any tests
kutzi commented on JENKINS-5130 NPE during Surefire execution of a Maven project without any tests Can you reproduce this with a recent Jenkins version? 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-5130) NPE during Surefire execution of a Maven project without any tests
kutzi assigned JENKINS-5130 to kutzi NPE during Surefire execution of a Maven project without any tests Change By: kutzi (20/Jan/13 11:03 AM) Assignee: kutzi 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-15274) Build fails if there are test failures during Invoke top-level Maven targets build step
kutzi resolved JENKINS-15274 as Not A Defect Build fails if there are test failures during Invoke top-level Maven targets build step Use -Dmaven.test.failure.ignore=true This is not an issue, but a question. Please post such things to the users list. Thanks Change By: kutzi (20/Jan/13 11:06 AM) 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-3954) OutOfMemoryError on Maven site on SECOND build
kutzi updated JENKINS-3954 OutOfMemoryError on Maven site on SECOND build Change By: kutzi (20/Jan/13 11:08 AM) Due Date: 31/Mar/13 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-11721) MavenTestDataPublisher does not work with modules and after restart
kutzi updated JENKINS-11721 MavenTestDataPublisher does not work with modules and after restart Change By: kutzi (20/Jan/13 11:10 AM) Due Date: 31/Mar/13 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-11721) MavenTestDataPublisher does not work with modules and after restart
kutzi assigned JENKINS-11721 to kutzi MavenTestDataPublisher does not work with modules and after restart Change By: kutzi (20/Jan/13 11:10 AM) Assignee: kutzi 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-11721) MavenTestDataPublisher does not work with modules and after restart
kutzi commented on JENKINS-11721 MavenTestDataPublisher does not work with modules and after restart If these are 2 different problems, please post 2 JIRA issues. Do you have a test project to reproduce the problems? 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-15865) Jenkins build fails with fatal error for Maven 2 build of project with maven-failsafe-plugin
kutzi resolved JENKINS-15865 as Fixed Jenkins build fails with fatal error for Maven 2 build of project with maven-failsafe-plugin Change By: kutzi (20/Jan/13 11:14 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-15167) Parsing pom.xml failed due to '\t' character inside pom.xml
kutzi resolved JENKINS-15167 as Incomplete Parsing pom.xml failed due to \t character inside pom.xml No feedback from reporter Change By: kutzi (20/Jan/13 3:57 PM) Status: Open Resolved Resolution: Incomplete 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-15066) Long wait between last build step and first post build step
kutzi updated JENKINS-15066 Long wait between last build step and first post build step Change By: kutzi (20/Jan/13 3:59 PM) Component/s: core 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-10234) Junit result archiver getting stuck for a long time in concurrent builds
kutzi commented on JENKINS-10234 Junit result archiver getting stuck for a long time in concurrent builds IMO this is definitely a feature and not a bug. If you don't like this behaviour, then use e.g. the xunit plugin which doesn't seem to behave in this way. 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-9913) Concurrent builds getting batched/nodes not getting released when jobs are completed
kutzi commented on JENKINS-9913 Concurrent builds getting batched/nodes not getting released when jobs are completed Sergey, do you mean 'artifact archiving' or 'JUnit result archiving'. In the former case, you would be probably right, but I've seen no comment here that artifact archiving is blocking, too. In the case of JUnit: yes it MUST block to calculate the diff (regressions et.al.) to the previous test results. So it is a feature. 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-9913) Concurrent builds getting batched/nodes not getting released when jobs are completed
kutzi commented on JENKINS-9913 Concurrent builds getting batched/nodes not getting released when jobs are completed For that you can e.g. use the xunit plugin as mentioned in JENKINS-10234. Generally, don't use any build steps which require blocking behaviour. Yes, very unfortunately it's not visible for end users which build steps do and which don't. 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-15440) Emailing users at the end of a failed build very slow for big Jenkins instance using subversion
kutzi commented on JENKINS-15440 Emailing users at the end of a failed build very slow for big Jenkins instance using subversion Sounds great. I'll push a svn-plugin release today or tomorrow. 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-16427) Job build freezes during access to svn repository
kutzi commented on JENKINS-16427 Job build freezes during access to svn repository I don't know. Depending on how you start your job. 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-10100) Replace build-in test graphs with the TestNG ones
kutzi commented on JENKINS-10100 Replace build-in test graphs with the TestNG ones To be honest, I don't remember if I posted this question to the dev-list at all. And if I did, I think I didn't get any answer. The answer would probably be a new @Extension point in Jenkins core. 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-777) The need for Subversion command line options.
kutzi commented on JENKINS-777 The need for Subversion command line options. I just did the release. Should be available in the update center soon. 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-16383) add option for SSL connection instead of SASL
kutzi commented on JENKINS-16383 add option for SSL connection instead of SASL Now I'm curious: what was the 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-16479) SVN Check Out Hung
kutzi commented on JENKINS-16479 SVN Check Out Hung See http://stackoverflow.com/questions/224756/java-application-hang-on-linux-at-java-io-unixfilesystem-getbooleanattributes0 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-9450) Addition of package-level maven-metadata.xml
kutzi updated JENKINS-9450 Addition of package-level maven-metadata.xml Change By: kutzi (25/Jan/13 10:56 AM) Summary: Additionof package-level maven-metadata.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-15961) Add ignore Push notification option
kutzi commented on JENKINS-15961 Add ignore Push notification option See JENKINS-6846 for the core-side fix. So this still needs to be implemented on the git side. 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-14585) Test Failure Claim Link not present for Maven test results
kutzi edited a comment on JENKINS-14585 Test Failure Claim Link not present for Maven test results Seems like have to configure this differently for Maven builds: Post build actions - Additional test report features Did you do that? 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-16368) Hardcoded protocol in some links
kutzi commented on JENKINS-16368 Hardcoded protocol in some links Actually, I was thinking about network-path reference as this bug - as I understand it - is that in some places Jenkins#getRootUrl() is used to construct intra-Jenkins links. Indeed, using absolute URIs in this case would be the even better solution. I find it quite strange that the value of getRootUrl doesn't always return the same - configured - value, but based on the 'current' protocol something different. But that was already so before this fix, so it doesn't actually worsen the situation. 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-16368) Hardcoded protocol in some links
kutzi edited a comment on JENKINS-16368 Hardcoded protocol in some links Actually, I was thinking about network-path reference as this bug - as I understand it - is that in some places Jenkins#getRootUrl() is used to construct intra-Jenkins links. Indeed, using absolute URIs in this case would be the even better solution. I find it quite strange that the value of getRootUrl doesn't always return the same - configured - value, but based on the 'current' request something different. But that was already so before this fix, so it doesn't actually worsen the situation. 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, send email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-16368) Hardcoded protocol in some links
kutzi commented on JENKINS-16368 Hardcoded protocol in some links Looking at it again, it actually does worsen the situation, as previously I was either getting the configured value or getRootUrlFromRequest() - which is also (kind of) mentioned in the Javadoc. Now I have 3 different return values, based on the context. 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-16368) Hardcoded protocol in some links
kutzi edited a comment on JENKINS-16368 Hardcoded protocol in some links We could have a new method in Jenkins which returns the rootUrl without protocol, so ModelHyperlinkNote could use absolute URIs, like you mentioned. Or am I misunderstanding the issue? Forget it. I think you already answered this with the proxy example. 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, send email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-16368) Hardcoded protocol in some links
kutzi commented on JENKINS-16368 Hardcoded protocol in some links Agree that this seems like a workaround. Moreover the fix doesn't seem to be complete as HTTPS might terminate in the reverse proxy, so Stapler.getCurrentRequest().getScheme() would return 'http' So the only 'correct' way to operate Jenkins under https seems to simply configure the rootUrl to start with https. Otherwise it's IMO simply a configuration 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 -- 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-16368) Hardcoded protocol in some links
kutzi commented on JENKINS-16368 Hardcoded protocol in some links I'd argue that the root URL must always be configured correctly. There's already a big warning on the global config page if you don't. Maybe we can still improve the documentation a bit to make the situation clearer for users. And then I'd close this a not-a-bug. 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, send email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-16518) Warning summary gone after plugin update
kutzi created JENKINS-16518 Warning summary gone after plugin update Issue Type: Bug Assignee: Ulli Hafner Components: analysis-core, checkstyle, findbugs, maven2 Created: 29/Jan/13 11:03 AM Description: we've recently updated our Checkstyle and FindBugs plugin (and also static analysis core) to the latest version and since then we've mentioned that the warning summary on the build overview page of Maven jobs has gone. Environment: Jenkins 1.480.2, analysis-core 1.48, findbugs 4.45, checkstyle 3.32 Project: Jenkins Priority: Major Reporter: kutzi 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-16533) Jobs checked out from svn with pinned externals continuously run (with no changes in svn)
kutzi commented on JENKINS-16533 Jobs checked out from svn with pinned externals continuously run (with no changes in svn) I wonder why the unit test created for JENKINS-6209 does not fail, when there's a regression 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-16368) Hardcoded protocol in some links
kutzi commented on JENKINS-16368 Hardcoded protocol in some links @vjuranek: I'm sure that might break some things - like when you try to use the root url in e-mails. Network-path references will only work in the context of a current request - AFAIK BTW: I didn't really propose to use this for the root URL. I just pointed out that this might be a solution in some way. 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] [jabber] (JENKINS-25143) 'no such file or directory' error while saving configure page
kutzi resolved JENKINS-25143 as Fixed no such file or directory error while saving configure page I believe this is already fixed with https://github.com/jenkinsci/jabber-plugin/commit/b031d80df626b30530c6dd88cf1f426614b2 (not released, yet) Change By: kutzi (14/Oct/14 7:05 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/d/optout.
[JIRA] [jabber] (JENKINS-25143) 'no such file or directory' error while saving configure page
kutzi commented on JENKINS-25143 no such file or directory error while saving configure page Released now in v1.26 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/d/optout.
[JIRA] [jabber] (JENKINS-25222) Jenkins does not stay in chatrooms after 1.26 upgrade
kutzi commented on JENKINS-25222 Jenkins does not stay in chatrooms after 1.26 upgrade No it's not in 1.27. I'll release 1.28 within the next couple of days 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/d/optout.
[JIRA] [jabber] (JENKINS-25222) Jenkins does not stay in chatrooms after 1.26 upgrade
kutzi resolved JENKINS-25222 as Fixed Jenkins does not stay in chatrooms after 1.26 upgrade Change By: kutzi (28/Oct/14 9:19 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/d/optout.
[JIRA] [ircbot] (JENKINS-25349) Leaking ircbot OutputThreads
kutzi commented on JENKINS-25349 Leaking ircbot OutputThreads Could you attach the full stack dump, please? 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/d/optout.
[JIRA] [ircbot-plugin] (JENKINS-25349) Leaking ircbot OutputThreads
kutzi commented on JENKINS-25349 Leaking ircbot OutputThreads I think I have a fix for this. Would you like to test https://dl.dropboxusercontent.com/u/25863594/ircbot.hpi ? 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/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-21216) Add support for Folder job type
kutzi commented on JENKINS-21216 Add support for Folder job type Has this actually been implemented? The PR hasn't been merged, yet, and in the documentation I can only find that it's supported to create jobs in existing folders, but nothing on top of that. 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/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-21216) Add support for Folder job type
kutzi commented on JENKINS-21216 Add support for Folder job type Oh, sorry for the noise. I was only looking at https://github.com/jenkinsci/job-dsl-plugin/wiki/Job-reference and https://github.com/jenkinsci/job-dsl-plugin/wiki/View-Reference, since they promise to have "all options" I guess the original PR https://github.com/jenkinsci/job-dsl-plugin/pull/120 can then be closed, too? 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/d/optout.
[JIRA] [jabber-plugin] (JENKINS-25505) After Upgrade jenkins to 1.587 cannot send message with jabber
kutzi commented on JENKINS-25505 After Upgrade jenkins to 1.587 cannot send message with jabber I'd suspect that the DNS SRV setup for your XMPP server might not be correct. Check e.g. http://blog.teemu.im/2008/12/14/setting-your-srv-records-straight-for-xmpp/ Have you ruled out that nothing else in the infrastructure has changed? Can you connect with a different XMPP client from the Jenkins host? 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/d/optout.
[JIRA] [jabber-plugin] (JENKINS-25515) Jabber can not send message
kutzi commented on JENKINS-25515 Jabber can not send message This looks like a bug in the Smack library parsing VCards, which is also reported elsewhere: http://stackoverflow.com/questions/26752285/android-asmack-vcard-classcastexception-while-calling-vcard-loadconn I added a workaround to just ignore the error, so that the connection works at least. Would you be willing to test it? https://dl.dropboxusercontent.com/u/25863594/jabber.hpi 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/d/optout.
[JIRA] [jabber-plugin] (JENKINS-12097) Using Jabber Plugin with Google Talk logs VCARD Exception
kutzi updated JENKINS-12097 Using Jabber Plugin with Google Talk logs VCARD Exception Change By: kutzi (10/Nov/14 6:42 PM) Summary: TryingtoUse Using JabberPlugin for with GoogleTalk Throws logs VCARDException 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/d/optout.
[JIRA] [jabber-plugin] (JENKINS-25505) After Upgrade jenkins to 1.587 cannot send message with jabber
kutzi commented on JENKINS-25505 After Upgrade jenkins to 1.587 cannot send message with jabber Also possible that Smack API 4.x broke something which was working previously... Does maybe your Jabber server use the older _jabber._tcp. name? This seems to be broken in Smack 4.x. See https://github.com/igniterealtime/Smack/commit/2eb13f48d2a72af9f0e88c5b2d8a9881a655fa1b#commitcomment-8506196 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/d/optout.
