[JIRA] [parameterized-trigger-plugin] (JENKINS-33671) all triggered downstream jobs blocked until all upstream jobs leave queue
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-33671 all triggered downstream jobs blocked until all upstream jobs leave queue Change By: John McCullough We have Jenkins 1.596.2 and 2.25 of the Parameterized Trigger plugin on a system with 1 master node and 6 slave nodes that use a single executor each. We have 14 services that are built as Maven jobs, and each has a post build action that uses the parameterized trigger option to call another job that performs calls which update an external system used in our deployment and test framework (see trigger-screenshot). I want a post build action, and not a post-build step so that the build will not fail due to trouble with the triggered job. The downstream job is configured to allow concurrent builds, which it does when it is not blocked. Also it is not configured to block on the upstream job (see config-screenshot).This works great when only one of these services is getting built. However when we are at peak activity, there can be check-ins coming in so frequently that for an extended period one of those services will always be queued up to build. Then we observe the issue shown in the queue-screenshot where all of the triggered build jobs are blocked until every instance of the upstream jobs have left the queue, only then the triggered jobs will then unblock. Note the upstream jobs can still be building, just not in queue. Note also that frequently all of the blocked jobs will report they are blocked by the same upstream job, however when the build they all use the correct parameters from the actual jobs that triggered each of them. Other times the hover tip info for the jobs does show the unique parameters for each triggered job while they are queued up.This has the unfortunate side effect of introducing a substantial delay between the completion of a new service build and updating the external system with metadata about the new build. A small delay there is not a problem, but it can be as large as an hour and that is a problem. We don't really want to have to create a stand-alone service to listen for these calls, but if Jenkins introduces too much of a delay we may have. I have tried using a post-build step instead of a post-build-action for the triggering of the downstream job and the same behavior was seen. Add Comment
[JIRA] [parameterized-trigger-plugin] (JENKINS-33671) all triggered downstream jobs blocked until all upstream jobs leave queue
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-33671 all triggered downstream jobs blocked until all upstream jobs leave queue Change By: John McCullough Attachment: config-screenshot.png 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] [parameterized-trigger-plugin] (JENKINS-33671) all triggered downstream jobs blocked until all upstream jobs leave queue
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-33671 all triggered downstream jobs blocked until all upstream jobs leave queue Change By: John McCullough Attachment: queue-screenshot.png 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] [parameterized-trigger-plugin] (JENKINS-33671) all triggered downstream jobs blocked until all upstream jobs leave queue
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-33671 all triggered downstream jobs blocked until all upstream jobs leave queue Change By: John McCullough Attachment: config-screenshot.png 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] [multijob-plugin] (JENKINS-23817) downstream jobs of multijob phase jobs are pending until multijob is done
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-23817 downstream jobs of multijob phase jobs are pending until multijob is done Change By: John McCullough Attachment: queue-screenshot.png 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] [multijob-plugin] (JENKINS-23817) downstream jobs of multijob phase jobs are pending until multijob is done
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-23817 downstream jobs of multijob phase jobs are pending until multijob is done Change By: John McCullough Comment: I see something very similar with our system. We have 14 services that are built as Maven jobs, and each has a post build action that uses the parameterized trigger option to call another job that performs calls which update an external system used in our deployment and test framework (see trigger-screenshot). I want a post build action, and not a post-build step so that the build will not fail due to trouble with the triggered job. The downstream job is configured to allow concurrent builds, which it does when it is not blocked. Also it is not configured to block on the upstream job.This works great when only one of these services is getting built. However when we are at peak activity, there can be check-ins coming in so frequently that for an extended period one of those services will always be queued up to build. Then we observe the issue shown in the queue-screenshot where all of the triggered build jobs are blocked until every instance of the upstream jobs have left the queue, only then the triggered jobs will then unblock. Note the upstream jobs can still be building, just not in queue. Note also that all of the blocked jobs report they are blocked by the same upstream job, however when the build they all use the correct parameters from the actual jobs that triggered each of them. This has the unfortunate side effect of introducing a substantial delay between the completion of a new service build and updating the external system with metadata about the new build. A small delay there is not a problem, but it can be as large as an hour and that is a problem. We don't really want to have to create a stand-alone service to listen for these calls, but if Jenkins introduces to much of a delay we may have. I have tried using a post-build step instead of a post-build-action and the same behavior was seen. Add Comment This message was sent by
[JIRA] [parameterized-trigger-plugin] (JENKINS-33671) all triggered downstream jobs blocked until all upstream jobs leave queue
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-33671 all triggered downstream jobs blocked until all upstream jobs leave queue Change By: John McCullough We have Jenkins 1.596.2 and 2.25 of the Parameterized Trigger plugin on a system with 1 master node and 6 slave nodes that use a single executor each. We have 14 services that are built as Maven jobs, and each has a post build action that uses the parameterized trigger option to call another job that performs calls which update an external system used in our deployment and test framework (see trigger-screenshot). I want a post build action, and not a post-build step so that the build will not fail due to trouble with the triggered job. The downstream job is configured to allow concurrent builds, which it does when it is not blocked. Also it is not configured to block on the upstream job (see config-screenshot).This works great when only one of these services is getting built. However when we are at peak activity, there can be check-ins coming in so frequently that for an extended period one of those services will always be queued up to build. Then we observe the issue shown in the queue-screenshot where all of the triggered build jobs are blocked until every instance of the upstream jobs have left the queue, only then the triggered jobs will then unblock. Note the upstream jobs can still be building, just not in queue. Note also that frequently all of the blocked jobs will report they are blocked by the same upstream job, however when the build they all use the correct parameters from the actual jobs that triggered each of them. Other times the hover tip info for the jobs does show the unique parameters for each triggered job while they are queued up. This has the unfortunate side effect of introducing a substantial delay between the completion of a new service build and updating the external system with metadata about the new build. A small delay there is not a problem, but it can be as large as an hour and that is a problem. We don't really want to have to create a stand-alone service to listen for these calls, but if Jenkins introduces to much of a delay we may have. I have tried using a post-build step instead of a post-build-action and the same behavior was seen. Add Comment
[JIRA] [parameterized-trigger-plugin] (JENKINS-33671) all triggered downstream jobs blocked until all upstream jobs leave queue
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-33671 all triggered downstream jobs blocked until all upstream jobs leave queue Change By: John McCullough Attachment: trigger-screenshot.png 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] [multijob-plugin] (JENKINS-23817) downstream jobs of multijob phase jobs are pending until multijob is done
Title: Message Title John McCullough commented on JENKINS-23817 Re: downstream jobs of multijob phase jobs are pending until multijob is done I see something very similar with our system. We have 14 services that are built as Maven jobs, and each has a post build action that uses the parameterized trigger option to call another job that performs calls which update an external system used in our deployment and test framework (see trigger-screenshot). I want a post build action, and not a post-build step so that the build will not fail due to trouble with the triggered job. This works great when only one of these services is getting built. However when we are at peak activity, there can be check-ins coming in so frequently that for an extended period one of those services will always be queued up to build. Then we observe the issue shown in the queue-screenshot where all of the triggered build jobs are blocked until every instance of the upstream jobs have left the queue, only then the triggered jobs will then unblock. Note the upstream jobs can still be building, just not in queue. Note also that all of the blocked jobs report they are blocked by the same upstream job, however when the build they all use the correct parameters from the actual jobs that triggered each of them. This has the unfortunate side effect of introducing a substantial delay between the completion of a new service build and updating the external system with metadata about the new build. A small delay there is not a problem, but it can be as large as an hour and that is a problem. We don't really want to have to create a stand-alone service to listen for these calls, but if Jenkins introduces to much of a delay we may have. I have tried using a post-build step instead of a post-build-action and the same behavior was seen. 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
[JIRA] [multijob-plugin] (JENKINS-23817) downstream jobs of multijob phase jobs are pending until multijob is done
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-23817 downstream jobs of multijob phase jobs are pending until multijob is done Change By: John McCullough Attachment: trigger-screenshot.png 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] [multijob-plugin] (JENKINS-23817) downstream jobs of multijob phase jobs are pending until multijob is done
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-23817 downstream jobs of multijob phase jobs are pending until multijob is done Change By: John McCullough Attachment: queue-screenshot.png 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] [parameterized-trigger-plugin] (JENKINS-33671) all triggered downstream jobs blocked until all upstream jobs leave queue
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-33671 all triggered downstream jobs blocked until all upstream jobs leave queue Change By: John McCullough We have Jenkins 1.596.2 and 2.25 of the Parameterized Trigger plugin on a system with 1 master node and 6 slave nodes that use a single executor each. We have 14 services that are built as Maven jobs, and each has a post build action that uses the parameterized trigger option to call another job that performs calls which update an external system used in our deployment and test framework (see trigger-screenshot). I want a post build action, and not a post-build step so that the build will not fail due to trouble with the triggered job. The downstream job is configured to allow concurrent builds, which it does when it is not blocked. Also it is not configured to block on the upstream job (see config-screenshot).This works great when only one of these services is getting built. However when we are at peak activity, there can be check-ins coming in so frequently that for an extended period one of those services will always be queued up to build. Then we observe the issue shown in the queue-screenshot where all of the triggered build jobs are blocked until every instance of the upstream jobs have left the queue, only then the triggered jobs will then unblock. Note the upstream jobs can still be building, just not in queue. Note also that frequently all of the blocked jobs will report they are blocked by the same upstream job, however when the build they all use the correct parameters from the actual jobs that triggered each of them. Other times the hover tip info for the jobs does show the unique parameters for each triggered job while they are queued up.This has the unfortunate side effect of introducing a substantial delay between the completion of a new service build and updating the external system with metadata about the new build. A small delay there is not a problem, but it can be as large as an hour and that is a problem. We don't really want to have to create a stand-alone service to listen for these calls, but if Jenkins introduces to too much of a delay we may have. I have tried using a post-build step instead of a post-build-action and the same behavior was seen. Add Comment
[JIRA] [parameterized-trigger-plugin] (JENKINS-33671) all triggered downstream jobs blocked until all upstream jobs leave queue
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-33671 all triggered downstream jobs blocked until all upstream jobs leave queue Change By: John McCullough I se something very similar with our system. We have Jenkins 1.596.2 and 2.25 of the Parameterized Trigger plugin on a system with 1 master node and 6 slave nodes that use a single executor each. We have 14 services that are built as Maven jobs, and each has a post build action that uses the parameterized trigger option to call another job that performs calls which update an external system used in our deployment and test framework (see trigger-screenshot). I want a post build action, and not a post-build step so that the build will not fail due to trouble with the triggered job. The downstream job is configured to allow concurrent builds, which it does when it is not blocked. Also it is not configured to block on the upstream job (see config-screenshot) .This works great when only one of these services is getting built. However when we are at peak activity, there can be check-ins coming in so frequently that for an extended period one of those services will always be queued up to build. Then we observe the issue shown in the queue-screenshot where all of the triggered build jobs are blocked until every instance of the upstream jobs have left the queue, only then the triggered jobs will then unblock. Note the upstream jobs can still be building, just not in queue. Note also that all of the blocked jobs report they are blocked by the same upstream job, however when the build they all use the correct parameters from the actual jobs that triggered each of them.This has the unfortunate side effect of introducing a substantial delay between the completion of a new service build and updating the external system with metadata about the new build. A small delay there is not a problem, but it can be as large as an hour and that is a problem. We don't really want to have to create a stand-alone service to listen for these calls, but if Jenkins introduces to much of a delay we may have. I have tried using a post-build step instead of a post-build-action and the same behavior was seen. Add Comment
[JIRA] [parameterized-trigger-plugin] (JENKINS-33671) all triggered downstream jobs blocked until all upstream jobs leave queue
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-33671 all triggered downstream jobs blocked until all upstream jobs leave queue Change By: John McCullough Attachment: config-screenshot.png 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] [parameterized-trigger-plugin] (JENKINS-33671) all triggered downstream jobs blocked until all upstream jobs leave queue
Title: Message Title John McCullough created an issue Jenkins / JENKINS-33671 all triggered downstream jobs blocked until all upstream jobs leave queue Issue Type: Bug Assignee: huybrechts Components: parameterized-trigger-plugin Created: 2016/Mar/19 1:09 AM Environment: Jenkins 1.596.2 and version 2.25 of the Parameterized Trigger plugin on CentOS release 6.6 (Final) LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch jdk 1.7.0_51 Priority: Major Reporter: John McCullough I se something very similar with our system. We have Jenkins 1.596.2 and 2.25 of the Parameterized Trigger plugin on a system with 1 master node and 6 slave nodes that use a single executor each. We have 14 services that are built as Maven jobs, and each has a post build action that uses the parameterized trigger option to call another job that performs calls which update an external system used in our deployment and test framework (see trigger-screenshot). I want a post build action, and not a post-build step so that the build will not fail due to trouble with the triggered job. The downstream job is configured to allow concurrent builds, which it does when it is not blocked. Also it is not configured to block on the upstream job. This works great when only one of
[JIRA] [multijob-plugin] (JENKINS-23817) downstream jobs of multijob phase jobs are pending until multijob is done
Title: Message Title John McCullough updated an issue Jenkins / JENKINS-23817 downstream jobs of multijob phase jobs are pending until multijob is done Change By: John McCullough Attachment: trigger-screenshot.png 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] [multijob-plugin] (JENKINS-23817) downstream jobs of multijob phase jobs are pending until multijob is done
Title: Message Title John McCullough edited a comment on JENKINS-23817 Re: downstream jobs of multijob phase jobs are pending until multijob is done I see something very similar with our system. We have 14 services that are built as Maven jobs, and each has a post build action that uses the parameterized trigger option to call another job that performs calls which update an external system used in our deployment and test framework (see trigger-screenshot). I want a post build action, and not a post-build step so that the build will not fail due to trouble with the triggered job. The downstream job is configured to allow concurrent builds, which it does when it is not blocked. Also it is not configured to block on the upstream job. This works great when only one of these services is getting built. However when we are at peak activity, there can be check-ins coming in so frequently that for an extended period one of those services will always be queued up to build. Then we observe the issue shown in the queue-screenshot where all of the triggered build jobs are blocked until every instance of the upstream jobs have left the queue, only then the triggered jobs will then unblock. Note the upstream jobs can still be building, just not in queue. Note also that all of the blocked jobs report they are blocked by the same upstream job, however when the build they all use the correct parameters from the actual jobs that triggered each of them. This has the unfortunate side effect of introducing a substantial delay between the completion of a new service build and updating the external system with metadata about the new build. A small delay there is not a problem, but it can be as large as an hour and that is a problem. We don't really want to have to create a stand-alone service to listen for these calls, but if Jenkins introduces to much of a delay we may have. I have tried using a post-build step instead of a post-build-action and the same behavior was seen. 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
[JIRA] [core] (JENKINS-18781) Configurable channel timeout for slaves
Title: Message Title John McCullough commented on JENKINS-18781 Re: Configurable channel timeout for slaves We also see this behavior periodicially in our system. Unfortunately for us we lose a lot of time and it is very disruptive of our release process when it occurs since the Windows slave nodes which show this problem are used to execute long-running tests. It would not be such a problem if it was just a short running module build job that can be readily retried. This seems like it would be really straightforward to add configurable values for this behavior and it would increase the value we get from Jenkins quite a lot. Please consider addressing this issue . Thanks, John 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] [artifactory-plugin] (JENKINS-12950) pom.xml not deploying to Artifactory
John McCullough commented on JENKINS-12950 pom.xml not deploying to Artifactory To avoid the chance of leftovers from previous builds getting deployed our jobs use a pre-build step to call a script to just delete the local maven repository on the build nodes. Easiest way to be sure. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
