[JIRA] (JENKINS-56065) Change handling of symlinks when scanning for files in warnings-ng-plugin
Title: Message Title Michael Barker commented on JENKINS-56065 Re: Change handling of symlinks when scanning for files in warnings-ng-plugin I've create a pull request that implements this (include checkbox configuration): https://github.com/jenkinsci/warnings-ng-plugin/pull/11 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-56065) Change handling of symlinks when scanning for files in warnings-ng-plugin
Title: Message Title Michael Barker commented on JENKINS-56065 Re: Change handling of symlinks when scanning for files in warnings-ng-plugin I think Job makes the most sense as it is the same place where the fileset is defined. 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-56065) Change handling of symlinks when scanning for files in warnings-ng-plugin
Title: Message Title Michael Barker updated an issue Jenkins / JENKINS-56065 Change handling of symlinks when scanning for files in warnings-ng-plugin Change By: Michael Barker In our environment the build tool creates a number of symlinks to parent directories creating recursive directory structures. This play's havoc with Ant's DirectoryScanner used by the FileFinder in the warnings-ng-plugin. The default protections in DirectoryScanner (limit to traversing 5 levels of symlinks) aren't sufficient, given the number of files in our output directory, to prevent the jenkins agent from running out of memory. Preventing symlink traversal altogether (see patch) fixes the problem.However I suspect this may break some users, would it be possible to have a configuration option next to the fileset pattern to be scanned to include a checkbox to disable traversing symlinks.We've already tried moving the appropriate files to a different directory structure, but the FindBugs/SpotBugs file searching will search for the originating Java files after getting the main analysis records, which causes to break as well (uses the same FileFinder). 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,
[JIRA] (JENKINS-56065) Change handling of symlinks when scanning for files in warnings-ng-plugin
Title: Message Title Michael Barker updated an issue Jenkins / JENKINS-56065 Change handling of symlinks when scanning for files in warnings-ng-plugin Change By: Michael Barker Attachment: dont-use-symlinks.patch 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-56065) Change handling of symlinks when scanning for files in warnings-ng-plugin
Title: Message Title Michael Barker updated an issue Jenkins / JENKINS-56065 Change handling of symlinks when scanning for files in warnings-ng-plugin Change By: Michael Barker Attachment: dont-use-symlinks.patch 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-56065) Change handling of symlinks when scanning for files in warnings-ng-plugin
Title: Message Title Michael Barker created an issue Jenkins / JENKINS-56065 Change handling of symlinks when scanning for files in warnings-ng-plugin Issue Type: Improvement Assignee: Ulli Hafner Attachments: dont-use-symlinks.patch Components: warnings-ng-plugin Created: 2019-02-08 23:44 Priority: Minor Reporter: Michael Barker In our environment the build tool creates a number of symlinks to parent directories creating recursive directory structures. This play's havoc with Ant's DirectoryScanner used by the FileFinder in the warnings-ng-plugin. The default protections in DirectoryScanner (limit to traversing 5 levels of symlinks) aren't sufficient, given the number of files in our output directory, to prevent the jenkins agent from running out of memory. Preventing symlink traversal altogether (see patch) fixes the problem. However I suspect this may break some users, would it be possible to have a configuration option next to the fileset pattern to be scanned to include a checkbox to disable traversing symlinks. We've already moving the appropriate files to a different directory structure, but the FindBugs/SpotBugs file searching will search for the originating Java files after getting the main analysis records, which causes to break as well (uses the same FileFinder).
[JIRA] (JENKINS-40999) Recursive symlink causes high resource utilization, termination of slave process in ArchiveArtifact and Publish JUnit results steps.
Title: Message Title Michael Barker commented on JENKINS-40999 Re: Recursive symlink causes high resource utilization, termination of slave process in ArchiveArtifact and Publish JUnit results steps. This issue is also affecting us. Our build tool (Buck) creates symlinks that create loops within the directory structure. I think a general fix for infinitely recursing issue would be to track the canonical path current being traversed and stop if it is revisited. If I were to get this patched in Ant, would updating the ant version for Jenkins fix this for all of the plugins that use FileSet based scanning (TAP Results, Checkstyle, etc.)? What version of Ant does Jenkins need to use. I see that it is currently on 1.9.2. Does it need to stay on the 1.9.x line? 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-31155) Workflow shared library improvements
Title: Message Title Mike Key commented on JENKINS-31155 Re: Workflow shared library improvements +1 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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] [mercurial] (JENKINS-11102) Give the possibility to monitor all branches as Git plugin
Mike Wilson commented on JENKINS-11102 Give the possibility to monitor all branches as Git plugin Yes, since my last round looking at this topic I have also switched to the one-job-per-branch camp. This is what is most natural considering job status - different branches may have very little to do with each other and their statuses shouldn't be mixed up. But the topic in this ticket is still very relevant and might be appropriate to address in the generic Jenkins code. Either an offical new "super job" entity that can control automatic creation of other jobs, or some simple "clone this job for all branches" setting on ordinary jobs. Then SCM plugins would be required to report the active branches, which could be done at the same time as checking for new checkins. 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-10558) Jenkins mercurial plugin - add support for bookmarks
Mike Wilson commented on JENKINS-10558 Jenkins mercurial plugin - add support for bookmarks Great, thanks. I can clearly see uses both for branches that keep their names forever (for documentation reasons), and for ones that drop their names once finished. I guess bookmarks could be used for both (just don't delete the names you want to keep?) but named branches are probably better for the former as they also have the active/closed status to aid you in finding relevant branches? So this would boil down to that support for auto-building both all branches and all bookmarks would be valuable [now voting for both this ticket and JENKINS-11102] 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-10558) Jenkins mercurial plugin - add support for bookmarks
Mike Wilson commented on JENKINS-10558 Jenkins mercurial plugin - add support for bookmarks This sounds interesting, but I wonder about bookmarks vs branches. You mention that some users prefer bookmarks as branches stay around forever. Do you see the problem with persistent branch names as something causing performance problems (too many branch names building up over time) or more of supporting some users' personal preferences of how to use Mercurial? 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-11102) Give the possibility to monitor all branches as Git plugin
Mike Wilson commented on JENKINS-11102 Give the possibility to monitor all branches as Git plugin This feature would be a very big win where I work too. We want to switch to topic/feature branches and being able to configure the repository once and then have it run dynamically for all branches would be a big win. I understand jglick's argument though, about the job status. How does the Git plugin deal with this, and have they established an "acceptable" compromise? 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
