[JIRA] (JENKINS-45094) Memory usage on dashboard, activity pages after browser is open a long time
Title: Message Title Henrik Skupin commented on JENKINS-45094 Re: Memory usage on dashboard, activity pages after browser is open a long time Phillip Whoriskey, if you could install a recent Nightly build of Firefox 72.0 and install the profiler addon from https://profiler.firefox.com/, you could create a profile which might help to figure out where the leak actually is happening. See the documentation in how to create and upload a profile: https://profiler.firefox.com/docs/#/ Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.183187.1498178724000.9598.1572990060224%40Atlassian.JIRA.
[JIRA] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin edited a comment on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Ok, so here an update. If that patch sticks and will not be backed out again, we will land the Firefox patch for Firefox 69 on May 14th or 15th. Which means it will ride the trains through beta, and will be finally be released on Sep 3rd. If by that time there are still users who running a Jenkins LTS release earlier than 2.164.3, they will have to use Firefox 68 ESR. That ESR version will be maintained for another year, and will never have this patch included. Details see [https://bugzilla.mozilla.org/show_bug.cgi?id=1370630#c41] and following. Thanks a lot again for the patch! It will unblock us from landing several features which are all blocked by this particular issue. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Ok, so here an update. If that patch sticks and will not be backed out again, we will land the Firefox patch for Firefox 69 on May 14th or 15th. Which means it will ride the trains through beta, and will be finally be released on Sep 3rd. If by that time there are still users who running a Jenkins LTS release earlier than 2.164.3, they will have to use Firefox 68 ESR. That ESR version will be maintained for another year, and will never have this patch included. Details see https://bugzilla.mozilla.org/show_bug.cgi?id=1370630#c41 and following. Thanks a lot again for the patch! It will unblock us from landing several features which are all blocked by this particular issue. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Daniel Beck thank you for bringing this up. It's actually not my job to make such a decision, so I will leave it up to the release managers to decide. I will clearly reference your last comment, so that they are aware of the situation for Jenkins users. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox I assume you mean 2019-05-08. We can post-pone for sure. It's not that this patch is critical, and we already waited a while for it. Do you have some stats in how long it takes for the majority of users to upgrade to the next LTS release? Will it be one week, or two? Also note that the fix will land on mozilla-central only, which means it will only be part of a nightly build. Those people are tech-aware and should upgrade their instances fast enough. Our next merge to beta is on 2019-05-13, so I would suggest to at least wait until 2019-05-14 before landing that change in Firefox Nightly (69). Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Great to be helpful. And that sounds fantastic. So we now have to wait for the 2.174 and an upcoming LTS before we can make that change live in Firefox. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Oliver Gondža, a normal nightly build of Firefox won't work given that it hasn't the patch from bug 1370630 included. You can pick a build from https://treeherder.mozilla.org/#/jobs?repo=try=3f12e17b558a36ef5b65235d663c4e617c3d328e=build by just clicking the `B` symbol of your platform, selecting Job Details in the lower pane, and then `target.zip`, `target.dmg`, or `target.tar.bz2`. Just extract the archive and run the binary. With such a build you should be able to see the failure without the patch in Jenkins. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox I won't have the time for testing it, but I requested a new Firefox build with the patch on https://bugzilla.mozilla.org/show_bug.cgi?id=1370630 applied. Currently the patch doesn't apply anymore. Once we have a build I will happily post a link to it. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Thanks Daniel Beck! These are great news. I cannot await to see this being shipped with that release, and for a LTS later. Is there a place I can watch in which LTS release it will be included if stable? Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Thank you for the update Daniel! I also asked on https://bugzilla.mozilla.org/show_bug.cgi?id=1399783 if someone could help testing it with Firefox. Hope the new proposed fix will be less regression-prone and will fix it. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Oh, I thought that this issue was about a custom behavior only used for Firefox; as stated in the issue summary. So the non-trusted `submit` event was used for all browsers then? Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox What I wonder is that the change here should have only affected Firefox, right? But people are filing issues for Chrome and IE. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Daniel Beck, I simply want to report back that one of our engineers who works a lot with Jenkins just checked the latest release of Jenkins and it indeed seems to work all fine. Having it in the next LTS release would be fantastic! Thanks! Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox That's great to hear that you are considering it for a LTS release even it's not the upcoming one. Thanks a lot! Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Wonderful. In that case I assume you want to finish up the patch now? Is there something else you would need help with? My remaining question would be if we could also get this into a LTS release once it landed on master. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Thorsten Scherler, I assume that without your patch saving the settings doesn't work? Also AFAIR it was mentioned that all submit buttons throughout Jenkins are affected by that. They all work that way now? If yes, that sounds great. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Here the direct links to the builds: https://archive.mozilla.org/pub/firefox/nightly/2017/07/2017-07-07-10-01-38-mozilla-central/firefox-56.0a1.en-US.linux-i686.tar.bz2 https://archive.mozilla.org/pub/firefox/nightly/2017/07/2017-07-07-10-01-38-mozilla-central/firefox-56.0a1.en-US.linux-x86_64.tar.bz2 If you have another platform than Linux please let me know and I have to find the Windows and MacOS builds. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Thanks Daniel Beck. Sadly I don't have a chance to run such a Jenkins build locally and verify all the different occurrences of this problem. You and Thorsten Scherler should have the better overview of what to test. Therefore you wouldn't have to build Firefox with the patch but as I mentioned above just pick one of the older Firefox Nightly builds for your platform. The one which had this patch included can be found at https://archive.mozilla.org/pub/firefox/nightly/2017/07/2017-07-07-10-01-38-mozilla-central/. Let me know if that works for you. Thanks in advance! Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Regarding the bad news, about how many different submit buttons we are talking here? Is it something which could easily be fixed and shipped, or how long would it take? So far Jenkins seems to be the only site which blocks us from shipping this feature fix, and we really would like to get this out to our users for a better web platform conformance. Thanks. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox Ok, so I checked with such a Nightly build and switched the user agent to Chrome. That actually fixed it, yes. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53462) Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox
Title: Message Title Henrik Skupin commented on JENKINS-53462 Re: Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox We had to backout the patch due to the regression with Jenkins. As such it was only available in some Nightly builds of Firefox during the 56 development process. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] [envinject-plugin] (JENKINS-29056) Global environment variables set via properties file are not forwarded to slaves other than master
Title: Message Title Henrik Skupin created an issue Jenkins / JENKINS-29056 Global environment variables set via properties file are not forwarded to slaves other than master Issue Type: Bug Assignee: Gregory Boissinot Components: envinject-plugin Created: 24/Jun/15 11:16 AM Environment: Jenkins LTS 1.580.1 with EnvInject plugin 1.88 Labels: slave environment-variables Priority: Major Reporter: Henrik Skupin There are two ways to specify global environment variables. You can set them directly as name/value pair in the global settings, or let them import from a properties file. If you need those variables in jobs run on slave nodes, you will notice that only those hard-coded variables are present. The loaded variables will not be available. Those are only available if the job is getting run on the master. The workaround for now would be to load this properties file by specifying a build step in that job.
[JIRA] [xshell-plugin] (JENKINS-25600) XShell does not kill running process if job is getting aborted
Henrik Skupin commented on JENKINS-25600 XShell does not kill running process if job is getting aborted Ok, I was able to get XShell built on my own and I checked a build before and after the above landed PR. As I'm able to see the broken behavior as reported here is really caused by your patch from PR #8. 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] [core] (JENKINS-25490) Slave JLNP client stops working with Unable to launch the application when master is stopped
Henrik Skupin commented on JENKINS-25490 Slave JLNP client stops working with Unable to launch the application when master is stopped So I already tried the way via the terminal by connecting the slave via javaws, but the client dies the same way when the master gets shutdown. So this is not a workaround. And this only happens on Linux and OS X. I re-tested with Windows and I cannot observe this behavior. There the client re-connects successfully once the master is back online. I'm not that happy with the 'java' workaround given that it would require us to update all of our 70 machines, by downloading the slave.jar file first. Also not sure how often it was required to re-download it given updates to that file. I'm working on a puppet configuration for us but that is not ready yet. 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] [core] (JENKINS-25490) Slave JLNP client stops working with Unable to launch the application when master is stopped
Henrik Skupin commented on JENKINS-25490 Slave JLNP client stops working with Unable to launch the application when master is stopped So I also tried to install jenkins as service via the JNLP connection window, but that failed on OS X. So it looks like we really have to use the 'java' command for now on both affected platforms. 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] [xshell-plugin] (JENKINS-25600) XShell does not kill running process if job is getting aborted
Henrik Skupin created JENKINS-25600 XShell does not kill running process if job is getting aborted Issue Type: Bug Assignee: Unassigned Components: xshell-plugin Created: 13/Nov/14 4:42 PM Description: As we have seen lately XShell is not able to kill a running process once it is running on the slave, and the user aborts the job on the master machine. Current result is that the job is marked as aborted on the master, but it is still running on the client. This totally breaks our testruns because Jenkins thinks the node is free again, and schedules the next job for this node. But given that by our definition only a single job can run on a node, it will fail. The Jenkins log shows the following when aborting a job: mozilla-aurora_update #2 aborted java.lang.InterruptedException: sleep interrupted at java.lang.Thread.sleep(Native Method) at hudson.plugins.xshell.XShellBuilder.perform(XShellBuilder.java:158) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:585) at hudson.model.Run.execute(Run.java:1684) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Environment: Jenkins 1.580.1 with XShell 0.9 Project: Jenkins Priority: Critical Reporter: Henrik Skupin 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] [xshell-plugin] (JENKINS-25600) XShell does not kill running process if job is getting aborted
Henrik Skupin commented on JENKINS-25600 XShell does not kill running process if job is getting aborted Could this have been caused by https://github.com/jenkinsci/xshell-plugin/pull/8? 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] [xshell-plugin] (JENKINS-25600) XShell does not kill running process if job is getting aborted
Henrik Skupin commented on JENKINS-25600 XShell does not kill running process if job is getting aborted Oh, and this is indeed a regression between version 0.8 and 0.9. 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] [xshell-plugin] (JENKINS-25600) XShell does not kill running process if job is getting aborted
Henrik Skupin commented on JENKINS-25600 XShell does not kill running process if job is getting aborted That's correct. Via the red button as visible in the console output in the top right, or in the node list in the dashboard. 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] [core] (JENKINS-25582) Installing Jenkins service the slave cannot re-connect after first system restart
Henrik Skupin created JENKINS-25582 Installing Jenkins service the slave cannot re-connect after first system restart Issue Type: Bug Assignee: Unassigned Components: core Created: 12/Nov/14 11:01 PM Description: I tried to use the Windows Service, which can be installed via a JLNP connection, to let the slave nodes automatically connect to the master. The installation seems to have a problem with shutting down the initial connection to master. So after a system restart of the slave it is no longer able to re-connect to the master because the slave is still marked as connected. It looks like that when the initial JLNP connection was killed the slave has not properly disconnected itself. Further restarts do not show this behavior. As of now you are forced to restart Jenkins on the master machine to let the client connect again. Steps: 1. Setup Jenkins and a slave node via Java Web Start 2. Connect a Windows slave 3. Select 'File | Install as a service' 4. Wait for the service to be installed 5. Restart the slave Once the slave has been restarted, the service will try to re-connect to the master, but the connection is not allowed: Nov 12, 2014 11:11:05 PM hudson.TcpSlaveAgentListener$ConnectionHandler run INFO: Accepted connection #618 from /192.168.123.3:60703 Nov 12, 2014 11:11:05 PM jenkins.slaves.JnlpSlaveHandshake error WARNING: TCP slave agent connection handler #618 with /192.168.123.3:60703 is aborted: dummy-windows is already connected to this master. Rejecting this connection. Nov 12, 2014 11:11:05 PM jenkins.slaves.JnlpSlaveHandshake error WARNING: TCP slave agent connection handler #618 with /192.168.123.3:60703 is aborted: Unrecognized name: dummy-windows I see hundreds of those messages in a really quick sequence. Environment: Jenkins master (1.580.1) on Ubuntu 14.04 and Jenkins slave on Windows 7 64bit. Project: Jenkins Priority: Critical Reporter: Henrik Skupin 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] [core] (JENKINS-25490) Slave JLNP client stops working with Unable to launch the application when master is stopped
Henrik Skupin commented on JENKINS-25490 Slave JLNP client stops working with Unable to launch the application when master is stopped But isn't that the headless mode? The tests we are running require a GUI. That's why we used the JLNP method so far. Would that not be necessary? Means we could write our own little daemon (script) to ensure that slave.jar is the current version and (re-)starts the slave if it is not running? I tested it with the `java` command and it works at least on Ubuntu. I will also have to test on Windows, but would like to know more about my above question first. 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 -- 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] [core] (JENKINS-25490) Slave JLNP client stops working with Unable to launch the application when master is stopped
Henrik Skupin commented on JENKINS-25490 Slave JLNP client stops working with Unable to launch the application when master is stopped That is correct, yes. We don't have it running as service via upstart. 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] [core] (JENKINS-25490) Slave JLNP client stops working with Unable to launch the application when master is stopped
Henrik Skupin created JENKINS-25490 Slave JLNP client stops working with Unable to launch the application when master is stopped Issue Type: Bug Assignee: Unassigned Components: core Created: 07/Nov/14 1:27 PM Description: Since the former major LTS release I experience a kinda problematic problem with our Jenkins instance. Whenever the master is stopped (shutdown) with active connections to slaves, the JLNP client on the slaves stops working with the message: "Unable to launch the application". This was not the case before, so the client application was still running and reconnected once the master was back online. With the current behavior I have to step through all the 60 slave nodes, and start the JLNP client manually. Steps: 1. Download Jenkins 1.580.1 and run it 2. Setup a dumb slave via Java Web Start 3. Connect the slave via the same machine 4. Stop the master After step 4 the JLNP client should stay open, waiting for the master being online again. But it fails with the above message and the following stack: Exception: CouldNotLoadArgumentException[ Could not load file/URL specified: /tmp/javawJ3YZLo] at com.sun.javaws.Main.launchApp(Unknown Source) at com.sun.javaws.Main.continueInSecureThread(Unknown Source) at com.sun.javaws.Main.access$000(Unknown Source) at com.sun.javaws.Main$1.run(Unknown Source) at java.lang.Thread.run(Thread.java:744) Wrapped Exception: java.io.FileNotFoundException: /tmp/javawJ3YZLo (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:146) at java.io.FileInputStream.init(FileInputStream.java:101) at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source) at com.sun.javaws.Main.launchApp(Unknown Source) at com.sun.javaws.Main.continueInSecureThread(Unknown Source) at com.sun.javaws.Main.access$000(Unknown Source) at com.sun.javaws.Main$1.run(Unknown Source) at java.lang.Thread.run(Thread.java:744) Environment: Jenkins 1.580.1 on Ubuntu 14.04 with slaves connected via JLNP. Project: Jenkins Priority: Critical Reporter: Henrik Skupin 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] [core] (JENKINS-25490) Slave JLNP client stops working with Unable to launch the application when master is stopped
Henrik Skupin commented on JENKINS-25490 Slave JLNP client stops working with Unable to launch the application when master is stopped A quick regression check has been shown that this regression started between 1.554.3 and 1.565.1. 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] [core] (JENKINS-25490) Slave JLNP client stops working with Unable to launch the application when master is stopped
Henrik Skupin commented on JENKINS-25490 Slave JLNP client stops working with Unable to launch the application when master is stopped This is a regression in v1.559 (https://jenkins-ci.org/changelog#v1.559) and totally smells like an unwanted behavior caused by https://issues.jenkins-ci.org/browse/JENKINS-19055 May this only be a problem if the JLNP client it's not installed as a service? 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] [core] (JENKINS-25490) Slave JLNP client stops working with Unable to launch the application when master is stopped
Henrik Skupin commented on JENKINS-25490 Slave JLNP client stops working with Unable to launch the application when master is stopped May be a dupe of #24272? 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] [core] (JENKINS-24272) jnlp slaves fail to reconnect when master is restarted
Henrik Skupin commented on JENKINS-24272 jnlp slaves fail to reconnect when master is restarted What is left to do here? As long as this fix is not in a release or even the current 1.580.x LTS, is there a way to workaround it? We have around 70 slaves and having to re-connect them all manually is terrible. 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 -- 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] [clone-workspace-scm-plugin] (JENKINS-25376) Clonnig an archived workspace which is currently geting archived will fail
Henrik Skupin commented on JENKINS-25376 Clonnig an archived workspace which is currently geting archived will fail I want to add that the real problem might be that job B is trying to get the archive from job A, but A completed and replaced the last successful build. So Job B downloaded a part from the former archive and would continue with the new one. That results in a broken archive on the slave node for job B. Maybe this is not a clone workspace bug a Jenkins core bug? If jobs, which are dependent on another job, are running the dependent job might not finish but wait until no other job accesses its resources? 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] [junit-plugin] (JENKINS-10234) Junit result archiver getting stuck for a long time in concurrent builds
Henrik Skupin commented on JENKINS-10234 Junit result archiver getting stuck for a long time in concurrent builds There is version 1.565.3 LTS to be scheduled for Oct 1st. Not sure when fixes are taking into consideration for LTS releases. Anything else beside the keyword we could try to get it in? The next major version bump for LTS will happen end of Oct, where this might be 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] [junit] (JENKINS-10234) Junit result archiver getting stuck for a long time in concurrent builds
Henrik Skupin commented on JENKINS-10234 Junit result archiver getting stuck for a long time in concurrent builds Any change that we could get this backported to the 1.565.x LTS branch? It's one of the most annoying problems for our Jenkins production systems. 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] [mail-watcher] (JENKINS-20536) Allow use of environment variable for e-mail address
Henrik Skupin commented on JENKINS-20536 Allow use of environment variable for e-mail address Is there any chance this can be implemented? It's a hassle to have to change so many configuration files if the email changes. 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 -- 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] [email-ext] (JENKINS-20078) email-ext plugin takes a huge amount of time to send out final status emails (30min)
Henrik Skupin commented on JENKINS-20078 email-ext plugin takes a huge amount of time to send out final status emails (30min) I think the resolution of this issue should be fixed, and not 'not a defect'. 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] [core] (JENKINS-12028) A path argument for launching jenkins.war file causes an exception and recursively deletes all files from the current folder
Henrik Skupin commented on JENKINS-12028 A path argument for launching jenkins.war file causes an exception and recursively deletes all files from the current folder This seems to work fine with Jetty. I cannot reproduce it anymore with version 1.554.2. 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] [ansicolor] (JENKINS-23388) AnsiColor no longer shows colored output in version 0.4.0
Henrik Skupin updated JENKINS-23388 AnsiColor no longer shows colored output in version 0.4.0 Change By: Henrik Skupin (10/Jun/14 1:40 PM) Summary: AnsiColornolongershowscoloredoutput sinceupgradedfrom in version0. 3 4 . 1 0 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] [ansicolor] (JENKINS-23388) AnsiColor no longer shows colored output in version 0.4.0
Henrik Skupin commented on JENKINS-23388 AnsiColor no longer shows colored output in version 0.4.0 Just to add I tested this with Jenkins version 1.554.2. 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] [ansicolor] (JENKINS-23388) AnsiColor no longer shows colored output since upgraded from version 0.3.1
Henrik Skupin created JENKINS-23388 AnsiColor no longer shows colored output since upgraded from version 0.3.1 Issue Type: Bug Assignee: Unassigned Components: ansicolor Created: 10/Jun/14 1:39 PM Description: Today I tried to upgrade ansicolor from version 0.3.1 to version 0.4.0. When I checked our console output for the build jobs, the content is no longer colored. Downgrading to version 0.3.1 made it appear again. So there is somewhere a regression between 0.3.1 and 0.4: https://github.com/dblock/jenkins-ansicolor-plugin/blob/master/CHANGELOG.md#040 Here example output in the console, which is not colored anymore: [1;34mTEST-START [0m | restartTests/testAddons_enableDisableExtension/test3.js | setupModule Project: Jenkins Priority: Major Reporter: Henrik Skupin 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] [core] (JENKINS-20204) Latest release of Java 7 blocks the connection to slaves due to no permissions attribute in the JAR file
Henrik Skupin commented on JENKINS-20204 Latest release of Java 7 blocks the connection to slaves due to no permissions attribute in the JAR file Wonderful news Kohsuke! Will this be backported to the latest 1.532.x LTS 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 -- 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] [core] (JENKINS-20204) Latest release of Java 7 blocks the connection to slaves due to no permissions attribute in the JAR file
Henrik Skupin commented on JENKINS-20204 Latest release of Java 7 blocks the connection to slaves due to no permissions attribute in the JAR file I talked with Kohsuke during the FOSDEM about 2 weeks ago, and he mentioned to me that he will have a look at it. So hopefully we will have a fix soon for that problem. 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] [xshell] (JENKINS-20478) Some of the Environment Variables are not expanding properly
Henrik Skupin commented on JENKINS-20478 Some of the Environment Variables are not expanding properly I think the last comment might be a different issue because we only see this when the $DATE parameter is empty for the given 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 -- 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] [email-ext] (JENKINS-20595) Make use of JenkinsUrl instead of HudsonUrl
Henrik Skupin commented on JENKINS-20595 Make use of JenkinsUrl instead of HudsonUrl Thank you Alex for fixing this. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [git] (JENKINS-19994) Unable to delete workspace
Henrik Skupin commented on JENKINS-19994 Unable to delete workspace Our own specific instance of the failure I'm also tracking at https://github.com/mozilla/mozmill-ci/issues/358. If I read the stack attached over there correctly, the failure is not inside of the delete workspace plugin, but in core. So the delete workspace plugin and other tasks like rotate log can't get a handle for their operations because the file is locked. We will further investigate it the next 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/groups/opt_out.
[JIRA] [email-ext] (JENKINS-20595) Make use of JenkinsUrl instead of HudsonUrl
Henrik Skupin created JENKINS-20595 Make use of JenkinsUrl instead of HudsonUrl Issue Type: Bug Assignee: Alex Earl Components: email-ext Created: 14/Nov/13 9:15 PM Description: One of the new features in the 1.509 LTS releases is that the Jenkins URL is stored inside the jenkinsURL field of the new file called jenkins.model.JenkinsLocationConfiguration.xml. Email-ext as of now stores the URL as hudsonUrl in its own hudson.plugins.emailext.ExtendedEmailPublisher.xml. As discussed at https://github.com/mozilla/mozmill-ci/pull/346/files#r7320234 the extension should be updated. Environment: Jenkins LTS 1.509.2 or higher Project: Jenkins Priority: Major Reporter: Henrik Skupin 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] [git] (JENKINS-19994) Unable to delete workspace
Henrik Skupin commented on JENKINS-19994 Unable to delete workspace Yeah, it's a reboot but not in all cases. So we see this problem a lot after installing updates and rebooting those nodes. But also have the problem that it sporadically starts, as what I have seen on Saturday. But this might be related to a restart, given that this job was run the last time on Nov 2nd on this node. So we might not have observed the problem earlier. How often do you reboot your machines? To help with the investigation we will add some logging to the delete workspace plugin to hopefully get more information when this problem occurs. 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] [git] (JENKINS-19994) Unable to delete workspace
Henrik Skupin commented on JENKINS-19994 Unable to delete workspace In our case we are using Java Web Start to connect the individual slaves to the master. So closing the Jenkins window and calling javaws with the node URL again, made it work. So we are using the same technique here, and your problem description sounds reasonable. But what me still wonders is why those kind of things also happen when we restart a Windows node and reconnecting it to the master. Not sure if that might be a different issue or related here. 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] [git] (JENKINS-19994) Unable to delete workspace
Henrik Skupin commented on JENKINS-19994 Unable to delete workspace I have seen the same problem again an hour ago and used my time to further investigate it. By using the Process Explorer I have seen that when for the file affected there is a sharing violation shown. That means another process still has an handle to that file open. Checking this file via the Explorer has shown that it has a file size of 0 Byte! The last access (modification) time was even 7 days old. Further research revealed that I could use handle (http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx) to show which processes have an handle open to that file. Doing that no other process except javaw.exe is shown. So some class in Jenkins itself seems to keep a handle open. I think that this can happen to any file within the workspace. I only don't know yet, what triggers the problem. I hope that when any of our jobs fail the next time, the previous job is still in history. That way I could compare times of the last file access and task run at this time. 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] [git] (JENKINS-19994) Unable to delete workspace
Henrik Skupin commented on JENKINS-19994 Unable to delete workspace Oh, and what I forgot. A simple reconnect of Jenkins on the slave was enough to free the handle. After the restart of the client deleting the workspace was working fine. 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] [clone-workspace] (JENKINS-6890) clone-workspace-scm doesn't work when source job is a matrix job.
Henrik Skupin commented on JENKINS-6890 clone-workspace-scm doesnt work when source job is a matrix job. I have asked on the pull request. Lets see if we can get some progress. It would be great to see this issue 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/groups/opt_out.
[JIRA] (JENKINS-14880) BUILD_ID doesn't contain hostname if config hasn't been saved after initial startup
Henrik Skupin commented on JENKINS-14880 BUILD_ID doesnt contain hostname if config hasnt been saved after initial startup Jenkins correctly auto-detects the hostname and port as I have mentioned in my initial comment. The problem is the value of the $BUILD_URL variable, which is empty. 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-16255) Jenkins doesn't handle system wide environment variables which exist in different cases
Henrik Skupin created JENKINS-16255 Jenkins doesnt handle system wide environment variables which exist in different cases Issue Type: Bug Affects Versions: current Assignee: Jørgen Tjernø Components: environment-script Created: 03/Jan/13 5:11 PM Description: If system-wide environment variables have been set via /etc/environment those are not accessible if they exist in lower-case and capital case letters. Jenkins combines both variables into a single one, and updates the first detected variable with the value of the second one. Here some examples: Example 1: /etc/environment http_proxy=http://proxy.dmz.example.org:8080 HTTP_PROXY=http://proxy.dmz.example.org:8080 - Jenkins: HTTP_PROXY=http://proxy.dmz.example.org:8080 Example 2: Shell: export test=1 export TEST=2 - Jenkins TEST=1 Jenkins should not modify set environment variables because it will cause problems with tools which rely on the right capitalization. One example is mercurial which needs the lower case version of the proxy configuration. It will no longer work when both variables are set. Environment: Ubuntu 12.04 x86 Project: Jenkins Priority: Major Reporter: Henrik Skupin 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-16255) Jenkins doesn't handle system wide environment variables which exist in different cases
Henrik Skupin updated JENKINS-16255 Jenkins doesnt handle system wide environment variables which exist in different cases Change By: Henrik Skupin (03/Jan/13 5:18 PM) Component/s: core Component/s: environment-script 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-16255) Jenkins doesn't handle system wide environment variables which exist in different cases
Henrik Skupin updated JENKINS-16255 Jenkins doesnt handle system wide environment variables which exist in different cases Change By: Henrik Skupin (03/Jan/13 5:19 PM) Assignee: JørgenTjernø 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-16255) Jenkins doesn't handle system wide environment variables which exist in different cases
Henrik Skupin commented on JENKINS-16255 Jenkins doesnt handle system wide environment variables which exist in different cases Oh and one more example: shell: export test=1 - Jenkins test=1 As you can see we keep the lower letters if no variable with the same name and capital letters exist. 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-13774) Provide option for cloning all branches with Mercurial SCM
Henrik Skupin commented on JENKINS-13774 Provide option for cloning all branches with Mercurial SCM jglick, Dave and myself are working on the same project. So I have just added more details to our problem. As I have mentioned we can't have multiple subdirectories (checkouts) of the repository because the build process has to be able to do a hotswap between branches. That means all named branches of the local clone have to be up-to-date. 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-11770) NodeLabelParameter shouldn't be incompatible with Rebuild
Henrik Skupin commented on JENKINS-11770 NodeLabelParameter shouldnt be incompatible with Rebuild Thanks domi. When will the new version be released? The updater of Jenkins can't find it yet. 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-11770) NodeLabelParameter shouldn't be incompatible with Rebuild
Henrik Skupin commented on JENKINS-11770 NodeLabelParameter shouldnt be incompatible with Rebuild The integrated plugin upgrade page of Jenkins shows version 1.14 now but it's still not listed on the plugin page itself: https://wiki.jenkins-ci.org/display/JENKINS/Rebuild+Plugin Anyway it works fine. Thanks a lot! 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-13243) Do not replace slashes in URLs with backslashes on Windows
[ https://issues.jenkins-ci.org/browse/JENKINS-13243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161413#comment-161413 ] Henrik Skupin commented on JENKINS-13243: - Code has been merged: https://github.com/jenkinsci/xshell-plugin/pull/2 Do not replace slashes in URLs with backslashes on Windows -- Key: JENKINS-13243 URL: https://issues.jenkins-ci.org/browse/JENKINS-13243 Project: Jenkins Issue Type: Bug Components: xshell Affects Versions: current Environment: Can be reproduced on any Windows platform Reporter: Henrik Skupin When you call a script which expects an URL as parameter, the slashes will also be converted to backslashes. It results in a broken parameter for the build. So on Windows the plugin should not convert parameters which contain URLs. -- 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-13267) Wrong working dir used on Windows if executed command is in a subfolder
[ https://issues.jenkins-ci.org/browse/JENKINS-13267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrik Skupin resolved JENKINS-13267. - Resolution: Not A Defect As it has been turned out it was really an issue on our side. Sorry for the false alarm. Wrong working dir used on Windows if executed command is in a subfolder --- Key: JENKINS-13267 URL: https://issues.jenkins-ci.org/browse/JENKINS-13267 Project: Jenkins Issue Type: Bug Components: xshell Affects Versions: current Environment: Any Windows platform Reporter: Henrik Skupin If a build step with XShell calls a command which is not in the current working dir but in a sub folder, the sub folder is used as current working dir. This issue only persists on Windows and cannot be seen on Linux or Mac. Just take a command (which is a wrapper script) like: scripts/run hg clone https://hg.mozilla.org/qa/mozmill-automation It should clone the given repository into the nodes working dir, but right now it will end up as 'scripts/mozmill-automation'. So the wrapper scripts working dir is used. Calling the wrapper script from outside Jenkins it works fine, so it has to be a XShell bug. As reference of a problematic job see: https://github.com/whimboo/mozmill-ci/blob/master/jenkins-master/jobs/functional-test/config.xml#L78 Steps to reproduce: 1. Clone https://github.com/whimboo/mozmill-ci/ 2. Follow the readme and setup the system 3. Add a node for Windows 4. Run 'Build Now' on the functional testrun (Branch: mozilla-central, Platform: win32, Locale: en-US, BuildId: 20120328115525, Nodes: win_xp, Env-Platform: Windows) 5. Check the working dir of the project and notice that the hg clone is not ending up in the root working dir There is also no difference with executeFromWorkingDir enabled or disabled. 5. -- 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-13244) Improve logic for shell script completion
[ https://issues.jenkins-ci.org/browse/JENKINS-13244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrik Skupin resolved JENKINS-13244. - Resolution: Not A Defect I think that we can close this one. It's working fine now on Windows even when the script has a .cmd extension. Also for Linux is safer to not have a .sh extension and simply use the basename. Improve logic for shell script completion - Key: JENKINS-13244 URL: https://issues.jenkins-ci.org/browse/JENKINS-13244 Project: Jenkins Issue Type: Bug Components: xshell Affects Versions: current Environment: This issue applies to all platforms Reporter: Henrik Skupin Currently you can specify a script to call by simply removing the extension and XShell will automatically add .cmd on Windows. Not sure why .sh is not getting added on Linux because it should be mostly the default extension for bash scripts. Also would it be possible to not only add the default extension but also check for alternatives? Batch files on Windows have a .cmd extension nowadays, and not sure what options exist on Linux. So would be great if the plugin could support multiple extensions, select the best match or fails when executing the shell if multiple matches exist which can't be resolved. -- 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-13267) Wrong working dir used on Windows if executed command is in a subfolder
[ https://issues.jenkins-ci.org/browse/JENKINS-13267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrik Skupin updated JENKINS-13267: Summary: Wrong working dir used on Windows if executed command is in a subfolder (was: Wrong workspace used on Windows if executed command is in a subfolder) Wrong working dir used on Windows if executed command is in a subfolder --- Key: JENKINS-13267 URL: https://issues.jenkins-ci.org/browse/JENKINS-13267 Project: Jenkins Issue Type: Bug Components: xshell Affects Versions: current Environment: Any Windows platform Reporter: Henrik Skupin If a build step with XShell calls a command which is not in the current working dir but in a sub folder, the sub folder is used as current working dir. This issue only persists on Windows and cannot be seen on Linux or Mac. Just take a command (which is a wrapper script) like: scripts/run hg clone https://hg.mozilla.org/qa/mozmill-automation It should clone the given repository into the nodes working dir, but right now it will end up as 'scripts/mozmill-automation'. So the wrapper scripts working dir is used. Calling the wrapper script from outside Jenkins it works fine, so it has to be a XShell bug. As reference of a problematic job see: https://github.com/whimboo/mozmill-ci/blob/master/jenkins-master/jobs/functional-test/config.xml#L78 Steps to reproduce: 1. Clone https://github.com/whimboo/mozmill-ci/ 2. Follow the readme and setup the system 3. Add a node for Windows 4. Run 'Build Now' on the functional testrun (Branch: mozilla-central, Platform: win32, Locale: en-US, BuildId: 20120328115525, Nodes: win_xp, Env-Platform: Windows) 5. Check the working dir of the project and notice that the hg clone is not ending up in the root working dir There is also no difference with executeFromWorkingDir enabled or disabled. 5. -- 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-13244) Improve logic for shell script completion
Henrik Skupin created JENKINS-13244: --- Summary: Improve logic for shell script completion Key: JENKINS-13244 URL: https://issues.jenkins-ci.org/browse/JENKINS-13244 Project: Jenkins Issue Type: Bug Components: xshell Affects Versions: current Environment: This issue applies to all platforms Reporter: Henrik Skupin Currently you can specify a script to call by simply removing the extension and XShell will automatically add .cmd on Windows. Not sure why .sh is not getting added on Linux because it should be mostly the default extension for bash scripts. Also would it be possible to not only add the default extension but also check for alternatives? Batch files on Windows have a .cmd extension nowadays, and not sure what options exist on Linux. So would be great if the plugin could support multiple extensions, select the best match or fails when executing the shell if multiple matches exist which can't be resolved. -- 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
