[JIRA] (JENKINS-50379) Jenkins kills long running sh script with no output
Title: Message Title Jacob Keller commented on JENKINS-50379 Re: Jenkins kills long running sh script with no output > The problem is not that your script stops producing output for a while. That is perfectly normal and supported. The problem is that a side process which is supposed to be detecting this fact and touching the log file every three seconds is either not running, or not producing the right timestamp as observed by the Jenkins agent JVM. Right, so it sounds like we need to investigate why the side process that should be touching the log file isn't working properly. 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.189432.1521834811000.848.1568144400672%40Atlassian.JIRA.
[JIRA] (JENKINS-56150) git plugin with repo that has empty .gitmodules file NPE during submodule update
Title: Message Title Jacob Keller created an issue Jenkins / JENKINS-56150 git plugin with repo that has empty .gitmodules file NPE during submodule update Issue Type: Bug Assignee: Mark Waite Components: git-client-plugin Created: 2019-02-14 23:44 Priority: Major Reporter: Jacob Keller If a git repository happens to have an empty .gitmodules file, then the git client plugin will assume that the repository has submodules. Then, when the submodule Update code is run, it will crash with what appeared to be a Null Pointer exception. (my jenkins instance is having other issues, which prevent me from extracting the exceptions stack trace at the moment, but once I have it, I will update the bug.). Add Comment
[JIRA] (JENKINS-55939) git-plugin v4.0.0-rc not returning "lastBuiltRevision" in BuildData
Title: Message Title Jacob Keller commented on JENKINS-55939 Re: git-plugin v4.0.0-rc not returning "lastBuiltRevision" in BuildData Hmm.. The buildDetails section should include the revision that was built by that build... we won't actually have exposed buildData anymore, because this was being duplicated and stored for every build kept... 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-19022) GIT Plugin (any version) heavily bloats memory use and size of build.xml with "BuildData" fields
Title: Message Title Jacob Keller commented on JENKINS-19022 Re: GIT Plugin (any version) heavily bloats memory use and size of build.xml with "BuildData" fields tzafrir, the gitlab plugin probably just needs to be updated to look for BuildDetails instead of BuildData. As for the rebuilding issue, that is likely due to the fact that the new plugin no longer maintains history of "I built this already" if the build which did it was deleted. If the build hasn't been deleted it's plausible there is a bug in how we look up the old data again It may be worth more seriously considering the XmlFile approach. 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-38268) Parallel step and closure scope
Title: Message Title Jacob Keller commented on JENKINS-38268 Re: Parallel step and closure scope so you're using the git step, and expect its output to return something unique? Is it possible that after that runs once it always returns the first branch? I suspect maybe that step isn't actually returning the value you think it does? Hmm, but you said if you rename the variable it works fine?? that's odd. 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-49077) pipeline checkout step does not perform retries
Title: Message Title Jacob Keller commented on JENKINS-49077 Re: pipeline checkout step does not perform retries I am not sure that works when you need the pipeline to be loaded from the repository. 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller closed an issue as Fixed The root cause of this failure is due to launching the SSH server in the Jenkins test harness, which generates an SSH key. This key generation requires entropy, and Linux blocks when there isn't enough entropy available. In Virtual Machines, especially when running high test volumes, it is very easy to consume all of the available entropy, causing the tests to block when attempting to start the JenkinsRule. If entropy took too long to generate, it resulted in random test failures. This was fixed/worked around by upgrading to a newer version of Jenkins which has the SSH server disabled by default, thus avoiding the root cause of key generation. Jenkins / JENKINS-50642 intermittent JenkinsRule test timeout failure Change By: Jacob Keller Status: Open Closed Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
[JIRA] (JENKINS-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure Yea, upgrading to depending on the 2.60.3 Jenkins server avoids the issue due to no longer starting up SSH. Will close. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50379) Jenkins kills long running sh script with no output
Title: Message Title Jacob Keller commented on JENKINS-50379 Re: Jenkins kills long running sh script with no output I see this issue on scripts which do generate some output, but it happens that parts of the script take some time to run: in my case I'm compiling a kernel module and even when the make output is sent to the console, sometimes individual steps take longer than the timeout... Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller commented on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new I've had this pull request running as well in my test instance that I setup to test the thousands of branches case with the build details pull request as well, so far I haven't found any issues either. I'm curious what the ATH thing is as well. Hopefully we can get to the bottom of that one. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller commented on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new I believe I fixed this with the following pull request: https://github.com/jenkinsci/git-plugin/pull/579 Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller updated JENKINS-50556 Jenkins / JENKINS-50556 git polling succeeds even when origin/master has nothing new Change By: Jacob Keller Status: In Review Progress Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller started work on JENKINS-50556 Change By: Jacob Keller Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller updated JENKINS-50556 Jenkins / JENKINS-50556 git polling succeeds even when origin/master has nothing new Change By: Jacob Keller Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-19022) GIT Plugin (any version) heavily bloats memory use and size of build.xml with "BuildData" fields
Title: Message Title Jacob Keller commented on JENKINS-19022 Re: GIT Plugin (any version) heavily bloats memory use and size of build.xml with "BuildData" fields Make sure that commits aren't rebuilt when they've already been covered by a build. Make sure that job start time isn't significantly worse. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-19022) GIT Plugin (any version) heavily bloats memory use and size of build.xml with "BuildData" fields
Title: Message Title Jacob Keller commented on JENKINS-19022 Re: GIT Plugin (any version) heavily bloats memory use and size of build.xml with "BuildData" fields Yes, please. Additional testing would be a huge benefit. You can even use the one compiled by the pull request build tester found at https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fgit-plugin/detail/PR-578/11/artifacts Specifically https://ci.jenkins.io/job/Plugins/job/git-plugin/job/PR-578/11/artifact/target/git.hpi Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller commented on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new I submitted a pull request https://github.com/jenkinsci/git-plugin/pull/583 which should remove that restriction (as far as I can tell, it was inadvertently added and there's no reason that the extension "author in change log" depends on the workspace polling. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller commented on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new > Thanks Jacob, do you know how I could tell the git plugin to use the remote polling method instead of requiring a workspace? Make sure that you don't use any extensions which enable worktree polling. These include "author in change log", "change log to branch", "require workspace when polling", "Message exclusion", "User exclusion", or "Path restriction" I do not understand offhand why "author in change log" and "change log to branch" require this at the moment, but message exclusion, user exclusion, and path restriction require it because these features aren't implemented within the remote polling code. (I suspect it's possible to do so, but no one has done it). Additionally, remote polling is not setup to handle more than a single branch, so you need to make sure you only use one branch. It's in theory possible to fix these limitations, but I do not offhand know the work involved to do so. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure The test failures are occurring on the VMs see: https://ci.jenkins.io/job/Plugins/job/git-plugin/job/PR-579/5/display/redirect How difficult would it be to get haveged installed on the linux VM? That's what I got running on my local system to resolve the issue (as the particular system does not have a keyboard/mouse locally, nor does it have a hardware RNG source for rng-tools to use). I also verified that my original assumption that it wasn't fixed by 2.60.3 was wrong, so I think just upgrading to 2.60.3 and stopping tests on the old version would fix this as well. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller edited a comment on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure As a comment, Jenkins did not start disabling the SSHD server by default until 2.83 it looks like (based on the disablement landing in SSHD 2.1, and that version not being pulled in until 2.83..So the jenkins-jdk-8 branch likely will fail for the same reason (low entropy when spawning the SSHD server). EDIT: I ran the tests, and checked the output,it appears that SSHD is not run when we build with 2.60.3 as the base. Note that you may be able to get the remote VFs for the Jenkins CI server to enable something like virtio-rng if you have sufficient RNG from the hosts, but haveged may be sufficient as well. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller edited a comment on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure As a comment, Jenkins did not start disabling the SSHD server by default until 2.83 it looks like (based on the disablement landing in SSHD 2.1, and that version not being pulled in until 2.83..So the jenkins-jdk-8 branch likely will fail for the same reason (low entropy when spawning the SSHD server).Note that you may be able to get the remote VFs for the Jenkins CI server to enable something like virtio-rng if you have sufficient RNG from the hosts, but haveged may be sufficient as well. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure As a comment, Jenkins did not start disabling the SSHD server by default until 2.83 it looks like (based on the disablement landing in SSHD 2.1, and that version not being pulled in until 2.83.. So the jenkins-jdk-8 branch likely will fail for the same reason (low entropy when spawning the SSHD server). Note that you may be able to get the remote VFs for the Jenkins CI server to enable virtio-rng if you have sufficient RNG from the hosts, but haveged may be sufficient as well. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure I also just discovered that my linux system had been running without RNGD for a few months, which may explain the failures (no RNGD means that I don't have good entropy source on the system). Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure Additionally, I added some logging to the SSHD plugin, and I was able to extract this information: === Starting changelogAndPolling(jenkins.plugins.git.GitStepTest) 0.009 [id=380] INFO o.jvnet.hudson.test.JenkinsRule#createWebServer: Running on http://localhost:44701/jenkins/ 0.059 [id=386] INFO jenkins.InitReactorRunner$1#onAttained: Started initialization 0.060 [id=398] INFO jenkins.InitReactorRunner$1#onAttained: Listed all plugins 0.066 [id=391] INFO jenkins.InitReactorRunner$1#onAttained: Prepared all plugins 0.070 [id=389] INFO jenkins.InitReactorRunner$1#onAttained: Started all plugins 0.071 [id=389] INFO jenkins.InitReactorRunner$1#onAttained: Augmented all extensions 0.276 [id=409] WARNING h.ExtensionFinder$GuiceFinder$FaultTolerantScope$1#error: Failed to instantiate optional component org.jenkinsci.plugins.workflow.steps.scm.GitStep$DescriptorImpl; skipping 0.709 [id=399] INFO jenkins.InitReactorRunner$1#onAttained: Loaded all jobs 0.711 [id=391] INFO o.j.main.modules.sshd.SSHD#start: SSHD - start() 0.712 [id=391] INFO o.j.main.modules.sshd.SSHD#start: start() - stopped server 177.722 [id=391] INFO o.j.main.modules.sshd.SSHD#start: start() - set port 177.723 [id=391] INFO o.j.main.modules.sshd.SSHD#start: start() - set key pair 177.723 [id=391] INFO o.j.main.modules.sshd.SSHD#start: start() - set public key 177.734 [id=391] INFO o.j.main.modules.sshd.SSHD#start: Started SSHD at port 39243 177.735 [id=406] INFO jenkins.InitReactorRunner$1#onAttained: Completed initialization It appears that we go into SSHD start() and get stuck early in setup. Suddenly, a bunch of things made sense and I think the problem has to do with the platform not generating enough entropy so calls to get random numbers result installs waiting for entropy in /dev/random... That definitely explains the problem and why it's platform specific. I suspect my system I'm testing on does not have enough entropy so when running and re-running the SSHD server in rapid succession, it gets consumed, until the SSHD initialization stalls. Using something like haveged on the VFs would be a good solution I think. I'm looking into whether I can enable the hw rng on my system to avoid the stalls. > If you must support old lines and the Linux CI system has insufficient entropy, the only workaround I know of is installing the haveged package. Nice tip to think in terms of SSH key setup and entropy requirements. Add Comment
[JIRA] (JENKINS-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure > I'm thrilled that you've found what appears to be a persistent source of long running tests in test environments. Thanks for the investigation! Mostly persisted due to the timeout failures. > Are your changes to jenkins-test-harness something you'd be willing to share with me so that I could evaluate them in my test environments? I'd love to remove the source of the periodic timeouts that I receive when running tests on varied environments. If you really wanna see what I did: https://github.com/jacob-keller/jenkins-test-harness/tree/jk-disable-sshd > Jacob Keller if you run your tests using code from that pull request, do you see the same problems? I'll give it a shot. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure For record, here is the initial launch time for when the SSHD server is disabled. It's comparable for when the time is fast, but this is consistent whether I run only one test via -Dtest, vs if I run the entire suite. === Starting testBuildChooserContext(hudson.plugins.git.GitSCMTest) 0.051 [id=22]INFOo.jvnet.hudson.test.WarExploder#explode: Picking up existing exploded jenkins.war at /home/jekeller/git/jenkins/git-plugin/target/jenkins-for-test 0.276 [id=22]INFOo.jvnet.hudson.test.JenkinsRule#createWebServer: Running on http://localhost:41917/jenkins/ 0.854 [id=29]INFOjenkins.InitReactorRunner$1#onAttained: Started initialization 9.177 [id=49]INFOjenkins.InitReactorRunner$1#onAttained: Listed all plugins 9.219 [id=40]INFOjenkins.InitReactorRunner$1#onAttained: Prepared all plugins 9.238 [id=45]INFOjenkins.InitReactorRunner$1#onAttained: Started all plugins 9.244 [id=48]INFOjenkins.InitReactorRunner$1#onAttained: Augmented all extensions 10.397 [id=30]INFOjenkins.InitReactorRunner$1#onAttained: Loaded all jobs 10.493 [id=29]WARNING h.ExtensionFinder$GuiceFinder$FaultTolerantScope$1#error: Failed to instantiate optional component org.jenkinsci.plugins.workflow.steps.scm.GitStep$DescriptorImpl; skipping 11.212 [id=37]INFOjenkins.InitReactorRunner$1#onAttained: Completed initialization Additionally, it appears some work is avoided for multiple tests in the same class since the following test is much faster: === Starting testPolling_environmentValueInBranchSpec(hudson.plugins.git.GitSCMTest) 0.005 [id=7592] INFOo.jvnet.hudson.test.JenkinsRule#createWebServer: Running on http://localhost:32975/jenkins/ 0.058 [id=7598] INFOjenkins.InitReactorRunner$1#onAttained: Started initialization 0.059 [id=7610] INFOjenkins.InitReactorRunner$1#onAttained: Listed all plugins 0.062 [id=7603] INFOjenkins.InitReactorRunner$1#onAttained: Prepared all plugins 0.065 [id=7614] INFOjenkins.InitReactorRunner$1#onAttained: Started all plugins 0.065 [id=7621] INFOjenkins.InitReactorRunner$1#onAttained: Augmented all extensions 0.210 [id=7614] WARNING h.ExtensionFinder$GuiceFinder$FaultTolerantScope$1#error: Failed to instantiate optional component org.jenkinsci.plugins.workflow.steps.scm.GitStep$DescriptorImpl; skipping 0.334 [id=7612] INFOjenkins.InitReactorRunner$1#onAttained: Loaded all jobs 0.337 [id=7605] INFOjenkins.InitReactorRunner$1#onAttained: Completed initialization I am still very confused why running multiple tests (not even in parallel, or with multiple threads) ends up resulting in the slowdown, but disabling the SSHD server seems to fix it.
[JIRA] (JENKINS-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure Maybe Jesse Glick, or Stephen Connolly have some input? Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure I did a test with a modified jenkins-test-harness that always disabled the SSHD server, and it improved this dramatically, with tests taking <5minutes now. I still don't have a good method to actually implement this yet, but I definitely think we should improve this if we can. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure A PresetData won't work with using @ClassRule to setup the JenkinsRule (I can't figure a way to get the PresetData to run prior to the JenkinsRule setup...) Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure I don't know if this is the best solution, but I think we could extend the JenkinsRule to allow a preset data which disables the SSHD server. I can't find a better way that actually disables the server at startup. I dislike that it is an opt-in rather than an "opt in to re-enable the SSHD server in the tests that need it", since it would further require changes to the git tests.. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure It looks like jenkins-test-harness currently depends on 1.651.1, which does not disable SSHD by default. I'm unsure of how to add configuration at setup to avoid starting SSHD. but I am suspicious that this will resolve the test issues here. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller edited a comment on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure I am pretty sure this can be resolved by disabling the SSHD server at startup. I am not certain how to do this yet. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure I am pretty sure this can be resolved by disabling the SSHD server at startup. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller edited a comment on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure When I run an individual test it takes almost no time between finalizing setup and starting the SSHD server: 11.812 [id=32] FINE jenkins.InitReactorRunner$1#onTaskCompleted: Completed Finalizing set up 11.812 [id=40] FINE jenkins.InitReactorRunner$1#onAttained: Attained Finalizing set up 11.971 [id=24] INFO o.j.main.modules.sshd.SSHD#start: Started SSHD at port 35077 11.971 [id=24] FINE jenkins.InitReactorRunner$1#onTaskCompleted: Completed SSHD.init 11.975 [id=34] FINE jenkins.InitReactorRunner$1#onTaskCompleted: Completed GroovyInitScript.init But when I run the tests as a group... 0. 737 757 [id= 1773 463 ] >- FINE >--- jenkins.InitReactorRunner$1#onTaskCompleted: Completed AperiodicWork.init Finalizing set up 0. 738 757 [id= 1778 463 ] >- FINE >--- jenkins.InitReactorRunner$1# onTaskCompleted onAttained : Completed Attained Finalizing set up 0 5 . 738 065 [id= 1778 468 ] >- FINE >---jenkins hudson . InitReactorRunner$1 model.Queue # onAttained maintain : Attained Finalizing set up Queue maintenance started hudson.model.Queue@1e884c4c 4 10 . 252 065 [id= 1724 470 ] >- FINE >--- hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@ 43302067 1e884c4c 5 15 . 058 066 [id= 1752 473 ] >- FINE >--- hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@ 3aba7488 1e884c4c 9 20 . 252 066 [id= 1755 475 ] >- FINE >--- hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@ 43302067 1e884c4c 10 25 . 058 066 [id= 1757 440 ] >- FINE >--- hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@ 3aba7488 1e884c4c 30.067 [id=469] FINE hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@1e884c4c 75 35 . 064 067 [id= 1724 472 ] >- FINE >--- hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@ 3aba7488 1e884c4c 79 40 . 258 068 [id= 1754 473 ] >- FINE >--- hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@ 43302067 1e884c4c 80 45 . 065 068 [id= 1756 476 ] >- FINE >--- hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@ 3aba7488 1e884c4c 84 50 . 258 069 [id= 1760 468 ] >- FINE >--- hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@ 43302067 1e884c4c 85 55 . 065 069 [id= 1759 470 ] >- FINE >--- hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@ 3aba7488 1e884c4c 88 58 . 896 574 [id= 1788 464 ] >- INFO >--- o.j.main.modules.sshd.SSHD#start: Started SSHD at port 43187 46515 88 58 . 896 574 [id= 1788 464 ] >- FINE >--- jenkins.InitReactorRunner$1#onTaskCompleted: Completed SSHD.init I snipped the queue maintenance messages, but there's nothing else between these messages when logged at FINE
[JIRA] (JENKINS-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller edited a comment on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure When I run an individual test it takes almost no time between finalizing setup and starting the SSHD server: 11.812 [id=32] FINE jenkins.InitReactorRunner$1#onTaskCompleted: Completed Finalizing set up 11.812 [id=40] FINE jenkins.InitReactorRunner$1#onAttained: Attained Finalizing set up 11.971 [id=24] INFO o.j.main.modules.sshd.SSHD#start: Started SSHD at port 35077 11.971 [id=24] FINE jenkins.InitReactorRunner$1#onTaskCompleted: Completed SSHD.init 11.975 [id=34] FINE jenkins.InitReactorRunner$1#onTaskCompleted: Completed GroovyInitScript.init But when I run the tests as a group... 0.737 [id=1773]>-FINE>---jenkins.InitReactorRunner$1#onTaskCompleted: Completed AperiodicWork.init 0.738 [id=1778]>-FINE>---jenkins.InitReactorRunner$1#onTaskCompleted: Completed Finalizing set up 0.738 [id=1778]>-FINE>---jenkins.InitReactorRunner$1#onAttained: Attained Finalizing set up 4.252 [id=1724]>-FINE>---hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@43302067 5.058 [id=1752]>-FINE>---hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@3aba7488 9.252 [id=1755]>-FINE>---hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@43302067 10.058 [id=1757]>-FINE>---hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@3aba748875.064 [id=1724]>-FINE>---hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@3aba7488 79.258 [id=1754]>-FINE>---hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@43302067 80.065 [id=1756]>-FINE>---hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@3aba7488 84.258 [id=1760]>-FINE>---hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@43302067 85.065 [id=1759]>-FINE>---hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@3aba7488 88.896 [id=1788]>-INFO>---o.j.main.modules.sshd.SSHD#start: Started SSHD at port 43187 88.896 [id=1788]>-FINE>---jenkins.InitReactorRunner$1#onTaskCompleted: Completed SSHD.init There I snipped the queue maintenance messages, but there 's no other messages printed nothing else between these messages when logged at FINE Add Comment
[JIRA] (JENKINS-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure When I run an individual test it takes almost no time between finalizing setup and starting the SSHD server: 11.812 [id=32] FINE jenkins.InitReactorRunner$1#onTaskCompleted: Completed Finalizing set up 11.812 [id=40] FINE jenkins.InitReactorRunner$1#onAttained: Attained Finalizing set up 11.971 [id=24] INFO o.j.main.modules.sshd.SSHD#start: Started SSHD at port 35077 11.971 [id=24] FINE jenkins.InitReactorRunner$1#onTaskCompleted: Completed SSHD.init 11.975 [id=34] FINE jenkins.InitReactorRunner$1#onTaskCompleted: Completed GroovyInitScript.init But when I run the tests as a group... 0.737 [id=1773]>FINE>--jenkins.InitReactorRunner$1#onTaskCompleted: Completed AperiodicWork.init 0.738 [id=1778]>FINE>--jenkins.InitReactorRunner$1#onTaskCompleted: Completed Finalizing set up 0.738 [id=1778]>FINE>--jenkins.InitReactorRunner$1#onAttained: Attained Finalizing set up 4.252 [id=1724]>FINE>--hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@43302067 5.058 [id=1752]>FINE>--hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@3aba7488 9.252 [id=1755]>FINE>--hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@43302067 10.058 [id=1757]>FINE>--hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@3aba7488 75.064 [id=1724]>FINE>--hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@3aba7488 79.258 [id=1754]>FINE>--hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@43302067 80.065 [id=1756]>FINE>--hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@3aba7488 84.258 [id=1760]>FINE>--hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@43302067 85.065 [id=1759]>FINE>--hudson.model.Queue#maintain: Queue maintenance started hudson.model.Queue@3aba7488 88.896 [id=1788]>INFO>--o.j.main.modules.sshd.SSHD#start: Started SSHD at port 43187 88.896 [id=1788]>FINE>--jenkins.InitReactorRunner$1#onTaskCompleted: Completed SSHD.init There's no other messages printed between these Add Comment
[JIRA] (JENKINS-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure I've configured the logger to also output FINE log messages, and am running the tests now, hopefully that will shed light into what exactly is taking so long during Jenkins initialization. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure Something causes the tests to take significantly longer when run together, vs when run on their own... Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure More information: I dug into the surefire test reports of one of the slow tests: === Starting jenkins.plugins.git.GitSCMFileSystemTest 0.018 [id=184] INFO o.jvnet.hudson.test.JenkinsRule#createWebServer: Running on http://localhost:33389/jenkins/ 0.078 [id=190] INFO jenkins.InitReactorRunner$1#onAttained: Started initialization 0.082 [id=203] INFO jenkins.InitReactorRunner$1#onAttained: Listed all plugins 0.089 [id=195] INFO jenkins.InitReactorRunner$1#onAttained: Prepared all plugins 0.093 [id=191] INFO jenkins.InitReactorRunner$1#onAttained: Started all plugins 0.093 [id=192] INFO jenkins.InitReactorRunner$1#onAttained: Augmented all extensions 0.310 [id=197] INFO jenkins.InitReactorRunner$1#onAttained: Loaded all jobs 0.316 [id=203] WARNING h.ExtensionFinder$GuiceFinder$FaultTolerantScope$1#error: Failed to instantiate optional component org.jenkinsci.plugins.workflow.steps.scm.GitStep$DescriptorImpl; skipping 168.000 [id=212] INFO o.j.main.modules.sshd.SSHD#start: Started SSHD at port 38287 168.001 [id=212] INFO jenkins.InitReactorRunner$1#onAttained: Completed initialization Notice how it takes almost 167 seconds just to get to where the SSHD is started? The actual tests themselves are actually incredibly short: So we're basically spending most of the test run time (168.877 s - in jenkins.plugins.git.GitSCMFileSystemTest) just in that pre-run code. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins
[JIRA] (JENKINS-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure Paradoxically, if I increase the timeout run, sometimes the steps take less actual time to run: [INFO] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 481.838 s - in jenkins.plugins.git.GitStepTest with -Djenkins.test.timeout=360 [ERROR] Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 654.984 s <<< FAILURE! - in jenkins.plugins.git.GitStepTest with -Djenkins.test.timeout=180 (the default) I think this is because something (I am not sure what) is causing the test to be re-run (note the Tests Run = 7 vs 8 on the failing case). Also note if i run the test solo using -Dtest=GitStepTest it is much faster: [INFO] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 92.27 s - in jenkins.plugins.git.GitStepTest I suspect that something is going wrong when run in the normal way, resulting in the increased test time Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller commented on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new Phil Adams, it could maybe use the remote polling method, which doesn't require the workspace, but that gets turned off for a variety of reasons. It sounds like a different issue than the one I am describing here. I do have a potential fix posted at https://github.com/jenkinsci/git-plugin/pull/579 and you'd be welcome to try it out and see if it fixes your problem, (though I doubt it would...) Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller commented on JENKINS-50642 Re: intermittent JenkinsRule test timeout failure Error test timed out after 180 seconds Stacktrace org.junit.runners.model.TestTimedOutException: test timed out after 180 seconds at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:267) at jenkins.InitReactorRunner.run(InitReactorRunner.java:44) at jenkins.model.Jenkins.executeReactor(Jenkins.java:916) at jenkins.model.Jenkins.(Jenkins.java:815) at hudson.model.Hudson.(Hudson.java:85) at org.jvnet.hudson.test.JenkinsRule.newHudson(JenkinsRule.java:611) at org.jvnet.hudson.test.JenkinsRule.before(JenkinsRule.java:384) at org.jvnet.hudson.test.JenkinsRule$1.evaluate(JenkinsRule.java:537) at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298) at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.lang.Thread.run(Thread.java:748) Standard Output === Starting jenkins.plugins.git.GitSCMFileSystemTest Standard Error 0.009 [id=2163] INFO o.jvnet.hudson.test.JenkinsRule#createWebServer: Running on http://localhost:40627/jenkins/ 0.066 [id=2169] INFO jenkins.InitReactorRunner$1#onAttained: Started initialization 0.077 [id=2182] INFO jenkins.InitReactorRunner$1#onAttained: Listed all plugins 0.085 [id=2184] INFO jenkins.InitReactorRunner$1#onAttained: Prepared all plugins 0.085 [id=2182] INFO jenkins.InitReactorRunner$1#onAttained: Started all plugins 0.088 [id=2174] INFO jenkins.InitReactorRunner$1#onAttained: Augmented all extensions 0.238 [id=2174] INFO jenkins.InitReactorRunner$1#onAttained: Loaded all jobs 0.239 [id=2173] WARNING h.ExtensionFinder$GuiceFinder$FaultTolerantScope$1#error: Failed to instantiate optional component org.jenkinsci.plugins.workflow.steps.scm.GitStep$DescriptorImpl; skipping 180.001 [id=1] WARNING o.j.hudson.test.JenkinsRule$2#evaluate: Test timed out (after 180 seconds). "Jenkins cron thread" Id=2167 Group=FailOnTimeoutGroup WAITING on java.util.TaskQueue@795f8317 at java.lang.Object.wait(Native Method) - waiting on java.util.TaskQueue@795f8317 at java.lang.Object.wait(Object.java:502) at java.util.TimerThread.mainLoop(Timer.java:526) at java.util.TimerThread.run(Timer.java:505) "jenkins.util.Timer [#10]" Id=2196 Group=FailOnTimeoutGroup WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@77c10a5f at sun.misc.Unsafe.park(Native Method) - waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@77c10a5f at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) "jenkins.util.Timer [#1]" Id=2168 Group=FailOnTimeoutGroup WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$Conditi
[JIRA] (JENKINS-50642) intermittent JenkinsRule test timeout failure
Title: Message Title Jacob Keller created an issue Jenkins / JENKINS-50642 intermittent JenkinsRule test timeout failure Issue Type: Bug Assignee: Mark Waite Components: git-plugin, jenkins-test-harness Created: 2018-04-06 20:08 Priority: Major Reporter: Jacob Keller Sometimes, the JenkinsRule based tests in the git-plugin can fail intermittently when the default test is set to 180. It appears pretty often if you just run "mvn test" in the git plugin source code, it is fairly common to see a few tests marked as flaky get re-run and pass on the second run. If you increase the test timeout to say, 10 minutes, then the tests will pass. A few other tests that aren't marked as flaky also sometimes fail, and it is difficult to debug exactly what's causing them. [INFO] [INFO] Results: [INFO] [WARNING] Flakes: [WARNING] hudson.plugins.git.GitChangeSetBadArgsTest.testFindOrCreateEmptyCommitter(hudson.plugins.git.GitChangeSetBadArgsTest) [ERROR] Run 1: GitChangeSetBadArgsTest>Object.wait:502->Object.wait:-2 » TestTimedOut test ti... [INFO] Run 2: PASS [INFO] [WARNING] hudson.plugins.git.GitPublisherTest.testMergeAndPushFF(hudson.plugins.git.GitPublisherTest) [ERROR] Run 1: GitPublisherTest>Object.wait:502->Object.wait:-2 » TestTimedOut test timed out... [INFO] Run 2: PASS [INFO] [WARNING] hudson.plugins.git.GitPublisherTest.testMergeAndPushWithSystemEnvVar(hudson.plugins.git.GitPublisherTest) [ERROR] Run 1: GitPublisherTest>Object.wait:502->Object.wait:-2 » TestTimedOut test timed out... [INFO] Run 2: PASS [INFO] [WARNING] hudson.plugins.git.GitSCMTest.testEmailCommitter(hudson.plugins.git.GitSCMTest) [ERROR] Run 1: GitSCMTest>Object.wait:502->Object.wait:-2 » TestTimedOut test timed out after... [INFO] Run 2: PASS [INFO] [WARNING] hudson.plugins.git.GitStatusTest.testDoNotifyCommitWithTwoBranches(hudson.plugins.git.GitStatusTest) [ERROR] Run 1: GitStatusTest>Object.wait:502->Object.wait:-2 » TestTimedOut test timed out af... [INFO] Run 2: PASS [INFO] [WARNING] jenkins.plugins.git
[JIRA] (JENKINS-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller commented on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new I'm able to reproduce the issue by simply having the pipeline checkout master at some commit which was not "built", which causes the polling logic to treat it as an available tag. However, when we actually run the build, we'll never checkout that version again, so polling will always return true. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller commented on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new I made a separate jenkins instance to test this, and it appears by default, the git plugin does not actually checkout the commit and setup the local "master" reference. However, if anything happens to the repository in the workspace to actually get a local ref named master, we'll end up in a loop where polling always returns true. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller commented on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new This only happens if the job is setup to perform polling in the workspace. If it doesn't use the workspace polling, then it does not have this issue. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller updated an issue Jenkins / JENKINS-50556 git polling succeeds even when origin/master has nothing new Change By: Jacob Keller Environment: Git Plugin 3.3.2Jenkins 2.60.1 Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller edited a comment on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new It looks like this is performing polling in the workspace, so it happens that the workspace has master checked out at the older commit. I'm still unsure exactly why *that* happens, but some of the repositories appear to never actually check the branch out, so the revParse fails, while others do have it checked out. It looks like the workspace was requiring polling due to an extension. Removing the extension appears to have allowed it to work, but we now don't actually appear to check any of the extra repositories... Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller commented on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new It looks like this is performing polling in the workspace, so it happens that the workspace has master checked out at the older commit. I'm still unsure exactly why that happens, but some of the repositories appear to never actually check the branch out, so the revParse fails, while others do have it checked out. It looks like the workspace was requiring polling due to an extension. Removing the extension appears to have allowed it to work, but we now don't actually appear to check any of the extra repositories... Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Jacob Keller created an issue Jenkins / JENKINS-50556 git polling succeeds even when origin/master has nothing new Issue Type: Bug Assignee: Mark Waite Components: git-plugin Created: 2018-04-03 23:36 Priority: Minor Reporter: Jacob Keller I have a repository which is setup to perform git polling, and it always triggers, suggesting there are changes, even though there are not. In this case, the job has multiple checkouts using a pipeline, but I think it would only happen in the case of a single checkout as well. Specifically, the branch name is master, and it checks first all the "remote/branch" combinations, (in this case, "origin/master") and then fails to find anything new (as origin/master was already built). Then, it checks the branch name on its own, thinking that maybe it's a tag or some other ref. This results in reporting a separate commit (likely whatever master happens to be at when the polling was created), and thus reports a new commit to build. This causes the build to trigger every polling timeout, even though there aren't any real new changes. Here's a subset of the actual output with repository names and paths redacted. I have the VERBOSE logging enabled for more information. Started on Apr 3, 2018 4:01:00 PM Using strategy: Default [poll] Last Built Revision: Revision 72c4cea985bb5ff14813d27dac94f34887cbd841 (refs/remotes/origin/master) using GIT_SSH to set credentials > git ls-remote -h # timeout=10 Found 1 remote heads on [poll] Latest remote head revision on refs/heads/master is: 72c4cea985bb5ff14813d27dac94f34887cbd841 - already built by 1738 Using strategy: Default [poll] Last Built Revision: Revision cc24044526e9d460c74a59fcdeb12e43a446cb7d (origin/master) > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git config remote.origin.url # timeout=10 Fetchin
[JIRA] (JENKINS-44762) Polling always finds changes when you checkout 2 branches of the same repo in the pipeline
Title: Message Title
Jacob Keller edited a comment on JENKINS-44762
Re: Polling always finds changes when you checkout 2 branches of the same repo in the pipeline
> Probably another symptom of the well-known failure of the {{git}} plugin to correctly implement SCM APIs (see {{BuildData}}). No one has figured out how to refactor it without causing regressions for thousands of users. I think this has to do with multiple git clones in pipeline don't store the build data properly, resulting in inability to correctly identify that a previous build has already built on that second git clone.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
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-44762) Polling always finds changes when you checkout 2 branches of the same repo in the pipeline
Title: Message Title Jacob Keller commented on JENKINS-44762 Re: Polling always finds changes when you checkout 2 branches of the same repo in the pipeline > Probably another symptom of the well-known failure of the git plugin to correctly implement SCM APIs (see BuildData). No one has figured out how to refactor it without causing regressions for thousands of users. I think this has to do with multiple git clones in pipeline don't store the build data properly, resulting in inability to correctly identify that a previous build has already built on that second git clone. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-50260) lock step interacts badly with timeout step
Title: Message Title
Jacob Keller commented on JENKINS-50260
Re: lock step interacts badly with timeout step
This is with Lockable Resource Plugin 2.0 I'm not 100% sure if the issue is a timeout() killing the lock() or not. I looked at the pipeline graph, and I see a timeout set to 15 minutes and the lock is blocked for 13 minutes, so it's possible this isn't the issue. I also had 2 other branches of parallel pipeline that ended up blocking for 4 days before we killed the job. Specifically, the lock is only used inside a single build to limit parallelism of a section that cannot be run concurrently during a parallel{} chunk. Since the lockable resource name includes the BUILD_TAG, it should be a resource unique to the individual build, and thus the only places it should become locked are in other parallel threads. Any other ideas what might cause the deadlock?
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
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-50260) lock step interacts badly with timeout step
Title: Message Title
Jacob Keller created an issue
Jenkins / JENKINS-50260
lock step interacts badly with timeout step
Issue Type:
Bug
Assignee:
Unassigned
Components:
lockable-resources-plugin, workflow-basic-steps-plugin
Created:
2018-03-19 17:07
Priority:
Blocker
Reporter:
Jacob Keller
I have a job which takes a lock {} inside of a timeout {} block. If the timeout expires, then the lock {} is not freed, which results in future taking of the lock becoming a deadlock. It seems like timeout {} should properly free the lock when forcing an exit from the lock() step? Is this just a bad pipeline/workflow pattern?
Add Comment
[JIRA] (JENKINS-47789) Git BuildData entry leaks in from Gerrit event triggered builds in build.xml
Title: Message Title Jacob Keller commented on JENKINS-47789 Re: Git BuildData entry leaks in from Gerrit event triggered builds in build.xml This is a duplicate of 19022, though Gerrit makes this significantly worse. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-45579) Step to set stage or parallel status
Title: Message Title Jacob Keller commented on JENKINS-45579 Re: Step to set stage or parallel status This is also somewhat related to steps like the warnings publisher, which if you run in parallel results in the whole build being marked unstable even though only a single segment should have been, which may not be fixed by making separate unstable results for each parallel step (unless it fully encapsulates the build?) Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-42738) Support independent credentials per git submodule
Title: Message Title Jacob Keller commented on JENKINS-42738 Re: Support independent credentials per git submodule It is pretty tricky to do. The best way would be to re-write the entire branch and URL display so that you could add credentials there. Or adding a separate "use these credentials for this URL" that could be for either parent or submodule. But that also is a bit clunky. It would be most helpful if we could simply store credentials in Jenkins as to which URL they should be used and then just go "hey, jenkins, give us the credential for this URL" Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-40164) Obtain parallel warnings results in pipeline
Title: Message Title
Jacob Keller commented on JENKINS-40164
Re: Obtain parallel warnings results in pipeline
For example, in a pipeline, you can do something like: try { sh "some-command" catch (err) { "do stuff" } In a regular build, you would run shell script as part of the main build steps, and when the shell returns with a negative error code, the build result would become failure. However, the warnings plugin is run via the generic "step()" pipeline, and instead of returning an error or throwing an exception, the step literally sets the build status. This doesn't work in parallel since the whole build has a single status, and each parallel branch might result in different build status, and thus conflict. What I want is a new "scanWarnings" step which is a pipeline specific step we could call, and it would throw an exception, which we could catch in the pipeline code. It might be worth getting some input from someone who uses pipelines more?
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] (JENKINS-40164) warnings pipeline parallel obtian "results"
Title: Message Title Jacob Keller commented on JENKINS-40164 Re: warnings pipeline parallel obtian "results" JENKINS-30551 is related but not identical to this issue. Basically, what I want to be able to do is to run the warnings plugin inside a parallel branch, so that I can scan warnings for a particular log file generated differently for each parallel branch. In this case, each branch is running on a separate node, and each node is a different version of the Linux Kernel, I am compiling a driver. I need to be able to determine the outcome of the warnings step inside the parallel branch. Unfortunately, the warnings plugin sets the entire job status, so if I just check the buildStatus variable directly, I am unable to determine whether the failure was this node or some other node, as the process is being run in parallel. Ideally, a separate pipeline specific step would be introduced which can run the warnings plugin and throws an exception when it fails. I could then catch the exception in the pipeline script, and handle it in various ways. My current job wants to rename a file to indicate whether the log has warnings or not. Finally, JENKINS-30551 is about making the display of multiple parallel branches work correctly which is a good thing but is not exactly related to my problem. 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/op
[JIRA] (JENKINS-5076) Master job of multiconfig project can be executed on hosts that are marked as "Leave this machine for tied jobs only"
Title: Message Title Jacob Keller commented on JENKINS-5076 Re: Master job of multiconfig project can be executed on hosts that are marked as "Leave this machine for tied jobs only" See also https://issues.jenkins-ci.org/browse/JENKINS-23459 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] (JENKINS-5076) Master job of multiconfig project can be executed on hosts that are marked as "Leave this machine for tied jobs only"
Title: Message Title
Jacob Keller reopened an issue
This issue is still occurring, as long as you also have marked the master Jenkins node as "exclusive". The reasoning can be found in commit 55bf88329027 ("If every node is restricted to tied jobs only, Matrix build jobs can never start.", 2013-06-18) I believe this commit should be reverted, since it is definitely not what the user would expect of an exclusive node.
Jenkins / JENKINS-5076
Master job of multiconfig project can be executed on hosts that are marked as "Leave this machine for tied jobs only"
Change By:
Jacob Keller
Resolution:
Fixed
Status:
Resolved Reopened
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-40729) flyweight task executing on exclusive slave
Title: Message Title
Jacob Keller commented on JENKINS-40729
Re: flyweight task executing on exclusive slave
For reference, commit 55bf88329027 ("If every node is restricted to tied jobs only, Matrix build jobs can never start.", 2013-06-18) of the Jenkins CORE changed this behavior. Unfortunately, this means that exclusive nodes no longer ignore flyweight jobs if the master node cannot itself host the jobs. I think this needs to be refined somewhat, and possibly simply be considered an error.
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] (JENKINS-40729) flyweight task executing on exclusive slave
Title: Message Title Jacob Keller created an issue Jenkins / JENKINS-40729 flyweight task executing on exclusive slave Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: core, matrix-project-plugin, swarm-plugin Created: 2016/Dec/29 10:15 PM Priority: Critical Reporter: Jacob Keller I have a Matrix Job which runs on multiple slaves. These slaves are provided by Swarm Client, and are marked as "exclusive" such that they should only run jobs which match the slave label. However, the matrix job's initial "flyweight" light weight master job automatically selects this node as the master, and results in the build failing because this particular slave does not have the Git utilities installed, so it cannot run the flyweight task. I had assumed that "exclusive" really would be "exclusive" and would prevent flyweight tasks from selecting this machine. Add Comment
[JIRA] (JENKINS-40172) git pipeline scm poll workspace doesn't find git repository
Title: Message Title Jacob Keller created an issue Jenkins / JENKINS-40172 git pipeline scm poll workspace doesn't find git repository Issue Type: Improvement Assignee: Mark Waite Components: git-plugin Created: 2016/Dec/01 10:04 PM Priority: Major Reporter: Jacob Keller The git plugin doesn't appear to find the proper workspace when performing SCM polling on a pipeline job. I use the checkout() step and have set SCM polling to 10 minutes. Every 10 minutes, the polling log shows something along these lines: Using strategy: Default [poll] Last Built Revision: Revision 5f6e2e39083ff256ccc9face14f6358a5c522ee4 (origin/master) No Git repository yet, an initial checkout is required This line appears in the git plugin code in a section that appears to be the case of "requiresWorkspaceForPolling = true" which is the case when using multiple branches, or when the branch contains wildcards. I haven't yet figured out why it thinks my configuration has multiple branches (it should only have one) but either way the polling via workspace should still work as expected... When we go through this path, it appears that the pipeline job doesn't get the correct workspace, as the one that we run polling inside does not have the repository checked out.
[JIRA] (JENKINS-39820) The server rejected the connection: None of the protocols were accepted
Title: Message Title Jacob Keller commented on JENKINS-39820 Re: The server rejected the connection: None of the protocols were accepted I am having the same issue. I suspect it is because the remoting API in jenkins and the swarm client don't match. 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] (JENKINS-40164) warnings pipeline parallel obtian "results"
Title: Message Title Jacob Keller created an issue Jenkins / JENKINS-40164 warnings pipeline parallel obtian "results" Issue Type: Improvement Assignee: Ulli Hafner Components: warnings-plugin Created: 2016/Dec/01 7:39 PM Priority: Minor Reporter: Jacob Keller I currently use the warnings plugin in a pipeline build by simply calling the build step. Doing this sets the build result to unstable, so I was checking that during the pipeline to determine whether some extra steps to run. Specifically, I have a parallel build, which builds on multiple different configurations in parallel, and I want to rename the log file for each build to "unstable" only if that configuration got warnings. However, the build result is global for the whole pipeline. How can I obtain the number of warnings or the "result" of the warnings step in such a way that each parallel invocation can get its own results? This allows me to rename my logged files so that users who look at the final results can quickly determine which configurations were faulty? Add Comment
[JIRA] (JENKINS-38676) git summary should show the repository URL
Title: Message Title Jacob Keller commented on JENKINS-38676 Re: git summary should show the repository URL Note that this has a workaround in that you can set a "Custom SCM Name" extension. This is probably good enough for now, though it's not intuitive that you need to set a "custom" name to have any name at all. 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] (JENKINS-38675) gerrit trigger git summary show refspec instead of branch
Title: Message Title Jacob Keller commented on JENKINS-38675 Re: gerrit trigger git summary show refspec instead of branch https://github.com/jenkinsci/gerrit-trigger-plugin/pull/299 It turns out this is a relatively simple change in the GerritTriggerBuildChooser. I proposed a pull request with this change to gerrit-trigger-plugin. 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] (JENKINS-38675) gerrit trigger git summary show refspec instead of branch
Title: Message Title Jacob Keller started work on JENKINS-38675 Change By: Jacob Keller Status: Open In Progress 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] (JENKINS-38675) gerrit trigger git summary show refspec instead of branch
Title: Message Title Jacob Keller commented on JENKINS-38675 Re: gerrit trigger git summary show refspec instead of branch I disagree with the removal of git-plugin and git-client-plugin as I believe that it probably requires a change in more than just the gerrit-trigger-plugin.. 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] (JENKINS-38676) git summary should show the repository URL
Title: Message Title Jacob Keller created an issue Jenkins / JENKINS-38676 git summary should show the repository URL Issue Type: Improvement Assignee: Mark Waite Components: git-plugin Created: 2016/Oct/04 5:20 AM Priority: Minor Reporter: Jacob Keller When using multiple git repositories in a pipeline, the git plugin adds a sumary for each built repository that looks something like Revision: a branch another branch ... another branch (Usually only one branch, but some cases show more). This summary could benefit from adding the repository URL or a human readable name, so that users can quickly see which revision belongs to what repository. Especially true when there are multiple repositories in a single build. Add Comment
[JIRA] (JENKINS-38675) gerrit trigger git summary show refspec instead of branch
Title: Message Title Jacob Keller created an issue Jenkins / JENKINS-38675 gerrit trigger git summary show refspec instead of branch Issue Type: Improvement Assignee: rsandell Components: gerrit-trigger-plugin, git-client-plugin, git-plugin Created: 2016/Oct/04 5:18 AM Priority: Minor Reporter: Jacob Keller When you have multiple git projects in a pipeline build, multiple git summary bits appear in the build information when you highlight the build. These currently show something like Revision: a built branch another built branch When using the gerrit trigger plugin, the "built branches" only show the name of the branch from $GERRIT_BRANCH, instead of showing a refspec. Ideally when using these together, we should see the refspec instead of the branch because this is really what was built by the job. Add Comment
[JIRA] (JENKINS-38052) Pipeline parallel map not supporting curried closures
Title: Message Title Jacob Keller commented on JENKINS-38052 Re: Pipeline parallel map not supporting curried closures I think this is similar to https://issues.jenkins-ci.org/browse/JENKINS-38268 and doesn't require use of curried closures, but just closures within parallel in general. 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] (JENKINS-38268) Parallel step and closure scope
Title: Message Title Jacob Keller edited a comment on JENKINS-38268 Re: Parallel step and closure scope I have this exact issue as well . I have a block that takes a closure and sets up the parallel branches and wants to run the closure once for each node, but the parameter to the closure always takes only the last value when inside the node. 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] (JENKINS-38268) Parallel step and closure scope
Title: Message Title Jacob Keller commented on JENKINS-38268 Re: Parallel step and closure scope I have this exact issue. 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] (JENKINS-32479) multiple git repositories sometimes fail to checkout some of them into subdirectory
Title: Message Title Jacob Keller commented on JENKINS-32479 Re: multiple git repositories sometimes fail to checkout some of them into subdirectory Unfortunately this would still result in the same problem, because the git plugin wipes out the workspace when cloning, so it is still possible to have the issue occur. It is easier to avoid in the pipeline as long as the pipeline steps are ordered correctly. The user just has to know and understand that the git plugin will wipe out the workspace path so you must ensure that the repositories are ordered correctly. In general, for pipeline this is obvious, but it is not obvious for the multi-scm plugin. 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] (JENKINS-36584) pipeline branched build failes with workspace not a directory issue
Title: Message Title Jacob Keller commented on JENKINS-36584 Re: pipeline branched build failes with workspace not a directory issue I'll try to get a copy of the steps I'm running tomorrow. 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] (JENKINS-36584) pipeline branched build failes with workspace not a directory issue
Title: Message Title Jacob Keller created an issue Jenkins / JENKINS-36584 pipeline branched build failes with workspace not a directory issue Issue Type: Bug Assignee: Jesse Glick Components: workflow-plugin Created: 2016/Jul/11 10:35 PM Environment: Jenkins 2.12 Priority: Blocker Reporter: Jacob Keller I have a branch setup for a pipeline which fails on all but one slave with a weird issue that the shell script cannot run because the workspace is a file not a directory. I also have an unarchive step just prior to the sh script which unarchives a tar.gz file into the workspace. When I checked on the slave system, it appears that the unarchive step in the pipeline is actually fully replacing the workspace with the unarchived file instead of placing it inside the work directory. java.io.IOException: Cannot run program "nohup" (in directory "/home/jenkins/workspace/i40e/pipeline"): error=20, Not a directory at java.lang.ProcessBuilder.start(Unknown Source) at hudson.Proc$LocalProc.(Proc.java:243) at hudson.Proc$LocalProc.(Proc.java:212) at hudson.Launcher$LocalLauncher.launch(Launcher.java:815) at hudson.Launcher$ProcStarter.start(Launcher.java:381) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1148) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1113) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.jav
[JIRA] (JENKINS-27916) GString not flattened to String by DSL inside a map
Title: Message Title
Jacob Keller commented on JENKINS-27916
Re: GString not flattened to String by DSL inside a map
The above does not work and still generates the exception: def file = "name-$ {env.BUILD_NUMBER} " [(file) : "."] still results in java.lang.ClassCastException: org.codehaus.groovy.runtime.GStringImpl cannot be cast to java.lang.String at org.jenkinsci.plugins.workflow.steps.ArtifactUnarchiverStepExecution.run(ArtifactUnarchiverStepExecution.java:44) at org.jenkinsci.plugins.workflow.steps.ArtifactUnarchiverStepExecution.run(ArtifactUnarchiverStepExecution.java:20) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:49) at hudson.security.ACL.impersonate(ACL.java:213) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:47) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)
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] (JENKINS-27668) Add support for multiple git repositories in a single workspace
Title: Message Title Jacob Keller edited a comment on JENKINS-27668 Re: Add support for multiple git repositories in a single workspace I suspect job definition would require re-work to support multiple SCMs. It's not un-doable but no one has put forth effort to work on it. I think it's best to be a core Jenkins feature, and get the review necessary to support the workflow. I don't think it's too far out there, and I think even changes could be handled properly that way. I think that this extension of features is worth doing even though pipelines support multiple repositories, as pipelines are more complex and not for everyone. 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] (JENKINS-27668) Add support for multiple git repositories in a single workspace
Title: Message Title Jacob Keller commented on JENKINS-27668 Re: Add support for multiple git repositories in a single workspace I suspect job definition would require re-work to support multiple SCMs. It's not un-doable but no one has put forth effort to work on it. I think it's best to be a core Jenkins feature, and get the review necessary to support the workflow. I don't think it's too far out there, and I think even changes could be handled properly that way. 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] (JENKINS-27668) Add support for multiple git repositories in a single workspace
Title: Message Title Jacob Keller commented on JENKINS-27668 Re: Add support for multiple git repositories in a single workspace I'm not saying it's the best or that it couldn't be improved, but it's what we have today that doesn't require more work. 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] (JENKINS-32481) git plugin does not retry when submodule update fails
Title: Message Title Jacob Keller commented on JENKINS-32481 Re: git plugin does not retry when submodule update fails Yea this didn't get pulled into 2.5 I believe. 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] (JENKINS-27668) Add support for multiple git repositories in a single workspace
Title: Message Title Jacob Keller commented on JENKINS-27668 Re: Add support for multiple git repositories in a single workspace You can use Multiple SCM plugin for this. Just be sure that you order the repositories so that the "most root" subdirectory is cloned first, otherwise Git plugin will erase the files due to how git-clone requires an empty directory. 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] (JENKINS-30318) Git plugin breaks usage of Git LFS due to lack of Git Clone use
Title: Message Title Jacob Keller commented on JENKINS-30318 Re: Git plugin breaks usage of Git LFS due to lack of Git Clone use Ok so I did some digging, and it is not feasible to return to a clone from an init+fetch, because of the various enhancements added to the clone command which are not feasible to remove (as that would be removing a feature that people may depend on). If one of the people here wishes to take the effort to add explicit git-lfs support, I will be happy to review it, but I don't have time myself to work on that patch. 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] (JENKINS-30318) Git plugin breaks usage of Git LFS due to lack of Git Clone use
Title: Message Title Jacob Keller commented on JENKINS-30318 Re: Git plugin breaks usage of Git LFS due to lack of Git Clone use I would rather focus on just getting things working, and someone who is actively interested in using LFS is free to submit patches that fix the performance issues and they can be reviewed. Unfortunately I do not have the time to do that myself. 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] (JENKINS-30318) Git plugin breaks usage of Git LFS due to lack of Git Clone use
Title: Message Title Jacob Keller commented on JENKINS-30318 Re: Git plugin breaks usage of Git LFS due to lack of Git Clone use The problem is we can't depend on git-lfs, and I'd rather not have a checkbox for it. Also as I am unfamiliar with git-lfs I am not aware of how and what needs to be added everywhere. It would be better if it worked seamless. Switching to use git-clone is easier, and likely fixes other possible issues with the init+fetch combo we have now. 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] (JENKINS-30318) Git plugin breaks usage of Git LFS due to lack of Git Clone use
Title: Message Title Jacob Keller commented on JENKINS-30318 Re: Git plugin breaks usage of Git LFS due to lack of Git Clone use I can take a look tomorrow and see what it would take to use clone instead of fetch+init like we are now. I think with recent changes it might be possible now. 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] [swarm-plugin] (JENKINS-20668) Persist Jenkins swarm slaves when they go offline
Title: Message Title Jacob Keller commented on JENKINS-20668 Re: Persist Jenkins swarm slaves when they go offline Another issue I have is similar. Say a slave is for some label "node" and goes offline. If no other slave has the label "node" then that label isn't remembered by the Jenkins system. Thus, when a job is edited and saved, it removes the label from the configuration permanently (as it doesn't exist according to the master). This happens for example with a matrix job. This is a problem if someone happens to edit a job during a window when a slave is offline, and results in a hidden loss of running on that slave in the matrix job builds. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [git-plugin] (JENKINS-32479) multiple git repositories sometimes fail to checkout some of them into subdirectory
Title: Message Title Jacob Keller commented on JENKINS-32479 Re: multiple git repositories sometimes fail to checkout some of them into subdirectory Can we get some input from developers of Git plugin and Multiple-SCM plugin? The issue stems from ordering of repositories since the Git Plugin's "clone" operation calls a full delete of the current workspace. I have a possible solution revolving around making the Git Plugin report its actual sub directory using the getModuleRoot() interface, and then having Multiple-SCM "sort"/"order" the repositories in such a way as to avoid checking out into a sub directory first. Another option would be for Multiple SCM to implement for itself "checkout to a sub directory" instead of relying on the plugins to do so themselves. I believe this would be preferred since it would be much more universal, and allow easier correct access since my fix requires both a change to the git plugin and the multiple SCM plugin. Finally it may be possible to not need to remove the working directory when implementing clone() in the Git plugin. However, this requires continued use of the init+fetch setup, which currently breaks other uses such as Git-LFS and should be returned back to clone. There does not appear to be a good way to make git-clone behave correctly and allow cloning into a non-empty directory. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [git-plugin] (JENKINS-32479) multiple git repositories sometimes fail to checkout some of them into subdirectory
Title: Message Title Jacob Keller assigned an issue to Craig Rodrigues Jenkins / JENKINS-32479 multiple git repositories sometimes fail to checkout some of them into subdirectory Change By: Jacob Keller Assignee: Craig Rodrigues Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [git-plugin] (JENKINS-32479) multiple git repositories sometimes fail to checkout some of them into subdirectory
Title: Message Title Jacob Keller assigned an issue to Unassigned Jenkins / JENKINS-32479 multiple git repositories sometimes fail to checkout some of them into subdirectory Change By: Jacob Keller Assignee: Jacob Keller Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [git-client-plugin] (JENKINS-30318) Git plugin breaks usage of Git LFS due to lack of Git Clone use
Title: Message Title Jacob Keller commented on JENKINS-30318 Re: Git plugin breaks usage of Git LFS due to lack of Git Clone use We can fix Git plugin, but there is an issue. The init+fetch workaround would allow us to avoid an issue with checking out into a non-empty directory (which currently we do a "wipe" of the workspace which breaks multiple-SCM plugin if the order of repositories is bad). However, I would propose going ahead with this fix, assuming the maintainer agrees. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [git-plugin] (JENKINS-32479) multiple git repositories sometimes fail to checkout some of them into subdirectory
Title: Message Title Jacob Keller commented on JENKINS-32479 Re: multiple git repositories sometimes fail to checkout some of them into subdirectory An alternative would be to implement getModuleRoots for the Git Plugin to return the actual root when Git is using the extension, and then order checkouts based on this. I am thinking this is simpler and will try to implement this. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [git-plugin] (JENKINS-32479) multiple git repositories sometimes fail to checkout some of them into subdirectory
Title: Message Title Jacob Keller assigned an issue to Jacob Keller Jenkins / JENKINS-32479 multiple git repositories sometimes fail to checkout some of them into subdirectory Change By: Jacob Keller Assignee: Jacob Keller Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [git-plugin] (JENKINS-32479) multiple git repositories sometimes fail to checkout some of them into subdirectory
Title: Message Title Jacob Keller commented on JENKINS-32479 Re: multiple git repositories sometimes fail to checkout some of them into subdirectory So the recursive delete call was originally added since "git clone" does not let you clone into a non-empty directory. The root of this problem is due to how MultiSCM orders its checkouts, and there is no (obvious) way to tell which repositories belong in which directories from within the MultiSCM plugin, as this is part of the Git plugin settings. In addition, we can't really depend on a specific ordering from within the MultiSCM plugin, and we can't reliably remove the restriction that the work space be empty. I believe the problem is that MultiSCM should be made aware of the "checkout to separate directory" option, and indeed should actually implement it itself, since it is a very common or obvious problem when using multiple repositories. That would avoid the issues here without having to remove the constraint (which probably affects other SCMs as well!) Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [git-plugin] (JENKINS-32479) multiple git repositories sometimes fail to checkout some of them into subdirectory
Title: Message Title Jacob Keller commented on JENKINS-32479 Re: multiple git repositories sometimes fail to checkout some of them into subdirectory I found the root cause of the issue is due to lines 453 in the Git-client plugin, it runs a recursive "delete workspace" command, and so entirely depending on the ordering of the repositories the Multiple SCM plugin will fail. I don't even think the options are necessary to use, since a checkout -f will overwrite any files to begin with, and the only other option is implementing our own "clean" setup which would be more expensive than just relying on the clean extension. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [git-plugin] (JENKINS-32479) multiple git repositories sometimes fail to checkout some of them into subdirectory
Title: Message Title Jacob Keller edited a comment on JENKINS-32479 Re: multiple git repositories sometimes fail to checkout some of them into subdirectory I found believe the root cause of the issue is due to using MultiSCM to checkout submodules that exist within how the repository. This causes the git commands to fail if it happens to handle the parent project first. I believe this is an issue that should be fixed from within git.An alternative work-around would be to extend the submodule support in Git plugin to enable handles clones, via " git init" + "git fetch" + "git checkout submodule to specific sha1sum " which causes it to accidentally remove the other repositories . I am asking on the git mailing list if investigating this is expected behavior and how best to fix it now . Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [git-plugin] (JENKINS-32479) multiple git repositories sometimes fail to checkout some of them into subdirectory
Title: Message Title Jacob Keller commented on JENKINS-32479 Re: multiple git repositories sometimes fail to checkout some of them into subdirectory I found the root cause of the issue is due to using MultiSCM to checkout submodules that exist within the repository. This causes the git commands to fail if it happens to handle the parent project first. I believe this is an issue that should be fixed from within git. An alternative work-around would be to extend the submodule support in Git plugin to enable "checkout submodule to specific sha1sum". I am asking on the git mailing list if this is expected behavior and how best to fix it. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [git-plugin] (JENKINS-32479) multiple git repositories sometimes fail to checkout some of them into subdirectory
Title: Message Title Jacob Keller commented on JENKINS-32479 Re: multiple git repositories sometimes fail to checkout some of them into subdirectory Any chance you happen to have a smaller recreation we could use for testing? I'd like to try and sort out exactly what's happening here, as it recently happened again. I believe it may only occur when a fresh clone is initiated. What version of Git command line are you using, and what version of Git and Multi SCM are you using? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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.
