[JIRA] [bitbucket-plugin] (JENKINS-28877) Bitbucket Plugin unable to parse Bitbucket webhook response json
Title: Message Title Kevin Phillips commented on JENKINS-28877 Re: Bitbucket Plugin unable to parse Bitbucket webhook response json I finally got some time to build the plugin from source using your proposed changes and it appears to work for us. If we could get those changes integrated into an official release of the plugin sooner rather than later that would be awesome. 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] [bitbucket-plugin] (JENKINS-28877) Bitbucket Plugin unable to parse Bitbucket webhook response json
Title: Message Title Kevin Phillips commented on JENKINS-28877 Re: Bitbucket Plugin unable to parse Bitbucket webhook response json Based on a quick review of the documentation for that plugin, I believe it may provide some of the functionality we are looking for - although maybe not everything. However, it appears that plugin only works with BitBucket cloud edition. I noticed several references to this within the literature. If you believe this to be incorrect do let me know and I will investigate further. Also, I did a quick search through the Jenkins update center and I don't see mention of this plugin anywhere. If you believe it would work with on-premises versions of BitBucket I'd also need some info on where to find it and how to build/install 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] [bitbucket-plugin] (JENKINS-28877) Bitbucket Plugin unable to parse Bitbucket webhook response json
Title: Message Title Kevin Phillips commented on JENKINS-28877 Re: Bitbucket Plugin unable to parse Bitbucket webhook response json I'm not very familiar with the internal workings of this plugin - is there sufficient information in my last comment to devise a fix for this? We are currently evaluating BitBucket on-premises and would really like see the integration with Jenkins working before finalizing our decision. If there is any information I could provide to help expedite the fix, just let me know. Also, as I had mentioned previously, anyone is free to download and run the BitBucket on-premises version for evaluation and testing purposes so you should be able to try that if there are specifics you'd like to investigate. 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] [bitbucket-plugin] (JENKINS-28877) Bitbucket Plugin unable to parse Bitbucket webhook response json
Title: Message Title Kevin Phillips commented on JENKINS-28877 Re: Bitbucket Plugin unable to parse Bitbucket webhook response json I see a pull request was made for this months ago, and the changes appear to have been integrated back in January, but from what I can tell there has been no release of this plugin since the fix was integrated. Given the fact it has been nearly 2 months since the fix has been made, shouldn't there be a new version of the plugin by now? Unless there is some reason not to, I'd appreciate it if someone could push a new version to the Jenkins plugin server sooner rather than later. Without this fix the plugin simply does not work with any recent version of Bitbucket, making it effectively useless. 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] [bitbucket-plugin] (JENKINS-28877) Bitbucket Plugin unable to parse Bitbucket webhook response json
Title: Message Title Kevin Phillips commented on JENKINS-28877 Re: Bitbucket Plugin unable to parse Bitbucket webhook response json I am running 1.596.3 of Jenkins core and have confirmed I have v1.1.5 of this plugin and this problem is still reproducible. I took another look at the pull request, and I think my earlier assessment may have been incorrect. The last comment on this issue was left on January 31st which lead me to believe the fix hadn't been integrated until that date, which was after v1.1.5 had been released - but that isn't the case. I will have to take a closer look at my local configuration, but it would appear the fix for this issue is not working as intended. In my case I'm using the latest version of Bitbucket Server (v4.4.1) in case that makes any difference. Perhaps I'm hitting a different problem, however the error message I am current seeing exactly matches the one included in the description above (ie: JSONObject["user"] not found) 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] [bitbucket-plugin] (JENKINS-28877) Bitbucket Plugin unable to parse Bitbucket webhook response json
Title: Message Title
Kevin Phillips commented on JENKINS-28877
Re: Bitbucket Plugin unable to parse Bitbucket webhook response json
Correct. However I believe they use the same application code for the cloud service that they provide for the on-premises version. Even if that is not the case you can actually download a free copy of the on-premises version from Atlassian's website for testing if necessary. It requires a free activation of course, but that's easy enough to get.
I have also confirmed that this is not a configuration problem on my end. I do have the latest version of the plugin. I restarted our Jenkins server just to be sure all of the components and plugins were up to date and installed correctly, and I am still getting this problem. Here is a more complete snippet from my Jenkins logs in case it helps (it looks like it has at least some of the package contents right there in the log):
Mar 18, 2016 1:14:48 PM com.cloudbees.jenkins.plugins.BitbucketPayloadProcessor processPostServicePayload
INFO: Received commit hook notification for {"slug":"pytools","id":2,"name":"pytools","scmId":"git","state":"AVAILABLE","statusMessage":"Available","forkable":true,"project":{"key":"DOT","id":4,"name":"DevOps Tools","description":"Projects related to DevOps team","public":true,"type":"NORMAL"},"public":true}
Mar 18, 2016 1:14:48 PM org.eclipse.jetty.util.log.JavaUtilLog warn
WARNING: Error while serving http://builds.caris.priv/bitbucket-hook/
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)
at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96)
at org.kohsuke.stapler.MetaClass$2.dispatch(MetaClass.java:165)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:391)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649)
at org.kohsuke.stapler.Stapler.service(Stapler.java:238)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:198)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:176)
at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:85)
at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:99)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:95)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at
[JIRA] [publish-over-cifs-plugin] (JENKINS-32962) CIFS publisher doesn't provide links to artifacts
Title: Message Title Kevin Phillips updated an issue Jenkins / JENKINS-32962 CIFS publisher doesn't provide links to artifacts Providing a screen shot of what the artifact links look like when using the built in artifact manager plugin in Jenkins. Ideally the CIFS plugin would mirror this behavior. Change By: Kevin Phillips Attachment: sample_artifacts_links.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] [publish-over-cifs-plugin] (JENKINS-32962) CIFS publisher doesn't provide links to artifacts
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-32962 CIFS publisher doesn't provide links to artifacts Issue Type: Improvement Assignee: bap Components: publish-over-cifs-plugin Created: 15/Feb/16 7:31 PM Priority: Major Reporter: Kevin Phillips Most if not all of the artifact publisher plugins for Jenkins provide links directly on the dashboard pointing to the artifacts that were published. All, except for the CIFS publisher that is. This inconsistency makes it hard for people to interact with artifacts via the Jenkins dashboard as there is no easy correlation between artifacts found on a network share and the CI job that created them. This should be fixed sooner rather than later. Add Comment
[JIRA] [publish-over-cifs-plugin] (JENKINS-32961) Artifacts published with cifs publisher aren't deleted when the build gets deleted
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-32961 Artifacts published with cifs publisher aren't deleted when the build gets deleted Issue Type: Bug Assignee: bap Components: publish-over-cifs-plugin Created: 15/Feb/16 7:16 PM Priority: Major Reporter: Kevin Phillips While testing the CIFS publisher plugin I noticed that artifacts published using this plugin are not deleted when the associated jobs is deleted. This is frustrating at best and causes deployed artifacts to become orphaned consuming unnecessary storage space in the target share. This should be fixed. Add Comment
[JIRA] [publish-over-cifs-plugin] (JENKINS-16741) [X] Found zero files marks build as unstable
Title: Message Title Kevin Phillips commented on JENKINS-16741 Re: [X] Found zero files marks build as unstable I also have to say that it is somewhat troubling that this seemingly trivial change request has been outstanding for several years now without resolution. Is this plugin even being maintained any more? 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] [publish-over-cifs-plugin] (JENKINS-16741) [X] Found zero files marks build as unstable
Title: Message Title Kevin Phillips commented on JENKINS-16741 Re: [X] Found zero files marks build as unstable I just recently tried this plugin as a potential replacement for the Artifact Deployer plugin which is fraught with bugs, but I immediately noticed that the builds do not fail when there are no files to deploy, which could mean some breaking change in the build configuration or a misconfiguration in the job itself. Either way, treating the case of uploading 0 files as anything other than an error seems odd to me. At least the Artifact Deployer plugin provides an option to treat this case as an error if desired. 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] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips commented on JENKINS-32275 Re: Flexible publish plugin doesn't always instantiate correct child plugin All attempts to reproduce the "random" behavior I had originally experienced when reporting this defect have failed. I suspect the problem the entire time is that sometimes our users would be selecting the first action name from the list of actions while other times they were selecting the second instance. Since the action names are identical there was no easy / obvious way to tell them apart. In our case we have a large number of plugins installed so the duplicate action names were separated from one another by dozens of other actions so the duplication was not easily noticed making the behavior "seem" random. I would be content having this defect resolved and I have created a separate improvement request to find some way to disambiguate duplicate entries in the actions list when using the any-buildstep-plugin. See JENKINS-32550 for details. Thanks ikedam for your prompt replies and assistance with debugging this problem with me. It is greatly appreciated. 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] [any-buildstep-plugin] (JENKINS-32550) Ambiguous actions in list of available actions
Title: Message Title Kevin Phillips commented on JENKINS-32550 Re: Ambiguous actions in list of available actions Linked this improvement to the original defect that lead me to discover this very difficult to detect ambiguity. See the comment thread and screen shots attached to that defect for examples and details of the kinds of confusion this has caused us. 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] [any-buildstep-plugin] (JENKINS-32550) Ambiguous actions in list of available actions
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-32550 Ambiguous actions in list of available actions Issue Type: Improvement Assignee: bap Components: any-buildstep-plugin Created: 21/Jan/16 1:29 PM Priority: Minor Reporter: Kevin Phillips Over the past several months we had been dealing with what believed was a defect with several of our Jenkins plugins where by actions instantiated under a Flexible Publish post-build step were showing different options seemingly randomly (JENKINS-32275). It turns out that the root cause of our difficulties the entire time was our unawareness that when the any-build-step plugin is installed and enabled any plugins that support both build and post-build operations get listed twice in the available actions for the Flexible Publish and that both instances have the exact same action names making them indistinguishable. Here is an example use case of what I am talking about: setup a clean copy of Jenkins (we use v1.596.3) install the any-build-step plugin (v0.1) which should also install the Flexible Publish plugin (v0.15.2) among several others install a plugin that supports both build and post-build operations. With our
[JIRA] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips commented on JENKINS-32275 Re: Flexible publish plugin doesn't always instantiate correct child plugin The problem you point is You can't add more than two "set build description" of post build step. Right? Actually no. The original problem was that sometimes adding one of these actions as a post-build step resulted in the "Advanced" button being enabled while other times it was not. I can't get what you want to explain with post_build_actions.png. Any-build-step only affects the behavior of flexible-publish (and conditional-buildstep) and never affects "Add post-build action" of projects. I think therein lies some of my confusion. I thought the any-build-step plugin worked on arbitrary build / post-build steps. I hadn't realized that it only applies to flexible-publish and conditional-buildstep. I will limit subsequent testing to just those to areas. Also, given this fact I think the second point for confusion that I hadn't realized until yesterday was that in this case plugins such as set-build-description show up twice in the list of available actions - one representing a build step and one representing a post-build step - each of which present different options in the UI. I suspect that part of my problem in reporting this bug is that during testing I would occasionally click the former while other times I'd click the latter without realizing it. At least one improvement that could be made to the UI to avoid confusion would be to append / prepend some kind of indicator to distinguish duplicate action names like this. Maybe the any-build-step plugin could be enhanced such that if it detects two actions with the same name it could put a "(build)" or "(post-build)" label in front of the action name to avoid the ambiguity. That being said, when I was ad-hoc testing yesterday in my clean Jenkins environment I could have sworn that I managed to reproduce the behavior of the actions being created as build and post-build versions at random. I will do a bit more ad-hoc testing this morning to try and find a reproducible use case. If I can not find one I think it would be safe to say that this defect was actually attributed to human error caused by ambiguous duplication of action names, in which case enhancing the any-build-step plugin like what I suggested above could be a reasonable solution to this problem. Add Comment
[JIRA] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title
Kevin Phillips edited a comment on JENKINS-32275
Re: Flexible publish plugin doesn't always instantiate correct child plugin
{quote}The problem you point is* You can't add more than two "set build description" of post build step. * Right?{quote}Actually no. The original problem was that sometimes adding one of these actions as a post-build step resulted in the "Advanced" button being enabled while other times it was not.{quote}I can't get what you want to explain with post_build_actions.png.Any-build-step only affects the behavior of flexible-publish (and conditional-buildstep) and never affects "Add post-build action" of projects.{quote}I think therein lies some of my confusion. I thought the any-build-step plugin worked on arbitrary build / post-build steps. I hadn't realized that it only applies to flexible-publish and conditional-buildstep. I will limit subsequent testing to just those to areas.Also, given this fact I think the second point for confusion that I hadn't realized until yesterday was that in this case plugins such as set-build-description show up twice in the list of available actions - one representing a build step and one representing a post-build step - each of which present different options in the UI. I suspect that part of my problem in reporting this bug is that during testing I would occasionally click the former while other times I'd click the latter without realizing it.At least one improvement that could be made to the UI to avoid confusion would be to append / prepend some kind of indicator to distinguish duplicate action names like this. Maybe the any-build-step plugin could be enhanced such that if it detects two actions with the same name it could put a "(build)" or "(post-build)" label in front of the action name to avoid the ambiguity.That being said, when I was ad-hoc testing yesterday in my clean Jenkins environment I could have sworn that I managed to reproduce the behavior of the actions being created as build and post-build versions at random. I will do a bit more ad-hoc testing this morning to try and find a reproducible use case. If I can not find one I think it would be safe to say that this defect was actually attributed to human error caused by ambiguous duplication of action names, in which case enhancing the any-build-step plugin like what I suggested above could be a reasonable solution to this problem.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title
Kevin Phillips edited a comment on JENKINS-32275
Re: Flexible publish plugin doesn't always instantiate correct child plugin
{quote}The problem you point is* You can't add more than two "set build description" of post build step. * Right?{quote}Actually no. The original problem was that sometimes adding one of these actions as a post-build step resulted in the "Advanced" button being enabled while other times it was not.{quote}I can't get what you want to explain with post_build_actions.png.Any-build-step only affects the behavior of flexible-publish (and conditional-buildstep) and never affects "Add post-build action" of projects.{quote}I think therein lies some of my confusion. I thought the any-build-step plugin worked on arbitrary build / post-build steps. I hadn't realized that it only applies to flexible-publish and conditional-buildstep. I will limit subsequent testing to just those to areas.Also, given this fact I think the second point for confusion that I hadn't realized until yesterday was that in this case plugins such as set-build-description show up twice in the list of available actions - one representing a build step and one representing a post-build step - each of which present different options in the UI. I suspect that part of my problem in reporting this bug is that during testing I would occasionally click the former while other times I'd click the latter without realizing it.At least one improvement that could be made to the UI to avoid confusion would be to append / prepend some kind of indicator to distinguish duplicate action names like this. Maybe the any-build-step plugin could be enhanced such that if it detects two actions with the same name it could put a "(build)" or "(post-build)" label in front of the action name to avoid the ambiguity.That being said, when I was ad-hoc testing yesterday in my clean Jenkins environment I could have sworn that I managed to reproduce the behavior of the actions being created as build and post-build versions at random. I will do a bit more ad-hoc testing this morning to try and find a reproducible use case. If I can not find one I think it would be safe to say that this defect was actually attributed to human error caused by ambiguous duplication of action names, in which case enhancing the any-build-step plugin like what I suggested above could be a reasonable solution to this problem.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [any-buildstep-plugin] (JENKINS-32550) Ambiguous actions in list of available actions
Title: Message Title Kevin Phillips commented on JENKINS-32550 Re: Ambiguous actions in list of available actions NOTE: Given that the any-buildstep-plugin extends both the Flexible Publish and Conditional Build Step plugins, the same behavior is likely reproducible with the latter plugin as well, but I have not taken the time to confirm. 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] [any-buildstep-plugin] (JENKINS-32550) Ambiguous actions in list of available actions
Title: Message Title Kevin Phillips updated an issue Jenkins / JENKINS-32550 Ambiguous actions in list of available actions Attached a screen shot that illustrates the duplication I am looking to disambiguate here. Change By: Kevin Phillips Attachment: duplicate_actions_example.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] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips commented on JENKINS-32275 Re: Flexible publish plugin doesn't always instantiate correct child plugin Sorry for the wait. I've managed to setup a clean test environment with a clean instance of Jenkins 1.596.3 to try and reproduce this problem. It would appear that the behavior I'm seeing on our production server is slightly different than the behavior that I'm now seeing in this clean test environment, however the underlying problem is still reproducible. In fact, the behavior in the clean environment is inconsistent as well (to be explained later). Here is what I believe to be a minimum set of steps that are needed to reliably reproduce the problem: launch a clean environment for Jenkins 1.596.3 Install the description setter plugin (v1.10) Install the Flexible Publish plugin (v0.15.2) Install the Any Build Step plugin (v0.1) Under the Manage Jenkins -> Configure System panel locate the newly added "Flexible Publish" section Select the "Any build step" from the dropdown list next to the "Allowed build steps" option Save your changes Create a new job / project of type "Freestyle project" Under the Post-build actions, add a new "Set build description action" Next add a new Flexible Publish action also under the post-build section Add a conditional action of type "Set build description" to the Flexible Publish Add a second conditional action of type "Set build description" in the same area as the previous one Add an additional conditional action block to the Flexible Publish action by clicking the "Add conditional action" button beneath the first section Add one more conditional action of type "Set build description" to this newly added conditional section
[JIRA] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips commented on JENKINS-32275 Re: Flexible publish plugin doesn't always instantiate correct child plugin And now the plot thickens. As another test case I decided to customize the "Conditional buildstep" options which are installed as part of the build any plugin and discovered something interesting - there are now two instances of the "set build description" action in the drop down list for the flexible publisher. Here are the exact steps to reproduce: launch clean instance of Jenkins with the 3 plugins mentioned in my previous comment Go to the Manage Jenkins -> Configure System panel and find the "Conditional buildstep" section Under the "Allowed build steps" option select "Any build step" from the drop down menu Also under the "Configure System" panel locate the "Flexible publish" section Under the "Allowed build steps" option select "Any build step" from the drop down menu here as well Click save Create a new job / project of type "Freestyle project" Under Post-build actions, add a new "Flexible publish" action Click the "Add" button under the Flexible Publish action to expose the list of supported sub-actions. If you review the list carefully you'll see there are two entries for "set build description" (see attached screenshot) Based on my ad-hoc tests, one of these entries inserts a "build" action while the other inserts a "post-build" action, the latter of which exposes "Advanced" options for customizing the behavior based on the status of the build operation. Unfortunately there is no way to distinguish which is which based on the name alone. I have confirmed that we do have similar behavior on our production servers as well, which may partially explain away the behavior we are seeing. However I believe the underlying problem gets exacerbated when you only have one of the two "Allowed build steps" set to "Any build step". In those cases it appears as though there is only one "set build description" element presented in the list of actions, and sometimes it instantiates a "build" action while other times it instantiates a "post-build" action. Again, the behavior there seems somewhat random based on my preliminary ad-hoc tests.
[JIRA] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips updated an issue Jenkins / JENKINS-32275 Flexible publish plugin doesn't always instantiate correct child plugin Change By: Kevin Phillips Attachment: duplicate_actions_example.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] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips updated an issue Jenkins / JENKINS-32275 Flexible publish plugin doesn't always instantiate correct child plugin Change By: Kevin Phillips Attachment: build_vs_postbuild_options.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] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips updated an issue Jenkins / JENKINS-32275 Flexible publish plugin doesn't always instantiate correct child plugin Change By: Kevin Phillips Attachment: post_build_actions.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] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips commented on JENKINS-32275 Re: Flexible publish plugin doesn't always instantiate correct child plugin I thought I may as well add some more info based on my latest ad-hoc tests that may help further isolate this problem: the bug doesn't seem to be reproducible when only using the Flexible Publish plugin alone, so it seems likely the Any Build Step plugin may be to blame it would appear that when adding a build step of type "set build description" there are no "Advanced" options for customizing the behavior of the action based on the build status (which makes sense to me) it would appear that when adding a post-build step of type "set build description" there is an "Advanced" options area to customize the behavior based on the status of the build operation. This fact, combined with the previous one, should help distinguish which format of the plugin is being used at any given time. it would appear that the "build" action of type "set build description" allows one to instantiate multiple copies of itself as independent build operations, however "post-build" actions of type "set build description" limit themselves to just a single instance per project. There is one exception to this rule: when adding a conditional build step under a Flexible Publish action of type "set build description", you are able to add multiple instances of the action as desired. Perhaps this slight change in behavior may explain why sometimes we get one type of action over another (ie: after the first post-build action gets instantiated maybe subsequent ones are forced to be build actions instead ... although this behavior was inconsistent at best in my trials) Add Comment
[JIRA] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips commented on JENKINS-32275 Re: Flexible publish plugin doesn't always instantiate correct child plugin FYI: For kicks I took a quick look through our production system to see if there were duplication references to the Artifact Deployer actions as well, and there are! This would seem to suggest that at least part of the problem we have been experiencing is a result of duplicate entries with the exact same names showing up in the list of available actions, but only under certain specific conditions / circumstances. 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] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips commented on JENKINS-32275 Re: Flexible publish plugin doesn't always instantiate correct child plugin Yes, we do indeed have the any-build-step plugin installed so it is totally possible that is the culprit here. As for a screen shot of the set build description plugin, I assume you are looking for an example of what the set build description plugin looks like when not used in conjunction with the conditional publisher. I'll attach screen shots of that here shortly. As for testing the behavior in a clean Jenkins install, that would require slightly more effort but I'll see what I can do. 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] [exclusion-plugin] (JENKINS-32367) Exclusion list doesn't get updated when resources are removed
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-32367 Exclusion list doesn't get updated when resources are removed Issue Type: Bug Assignee: Unassigned Components: exclusion-plugin Created: 08/Jan/16 4:51 PM Environment: Windows, Jenkins LTS 1.596.3, Exclusion Plugin v0.10 Priority: Minor Reporter: Kevin Phillips It would appear that when one adds a new "resource" to a job, the list of available resources under the Exclusion Administration panel gets updated to include the new resource. However, when a resource is removed from a job this list is not updated resulting in superfluous entries in the table. This is confusing at best and can lead to erroneous assumptions regarding which jobs are using which resources. Steps to reproduce: 1. Add a new resource to a job 2. confirm the new resource appears in the Exclusion Administration panel 3. Edit the job once again and remove the resource added in step 1 4. check the list of resources reported under the Exclusion Administration panel. Result: the resource still appears in the list, associated with the sample job even though it is no longer used.
[JIRA] [throttle-concurrent-builds-plugin] (JENKINS-32334) Add option to throttle one job against a group of jobs
Title: Message Title Kevin Phillips updated an issue Jenkins / JENKINS-32334 Add option to throttle one job against a group of jobs Change By: Kevin Phillips We have recently added some new jobs to our Jenkins instance which are scheduled to run periodically to shut down some virtual machines used by some of our automated tests, restore the VMs back to a clean snapshot, and bring the VMs back online. During this process we want to prevent any unit tests that need said VMs from running since they would simply fail because the services they need would be offline.Currently our solution has been to setup a throttled build category, assign that category to every job that requires those VMs as well as the jobs that perform the automated maintenance, setting the category such that only one of the jobs therein may run anywhere on our build farm at a time. So if a unit test is currently using one of the VMs when the maintenance job kicks in, the latter will wait until the test completes before performing the cleanup. Conversely, if the cleanup job is running when a unit test triggers that depends on the target VM it will block until the cleanup is complete ensuring all necessary services are online before running the tests.This works fine as described however the problem we have is that the unit test jobs that make use of these VMs may run in parallel to one another since the tests themselves are independent from on another. Using the throttling plugin as described not only prevents the tests from running while the cleanup operation is running but it also prevents the tests from running side-by-side themselves.Now, on the one hand we probably could use the build blocker plugin to configure our unit test jobs such that they won't run while the cleanup operation is running, but using this plugin for the inverse case is cumbersome at best. Suppose we have 10 unit test jobs using a VM, and 1 job which manages the cleanup of the VM. All 10 test jobs can easily be set up to not run when the single cleanup job is running but making sure that all the relevant CI jobs are included in the cleanup job so they don't run in parallel is problematic at best. As new jobs are added, jobs renamed, etc. we would have to remember to constantly keep the cleanup job up to date. As human error always rears it's ugly head sooner or later someone will forget to do so which could result in intermittent, difficult to debug test failures - something we try to avoid.Ideally what I'd like to see is some option which would allow us to put all of our unit test jobs into a category and then have that entire group of jobs able to run in parallel but all of them block on the VM cleanup job and vice versa. Then all we'd need to do is ensure all jobs that make use of a particular VM be placed in the correct category and Jenkins could then sort out the rest automatically, similar to the way the throttling plugin currently works.To make the solution a bit more generic, maybe the throttling plugin could be extended such that "groups" of jobs could be defined, and then any jobs in group #1 will block when any jobs from group #2 are running and vice versa, but jobs within the same group are left free to run in parallel. Then we could add all of our unit test jobs to group 1, and then put just the
[JIRA] [throttle-concurrent-builds-plugin] (JENKINS-32334) Add option to throttle one job against a category
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-32334 Add option to throttle one job against a category Issue Type: New Feature Assignee: Oleg Nenashev Components: throttle-concurrent-builds-plugin Created: 07/Jan/16 2:57 PM Priority: Minor Reporter: Kevin Phillips We have recently added some new jobs to our Jenkins instance which are scheduled to run periodically to shut down some virtual machines used by some of our automated tests, restore the VMs back to a clean snapshot, and bring the VMs back online. During this process we want to prevent any unit tests that need said VMs from running since they would simply fail because the services they need would be offline. Currently our solution has been to setup a throttled build category, assign that category to every job that requires those VMs as well as the jobs that perform the automated maintenance, setting the category such that only one of the jobs therein may run anywhere on our build farm at a time. So if a unit test is currently using one of the VMs when the maintenance job kicks in, the latter will wait until the test completes before performing the cleanup. Conversely, if the cleanup job is running when a unit test triggers that depends on the target VM it will block until the cleanup is complete ensuring all necessary services are online before running the tests. This works fine as described however the problem we have is that the unit test jobs that make use of these VMs may run in parallel to one another since the tests themselves are independent from on another. Using the throttling plugin as described not only prevents the tests from
[JIRA] [throttle-concurrent-builds-plugin] (JENKINS-32334) Add option to throttle one job against a group of jobs
Title: Message Title Kevin Phillips commented on JENKINS-32334 Re: Add option to throttle one job against a group of jobs I probably should mention that if anyone can find some easy-to-maintain way of telling one job to block when a set of other jobs are running, assuming that the build blocker plugin is not sufficient due to inconsistencies in naming conventions and such, feel free to offer suggestions. 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] [throttle-concurrent-builds-plugin] (JENKINS-32337) Add ability to throttle a subset of a build
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-32337 Add ability to throttle a subset of a build Issue Type: New Feature Assignee: Oleg Nenashev Components: throttle-concurrent-builds-plugin Created: 07/Jan/16 4:11 PM Priority: Minor Reporter: Kevin Phillips Lately we have been using several different Jenkins plugins to control the execution of a diverse set of jobs, some of which may not be run in parallel to others, one of which being the throttle builds plugin. One limitation of the throttling plugin is that it applies to the entire job, making it impossible to throttle a subset of the operations performed with a larger, more complex job. For example, lets suppose you have a job that builds some code, runs some operations on the build, runs some unit tests against it, generates a package, and publishes the results somewhere. Further, lets suppose that some of the unit tests that job runs can not be run in parallel with other unit tests on the system. It would be nice to be able to have a build launch and run some of the initial processes in parallel to other processes on the system, but then when it comes time to execute the unit tests to then apply the throttling logic as it would normally be applied, releasing the lock once the tests are complete. I probably should point out that this behavior is provided exactly as described by the "exclusion" plugin, which we are currently using. However, the problem is that sometimes we'd like entire jobs to be excluded from a build until a locked resource is available while other times we'd like only part of a job to be blocked when a locked resource is
[JIRA] [exclusion-plugin] (JENKINS-32342) Add option to select exclusion resource to critical section
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-32342 Add option to select exclusion resource to critical section Issue Type: New Feature Assignee: Unassigned Components: exclusion-plugin Created: 07/Jan/16 5:13 PM Priority: Minor Reporter: Kevin Phillips Currently the exclusion plugin allows one to define multiple "exclusion resources" to any particular job. However, when adding the critical section start/end steps to the build process there is currently no way to indicate which of these exclusion resources each critical section should use. For example, suppose you have two exclusion resources, say "resource A" and "resource B". Now, suppose you have two separate operations in your build sequence, the first of which needs to be excluded when resource A is locked and the second of which needs to be excluded when resource B is locked. From what I can tell this is currently not possible. As such what I'd like to see is some additional configuration options provided to the "critical block start" and "critical block end" build steps allowing the user to select which of the exclusion resources each block is associated with. To preserve backwards compatibility you could associate each critical block with all configured exclusion resources by default but then allow the user to customize the selection as desired.
[JIRA] [exclusion-plugin] (JENKINS-32344) Provide feature for defining exclusion resources globally
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-32344 Provide feature for defining exclusion resources globally Issue Type: New Feature Assignee: Unassigned Components: exclusion-plugin Created: 07/Jan/16 5:17 PM Priority: Minor Reporter: Kevin Phillips Currently the exclusion plugin forces each job to define which exclusion resources it wants to define and use. This can be problematic when multiple jobs want to make use of the same exclusion resources because the user has to take care to add the same exclusion resource to all relevant jobs (duplication), and to try and avoid human error like typos and the like which could result in new exclusion resources being created inadvertently. What I would prefer to see is if the exclusion plugin provided some configuration options in the global Jenkins configuration area which would allow one to define their exclusion resources globally, and then perhaps provide a drop-down list of available exclusions when configuring each job. This would avoid the duplication and human errors just described.
[JIRA] [exclusive-execution-plugin] (JENKINS-32345) Add option to restrict job to a specific agent
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-32345 Add option to restrict job to a specific agent Issue Type: New Feature Assignee: Marco Ambu Components: exclusive-execution-plugin Created: 07/Jan/16 6:21 PM Priority: Minor Reporter: Kevin Phillips Currently the exclusive execution plugin assumes that the associated job must have exclusive access to the entire build farm managed by the Jenkins master. While this is handy in many cases, it would be nice if this plugin provided an option to limit the restriction to a single build agent. The use case I am thinking of is when you want to run a job that requires complete access to the target build agent without compromising any currently running builds, like if the job is to perform some kind of cleanup or maintenance on the target agent. In these cases it would be nice if the plugin could simply mark the specified agent as being temporarily offline rather than setting the entire master to quiet down mode, and then to halt execution until all of the executors on the one target agent are idle before continuing with the job. I was thinking that having some kind of drop-down list in the plugin configuration under the "Set exclusive execution" area of a jobs build environment options. By default the option could be set to "all" to mimic the current behavior and thus preserve backwards compatibility, but then would provide the user the ability to select one specific agent from the drop down list to isolate / target the scope of the exclusivity.
[JIRA] [zentimestamp-plugin] (JENKINS-32271) ZenTimestamp plugin appears to confuse certain dates
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-32271 ZenTimestamp plugin appears to confuse certain dates Issue Type: Bug Assignee: Gregory Boissinot Components: zentimestamp-plugin Created: 04/Jan/16 2:02 PM Environment: Windows, Jenkins LTS 1.596.3, ZenTimestamp 3.3 Priority: Major Reporter: Kevin Phillips We just encountered a very strange bug with the ZenTimestamp plugin. All of our builds from December 29th, 30th, and 31st in 2015 were all labelled with the incorrect year in the date component. For some reason all said builds claim the year to be 2016 instead of 2015! Builds after the new year do appear to be correct, so perhaps this is an isolated problem, but this does not build confidence in the plugin. I'd strongly urge the maintainers to review the implementation to confirm that this is not some pervading issue in the implementation that could cause incorrect date / time stamps to be generated again in the future. For reference, our Jenkins instance is configured to use the following build ID format string: "-MM-dd_HH-mm-ss". This pattern is set in the global Jenkins configuration and is not overridden in any of our affected CI jobs, and all builds from the 3 days mentioned, starting at midnight on December 29th appear to have been affected.
[JIRA] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips edited a comment on JENKINS-32275 Re: Flexible publish plugin doesn't always instantiate correct child plugin I probably should mention that if you 'hack' the config.xml for the job, replacing the instance of hudson.plugins.descriptionsetter.DescriptionSetterBuilder with hudson.plugins.descriptionsetter.DescriptionSetterPublisher the Jenkins UI does reflect the change and expose the "Advanced..." configuration button as one would expect. Further, after doing so you are able to modify these advanced settings directly from the Jenkins UI. This suggests that the Flexible Publish plugin does correctly load the configuration and is able to interact with the child plugin correctly, so this looks like this problem might be related to the initial instantiation of the child plugins after the first. 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] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-32275 Flexible publish plugin doesn't always instantiate correct child plugin Issue Type: Bug Assignee: bap Attachments: sample.png Components: flexible-publish-plugin Created: 04/Jan/16 3:53 PM Environment: Windows, Jenkins LTS 1.596.3. Flexible Publish 0.15.2 Priority: Major Reporter: Kevin Phillips I have discovered that some plugins provide inconsistent behavior with the flexible publish plugin and have isolated a specific use case that may be helpful for debugging and discussion. (Keep in mind that I have very little knowledge of the internal workings of Jenkins, so take some of my technical assumptions below within that context) Problem Using the flexible publish plugin to conditionally set the "Description" of a build using the Description Setter plugin seems to work correctly so long as you provide a single conditional operation to the flexible publish plugin, but when more conditional
[JIRA] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips commented on JENKINS-32275 Re: Flexible publish plugin doesn't always instantiate correct child plugin I probably should mention that if you 'hack' the config.xml for the job, replacing the instance of hudson.plugins.descriptionsetter.DescriptionSetterBuilder with hudson.plugins.descriptionsetter.DescriptionSetterPublisher the Jenkins UI does reflect the change and expose the "Advanced..." configuration button as one would expect. 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] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title
Kevin Phillips updated an issue
Jenkins / JENKINS-32275
Flexible publish plugin doesn't always instantiate correct child plugin
Change By:
Kevin Phillips
I have discovered that some plugins provide inconsistent behavior with the flexible publish plugin and have isolated a specific use case that may be helpful for debugging and discussion. (Keep in mind that I have very little knowledge of the internal workings of Jenkins, so take some of my technical assumptions below within that context)*Problem*Using the flexible publish plugin to conditionally set the "Description" of a build using the Description Setter plugin seems to work correctly so long as you provide a single conditional operation to the flexible publish plugin, but when more conditional actions are added subsequent instances of the description setter plugin do not expose all of their available options on the Jenkins UI. In this example case, the first instance exposes an "Advanced..." button allowing the customization of extra parameters not presented in the default list of options, where as subsequent instances do not provide such a button. See the attached sample.png for a visual.Closer examination of the XML generated by the Jenkins UI reveals that the Flexible Publish plugin is making reference to two different Jenkins plugins / classes for these divergent instances. In this example, the first instance of the Description Setter action is using a "DescriptionSetterPublisher" object, where as all subsequent instances are using a "DescriptionSetterBuilder" object, which may help shed some light on the problem. Below is a snippet from the config.xml for the job configuration presented in the attached screenshot:{code}${IS_CLEAN_BUILD}OracleVersion: ${OracleVersion}OracleVersion: ${OracleVersion}false${IS_CLEAN_BUILD}OracleVersion: both
[JIRA] [flexible-publish-plugin] (JENKINS-32275) Flexible publish plugin doesn't always instantiate correct child plugin
Title: Message Title Kevin Phillips commented on JENKINS-32275 Re: Flexible publish plugin doesn't always instantiate correct child plugin One of the other plugins we have recently exploited this same problem with is the Artifact Deployer plugin. In that case, the Flexible Publisher instantiates the org.jenkinsci.plugins.artifactdeployer.ArtifactDeployerBuilder class instead of the more appropriate org.jenkinsci.plugins.artifactdeployer.ArtifactDeployerPublisher class. 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] [vsphere-cloud-plugin] (JENKINS-31942) Add option to restore latest snapshot
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-31942 Add option to restore latest snapshot Issue Type: New Feature Assignee: Unassigned Components: vsphere-cloud-plugin Created: 07/Dec/15 2:53 PM Priority: Minor Reporter: Kevin Phillips I couldn't help but notice the vSphere cloud plugin has options for restoring snapshots as a build operation, but this feature only works with named snapshots at the moment. I'd like to see this functionality enhanced such that one could restore a VM back to the "last" snapshot (ie: the one used to launch the current instance of the VM). The vSphere client and all other vSphere tools have this option, so I suspect there must be a remote API call exposing this exact behavior. That being the case I'd hope it would be a trivial amount of work to implement this feature. NOTE: The rationale for this request is, we'd like to have VM cleanup logic done automatically as part of our Jenkins jobs, which would essentially shut down a running VM, restore it back to the 'last' snapshot, then restart it, thus ensuring CI operations that use the VM always start in a consistent state. Further, as the number of VMs increases it becomes difficult to ensure the names of snapshots stays consistent over time so it would be helpful to be able to restore the VM back to the last snapshot without needing to refer to it's name explicitly in the job.
[JIRA] [categorized-view-plugin] (JENKINS-31401) Regex filters cause jobs to be explicitly selected in categorized views
Title: Message Title Kevin Phillips updated an issue Jenkins / JENKINS-31401 Regex filters cause jobs to be explicitly selected in categorized views Change By: Kevin Phillips Attachment: submit_error.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] [categorized-view-plugin] (JENKINS-31401) Regex filters cause jobs to be explicitly selected in categorized views
Title: Message Title Kevin Phillips edited a comment on JENKINS-31401 Re: Regex filters cause jobs to be explicitly selected in categorized views I probably should also mention that there is an extreme degenerate case with respect to this defect that needs to be considered. If one has a relatively large Jenkins farm such as ours which currently manages over 1600 jobs, when one attempts to create a categorized view containing all jobs, after the initial view / filter is configured one can no longer make changes to the view. This appears to be caused by the fact that having a large number of check boxes included in the HTTP request when updating the view (ie: one for every job on the farm), the submit request fails with an error like the one I've just added attached to this issue.Given the fact there is no easy way to "deselect all" on the list of jobs, one is then left with one of two options: * manually go through all 1600+ jobs and uncheck them one by one * delete the view and recreate itNeither of these workarounds is reasonable in my opinion. Given the fact that in such situations the effects are essentially unrecoverable I'd like someone to consider escalating this issue and address it sooner rather than later. 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] [categorized-view-plugin] (JENKINS-31401) Regex filters cause jobs to be explicitly selected in categorized views
Title: Message Title Kevin Phillips commented on JENKINS-31401 Re: Regex filters cause jobs to be explicitly selected in categorized views I probably should also mention that there is an extreme degenerate case with respect to this defect that needs to be considered. If one has a relatively large Jenkins farm such as ours which currently manages over 1600 jobs, when one attempts to create a categorized view containing all jobs, after the initial view / filter is configured one can no longer make changes to the view. This appears to be caused by the fact that having a large number of check boxes included in the HTTP request when updating the view (ie: one for every job on the farm), the submit request fails with an error like the one I've just added to this issue. Given the fact there is no easy way to "deselect all" on the list of jobs, one is then left with one of two options: manually go through all 1600+ jobs and uncheck them one by one delete the view and recreate it Neither of these workarounds is reasonable in my opinion. Given the fact that in such situations the effects are essentially unrecoverable I'd like someone to consider escalating this issue and address it sooner rather than later. 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] [categorized-view-plugin] (JENKINS-31401) Regex filters cause jobs to be explicitly selected in categorized views
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-31401 Regex filters cause jobs to be explicitly selected in categorized views Issue Type: Bug Assignee: Unassigned Attachments: filter_example.png Components: categorized-view-plugin Created: 04/Nov/15 4:27 PM Priority: Major Reporter: Kevin Phillips When creating a categorized view it is possible to setup a filter on the view using numerous options and plugins. It would appear that regardless which options you choose to use when configuring this filter, when you save your changes and attempt to edit the view the effects of whatever filter you have configured are transposed to explicitly selected / checked off jobs in the list of Jobs presented towards the top of the configuration page. For example, in the attached screen shot I created a categorized view with a regular _expression_ of ".ksp." and saved the changes. Then when I attempt to edit the view after the save and examine the list of available Jobs I see that all of the jobs that satisfy my regular _expression_ are explicitly selected in the list. The most extreme case can be seen when using a regular _expression_ to select all of the jobs on your farm for the view (ie: ".*"), or using custom filters such as "All Jobs"
[JIRA] [categorized-view-plugin] (JENKINS-31401) Regex filters cause jobs to be explicitly selected in categorized views
Title: Message Title Kevin Phillips updated an issue Jenkins / JENKINS-31401 Regex filters cause jobs to be explicitly selected in categorized views Change By: Kevin Phillips When creating a categorized view it is possible to setup a filter on the view using numerous options and plugins. It would appear that regardless which options you choose to use when configuring this filter, when you save your changes and attempt to edit the view the effects of whatever filter you have configured are transposed to explicitly selected / checked off jobs in the list of Jobs presented towards the top of the configuration page.For example, in the attached screen shot I created a categorized view with a regular _expression_ of ". \ *ksp. \ *" and saved the changes. Then when I attempt to edit the view after the save and examine the list of available Jobs I see that all of the jobs that satisfy my regular _expression_ are explicitly selected in the list.The most extreme case can be seen when using a regular _expression_ to select all of the jobs on your farm for the view (ie: ". \ *"), or using custom filters such as "All Jobs" provided by the [View Job Filters|https://wiki.jenkins-ci.org/display/JENKINS/View+Job+Filters] plugin. In these cases, after saving your changes for the new filter, subsequent edits will have every single job in the list explicitly checked off. This bug is especially annoying when you want to modify the filter. Take my example from my screen shot. If I decide to change the filter to something different, say ".*32" to show only 32bit jobs, when I submit my changes the original filter criteria is preserved and the new criteria appended to the actual set of jobs being displayed because the jobs that matched the original regular _expression_ are now explicitly checked off, and they remain checked even when the regular _expression_ changes.At first glance this seemed like it may be a bug with the Jenkins core, or maybe with one of the plugins I was using for creating these custom filters, however I have been unable to replicate the problem using views of any other type (list, sectioned, etc.). This leads me to believe the issue is with the categorized view plugin itself. Add Comment
[JIRA] [conditional-buildstep-plugin] (JENKINS-18134) SCMTrigger condition includes upstream builds
Title: Message Title Kevin Phillips commented on JENKINS-18134 Re: SCMTrigger condition includes upstream builds Recently I investigated some odd build behavior on our farm which seemed to be related to this defect I reported, however the behavior I am now seeing looks to be slightly different than it was with the previous versions of Jenkins and this plugin that we were using before. Now, the behavior appears to be such that the BuildCause is only looking at one of potentially several causes and the conditional build step plugin is then just picking the first of those to use within it's condition checks. For example, here is a use case I just reproduced: Job A gets triggered by an SCM change, so BuildCause is SCMTRIGGER upon completion, Job A triggers Job B as a post-build step Job B then launches which has a conditional build step that should run when the BuildCause is of type SCMTrigger however the conditional action does not run because the BuildCause is actually reported as UPSTREAMTRIGGER Further, when considering more complex scenarios the plot seems to thicken. For example, suppose someone commit's a change to "Project A" (built by Job A) and "Project B" (built by Job B) at the same time. The sequence appears to go something like this: Job A gets triggered by the SCM change, and BuildCause is set to SCMTRIGGER upon completion, Job A triggers Job B as a post-build step Job B then launches as a result of Job A's trigger, picking up the SCM changes just committed as well, but the conditional build action still refuses to run because the BuildCause is still reported as UPSTREAMTRIGGER Closer examination of some of our production builds revealed that there are several BUILD_CAUSE environment variables available to each build. Two of the most interesting ones appear to be BUILD_CAUSE and ROOT_BUILD_CAUSE. Based on my own naive interpretation of their values, it appears as though the former tells us one (from potentially several) causes for the current job being run while the latter seems to tell us what the build cause was for the lowest level job in the dependency tree that lead to this build. So, in the case of example #1 above, BUILD_CAUSE for job B is UPSTREAMTRIGGER while the ROOT_BUILD_CAUSE is SCMTRIGGER. Interestingly, in example #2 the same results seem to be consistent with example #1. It is almost like, even though Job B has more than one trigger for the current build, the system is only reporting one of them under BUILD_CAUSE, so in this case UPSTREAMTRIGGER is reported and SCMTRIGGER is simply ignored. Not sure what part of the Jenkins system sets that
[JIRA] [conditional-buildstep-plugin] (JENKINS-18134) SCMTrigger condition includes upstream builds
Title: Message Title Kevin Phillips commented on JENKINS-18134 Re: SCMTrigger condition includes upstream builds I see there has been no activity on this bug report for several years. I'm wondering if anyone is planning on looking into this? NOTE: We have since upgraded to Jenkins LTS 1.596.3 and plugin v1.3.3 (the latest edition) and this appears to still be an issue. 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] [conditional-buildstep-plugin] (JENKINS-18134) SCMTrigger condition includes upstream builds
Title: Message Title Kevin Phillips commented on JENKINS-18134 Re: SCMTrigger condition includes upstream builds I probably should clarify that the ROOT_BUILD_CAUSE does appear to look at the build cause of the very first job in a sequence to see what initiated subsequent triggers. So, consider the following example: Job A starts because of an SCM change, and has it's BUILD_CAUSE set to SCMTRIGGER Job A triggers Job B in a post build step Job B then runs and triggers Job C as a post build step Job C then runs. It's BUILD_CAUSE will be UPSTREAMTRIGGER because Job B is what told it to run, but the ROOT_BUILD_CAUSE appears to be set to SCMTRIGGER because Job A was the first to run in the sequence and it's cause was SCMTRIGGER. Similarly, if Job C simultaneously picks up SCM changes at the same time Job B triggers it, it's BUILD_CAUSE will still be set to UPSTREAMTRIGGER. The SCM changes that were picked up basically get lost in the mix and they don't appear to be reported correctly. This, I think, is essentially the problem I'm trying to describe here. In such cases, I would expect the BUILD_CAUSE to report all of the events that may have lead to the build being triggered, thus allowing plugins like the condition build to look through the list and select the one(s) they are interested in. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You
[JIRA] [conditional-buildstep-plugin] (JENKINS-18134) SCMTrigger condition includes upstream builds
Title: Message Title Kevin Phillips edited a comment on JENKINS-18134 Re: SCMTrigger condition includes upstream builds I probably should clarify that the ROOT_BUILD_CAUSE does appear to look at the build cause of the very first job in a sequence to see what initiated subsequent triggers. So, consider the following example: # Job A starts because of an SCM change, and has it's BUILD_CAUSE set to SCMTRIGGER # Job A triggers Job B in a post build step # Job B then runs and triggers Job C as a post build step # Job C then runs. It's BUILD_CAUSE will be UPSTREAMTRIGGER because Job B is what told it to run, but the ROOT_BUILD_CAUSE appears to be set to SCMTRIGGER because Job A was the first to run in the sequence and it's cause was SCMTRIGGER.Similarly, if Job C simultaneously picks up SCM changes at the same time Job B triggers it, it's BUILD_CAUSE will still be set to UPSTREAMTRIGGER. The SCM changes that were picked up basically get lost in the mix and they don't appear to be reported correctly. This, I think, is essentially the problem I'm trying to describe here.In such cases, I would expect the BUILD_CAUSE to report all of the events that may have lead to the build being triggered, thus allowing plugins like the condition build to look through the list and select the one(s) they are interested in. In fact, it would appear that the conditional build plugin already supports processing multiple triggers because the conditions you can provide expose an option to only run when that build cause is "exclusive" (ie: only that one build cause and no others). The only way such an option makes sense is if the plugin supports detecting and processing builds that run as a result of multiple triggers.. 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] [nodelabelparameter-plugin] (JENKINS-15339) Node Label Parameter plugin breaks Windows batch file build steps if Name field not filled in
Title: Message Title Kevin Phillips commented on JENKINS-15339 Re: Node Label Parameter plugin breaks Windows batch file build steps if Name field not filled in I have confirmed this bug is reproducible in Jenkins LTS v1.596.3 as well, so I would like to see the fix backported to the LTS edition 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] [nodelabelparameter-plugin] (JENKINS-15339) Node Label Parameter plugin breaks Windows batch file build steps if Name field not filled in
Title: Message Title Kevin Phillips edited a comment on JENKINS-15339 Re: Node Label Parameter plugin breaks Windows batch file build steps if Name field not filled in IhaveconfirmedthisbugisreproducibleinJenkinsLTSv1.596.3aswell,soIwouldliketoseethefixbackportedtotheLTSeditionaswell. Also,IcanconfirmthebugisreproducibleonWindowsaswellsinceourJenkinsmasterrunsonaWindows7host. 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] [core] (JENKINS-29060) Jenkins incorrectly reports timestamps are inconsistent
Title: Message Title Kevin Phillips commented on JENKINS-29060 Re: Jenkins incorrectly reports timestamps are inconsistent be aware of JENKINS-21785 etc That was the issue that help us resolve the major SVN issues we were experiencing. Thanks for the link though. The difficulty involved updating our 1000+ jobs to include the appropriate credentials definitions, which were not a requirement in previous LTS releases. Most, but not all, of our jobs monitor SVN repositories but it was a bit tricky to ensure that all the affected jobs, and only those affected by this change, got updated. For future reference, any time that you include an invasive change like this in an LTS edition you probably should provide an easier way for users to upgrade their configurations instead of leaving them up to their own vices to hack around the changes. It would greatly reduce the pain of upgrading. I was referring to those in my earlier comment. Sorry - my misunderstanding. 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] [core] (JENKINS-29060) Jenkins incorrectly reports timestamps are inconsistent
Title: Message Title Kevin Phillips edited a comment on JENKINS-29060 Re: Jenkins incorrectly reports timestamps are inconsistent bq.beawareofJENKINS-21785etcThatwastheissuethathelpusresolvethemajorSVNissueswewereexperiencing.Thanksforthelinkthough.Thedifficultyinvolvedupdatingour1000+jobstoincludetheappropriatecredentialsdefinitions,whichwerenotarequirementinpreviousLTSreleases.Most,butnotall,ofourjobsmonitorSVNrepositoriesbutitwasabittrickytoensurethatalltheaffectedjobs,andonlythoseaffectedbythischange,gotupdated. AndunfortunatelywegleanednobenefitfromtheimprovedsecurityasallofourJenkinsinstancesarerunbehindafirewallandoperatewithinaWindowsdomainsoonlytrustedsystemhaveaccesstoourkeyservices.Thenetresultforuswasalotofsuperfluousworkforlittletonogain. Forfuturereference,anytimethatyouincludeaninvasivechangelikethisinanLTSeditionyouprobablyshouldprovideaneasierwayforuserstoupgradetheirconfigurationsinsteadofleavingthemuptotheirownvicestohackaroundthechanges.Itwouldgreatlyreducethepainofupgrading.bq.Iwasreferringtothoseinmyearliercomment.Sorry-mymisunderstanding. 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] [core] (JENKINS-29060) Jenkins incorrectly reports timestamps are inconsistent
Title: Message Title Kevin Phillips commented on JENKINS-29060 Re: Jenkins incorrectly reports timestamps are inconsistent One last question: Assuming you understand the Jenkins internals better than I, can you say whether the weird 'agents out of sync' problem described by JENKINS-18671 may be the cause of this out-of-order build issue? (ie: if the agent says a build started at 12:59:07pm but the clock on the Jenkins master says the current time is 12:59:03, could that lead Jenkins to think the build times are broken when in fact they aren't in actuality?) 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] [core] (JENKINS-29060) Jenkins incorrectly reports timestamps are inconsistent
Title: Message Title Kevin Phillips commented on JENKINS-29060 Re: Jenkins incorrectly reports timestamps are inconsistent NOTE: Based on my brief review of the source code in the link provided above, the 'inconsistent' build labels are defined as build numbers with ascending values that have descending time stamps, or vice versa. As I mentioned in my bug report I have confirmed that none of the builds being reported by Jenkins fall into that category. When I examine the build.xml files on disk on the Jenkins master, the build numbers, time stamps, folder names and symbolic links are all consistent with one another, and all of the values are always in ascending order (ie: build 123 has a time stamp larger than build 122 and smaller than build 124, in every reported case). I suppose this point may be moot if the underlying architecture has been changed in such a way that prevents any of these kinds of problems from happening, but I just thought I should mention it in case a similar bug may still be present in the latest version 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] [core] (JENKINS-29060) Jenkins incorrectly reports timestamps are inconsistent
Title: Message Title Kevin Phillips commented on JENKINS-29060 Re: Jenkins incorrectly reports timestamps are inconsistent Since 1.597 changed the storage layout of builds on disk, the reported issue should no longer occur there. Good to know. Hopefully the other product-stop bugs that were introduced by the 1.609.1 update can be fixed sooner rather than later so we can get those fixes as well. You need to compare the files on disk, not the loaded build records. Understood. I did actually compare the on-disk log and configuration files as stored on the Jenkins master when examining the data and could see nothing that would suggest that build numbers or time stamps were in any way out of order or duplicated with any other. That's what confused me. 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] [core] (JENKINS-29060) Jenkins incorrectly reports timestamps are inconsistent
Title: Message Title Kevin Phillips edited a comment on JENKINS-29060 Re: Jenkins incorrectly reports timestamps are inconsistent NOTE:Basedonmybriefreviewofthesourcecodeinthelinkprovidedabove,the'inconsistent'buildlabelsaredefinedasbuildnumberswithascendingvaluesthathavedescendingtimestamps,orviceversa.AsImentionedinmybugreportIhaveconfirmedthatnoneofthebuildsbeingreportedby our Jenkins instance fallintothatcategory.WhenIexaminethebuild.xmlfilesondiskontheJenkinsmaster,thebuildnumbers,timestamps,foldernamesandsymboliclinksareallconsistentwithoneanother,andallofthevaluesarealwaysinascendingorder(ie:build123hasatimestamplargerthanbuild122andsmallerthanbuild124,ineveryreportedcase).Isupposethispointmaybemootiftheunderlyingarchitecturehasbeenchangedinsuchawaythatpreventsanyofthesekindsofproblemsfromhappening,butIjustthoughtIshouldmentionitincaseasimilarbugmaystillbepresentinthelatestversionaswell. 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] [core] (JENKINS-29060) Jenkins incorrectly reports timestamps are inconsistent
Title: Message Title Kevin Phillips commented on JENKINS-29060 Re: Jenkins incorrectly reports timestamps are inconsistent Anything else a blocker for you? One other behavioral change in 1.609.1 is that the BUILD_ID property was changed from a time stamp to a numeric identifier. All of our build configurations and releases processes were dependent upon a builds identifier being a time stamp, and we more-or-less use that BUILD_ID variable everywhere (scripts, code, etc.). I did find a plugin that allows one to create a new time-stamp based environment variable for each build (Zen Time Stamp) but we'll need to reconfigure our infrastructure to use the new variable name throughout. We hit a LOT of problems with the SVN plugin as well but I believe we've finally sorted all those out. I'm also currently investigating some bugs with the way the new Jenkins version handles jobs that are enqueued for builds. There are a couple of cases where jobs may get deadlocked in the queue for various reasons. Still trying to isolate specific use cases though before I file any more bugs. NOTE: We may have to stick with v1.596.3 for the time being. Assuming there are a great number of new changes / improvements / fixes included in the next LTS release, we'll likely have to invest considerable time and expense making sure none of those additional changes break anything else anew. No idea re JENKINS-18671 . I doubt you're seeing the same issue. Make sure your nodes are all in synced time. All of our agents, and the master, are synchronized using the same NTP server and I have confirmed via direct examination of the agents that all the physical clocks on all machines are in fact correct and in sync with each other (to within 1S variance at least). It's only the Jenkins dashboard that suggests otherwise. If you believe JENKINS-18671 (or the underlying code change from JENKINS-18438 ) just let me know and I'll create a new defect for that. If this problem is in fact a new / different bug, and it is a contributing factor to the inconsistent time stamps being reported, then I would say that would be a significant issue that we'd also want fixed in the next LTS release as well. We can't have build logs getting corrupted even if the problem is intermittent. We use Jenkins as a central service now for all of our production work and we need to be able to rely on its ability to preserve the details of those build operations for auditing purposes. (although, I guess this is a problem we're currently stuck with on 1.596.3 so it hopefully wouldn't get any worse if we were to move to a newer LTS version at least).
[JIRA] [build-metrics-plugin] (JENKINS-23316) Some projects have builds whose timestamps are inconsistent
Title: Message Title Kevin Phillips commented on JENKINS-23316 Re: Some projects have builds whose timestamps are inconsistent I see this issue has been resolved as a duplicate, but there is no link or mention of which issue it duplicates? We are encountering this exact problem on the last two LTS editions of Jenkins (1.596.3 and 1.609.1). I'd like to make sure any further debugging information I report is put in the correct location. 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] [core] (JENKINS-29060) Jenkins incorrectly reports timestamps are inconsistent
Title: Message Title Kevin Phillips commented on JENKINS-29060 Re: Jenkins incorrectly reports timestamps are inconsistent This problem seems very similar, although slightly different in it's description, to JENKINS-18289 . I've added a related link for reference in case it's helpful. 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] [core] (JENKINS-29060) Jenkins incorrectly reports timestamps are inconsistent
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-29060 Jenkins incorrectly reports timestamps are inconsistent Issue Type: Bug Assignee: Unassigned Components: core Created: 24/Jun/15 1:07 PM Labels: lts-candidate Priority: Major Reporter: Kevin Phillips After recently upgrading to Jenkins LTS v1.596.3 we noticed that dozens, if not hundreds of builds per day are being reported as having inconsistent time stamps. Here are a few specific details that may help isolate the problem: I have confirmed that the build number (ie: integer values) for the offending builds as reported on the Jenkins dashboard is consistent with what is recorded in the build.xml files on the server, which are also consistent with the symbolic links stored on disk that point to those builds I have confirmed that the build IDs (ie: the time-stamped formatted identifiers) for the offending builds as reported on the Jenkins dashboard are consistent with what is recorded in the build.xml files on the server, which are also consistent with the names of the
[JIRA] [core] (JENKINS-18671) Clock Difference broken on Manage Nodes page
Title: Message Title Kevin Phillips commented on JENKINS-18671 Re: Clock Difference broken on Manage Nodes page Question: is it possible that this defect could also be causing an out of order builds problem as described by JENKINS-18289 ? Ever since we've upgraded to the latest LTS edition and discovered this time-sync problem, we've been getting dozens, if not hundreds of out-of-order build notifications a day. Seems like an odd coincidence. I probably should also mention that due to other critical bugs introduced in 1.609.1 LTS we've been forced to downgrade to 1.596.3 LTS, and both problems (ie: slaves out of sync and out of order builds) are still present. I'm not sure if this helps isolate the cause of the problem or not. 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] [core] (JENKINS-29060) Jenkins incorrectly reports timestamps are inconsistent
Title: Message Title Kevin Phillips updated an issue Jenkins / JENKINS-29060 Jenkins incorrectly reports timestamps are inconsistent Change By: Kevin Phillips AfterrecentlyupgradingtoJenkinsLTSv1.596.3wenoticedthatdozens,ifnothundredsofbuildsperdayarebeingreportedashavinginconsistenttimestamps.Hereareafewspecificdetailsthatmayhelpisolatetheproblem:*Ihaveconfirmedthatthebuildnumber(ie:integervalues)fortheoffendingbuildsasreportedontheJenkinsdashboardisconsistentwithwhatisrecordedinthebuild.xmlfilesontheserver,whicharealsoconsistentwiththesymboliclinksstoredondiskthatpointtothosebuilds*IhaveconfirmedthatthebuildIDs(ie:thetime-stampedformattedidentifiers)fortheoffendingbuildsasreportedontheJenkinsdashboardareconsistentwithwhatisrecordedinthebuild.xmlfilesontheserver,whicharealsoconsistentwiththenamesofthelogfoldersforeachofthesebuilds*IhaveconfirmedthatthestartTimeelementsinthebuild.xmlfilesresolvetothesamebuildIDsusedtostoreandorganizethebuilds*Ihaveconfirmedthatnoneofthesebuildsinterfereoroverlapwithpreviousorsubsequentbuildsofthesamejobs(ie:ifoffendingbuildis#536,Ihaveconfirmedthatitdoesinfactrunafterbuild#535andbeforebuild#537,andthatall3suchbuildshaveconsistentreferencestobuildnumbersandIDsthroughoutthelogs)*AfterupgradingtothisversionIdiscoveredthatallbuildagentsconnectedtoourmasterarenowreportingtheirclocksasbeingoutofsync,despitethefactthatIhaveconfirmedthatthisisnotactuallycorrect(ie:asdescribedunderJENKINS-18671).IsuspectthatthisincorrecttimereportingmaybesomehowconfusingJenkinsintothinkingbuildshaveincorrecttimestampswheninfacttheydon't.Iprobablyshouldalsomentionthatwe'veattemptedtoupgradetothelatestLTSedition,v1.609.1,intheoffchancetheremaybesomeimprovementsincludedtherethatmayresolvethisissue(ie:sinceitappearstohavere-structuredhowbuildsarestoredondisk,eliminatingthe'timestamp'labellingmechanism,whichmaycorrectthisproblem)howeverduetoother criticalbreakingchanges production-stopdefects includedinthatrelease(ie:JENKINS-28513)wewereforcedtoremainonthe1.596.3versionforthetimebeing.:( Add Comment
[JIRA] [core] (JENKINS-29011) Jenkins 1.609.1 reverse migration script doesn't work when using a custom log folder
Title: Message Title
Kevin Phillips updated an issue
Jenkins / JENKINS-29011
Jenkins 1.609.1 reverse migration script doesn't work when using a custom log folder
Change By:
Kevin Phillips
WerecentlyupgradedourJenkinsLTSinstancefromv1.532.3tothelatest1.609.1version,afterwhichwediscoveredsomecriticaldefectsthatrequiredustorollbacktothepriorversion,1.596.3.Insodoingweencounteredissuesloadingbuildlogsandsuchduetotheincompatibleconfigurationchangesappliedby1.609.1.Weproceededtorunthedowngradescriptasdescribed[here|https://wiki.jenkins-ci.org/display/JENKINS/JENKINS-24380+Migration]tonoavail.Thescriptappearedtohavecompletedwithouterrorbutitdidn'tactuallyapplyanychangestotheconfiguration.Furtherad-hoctestingrevealsthatonecontributingfactoristhatwehavesetacustompathfortheJenkinslogsonourmasterconfiguration(ie:$ \ {JENKINS_HOME}\logs\builds\$ \ {ITEM_FULL_NAME})andthisseemstoconfusethereversemigrationscript.TotestmytheoryImovedafewofourbuildlogfoldersoutofourcustomfolderandintotheirdefaultlocationunder$ \ {JENKINS_HOME}\jobs\$ \ {ITEM_FULL_NAME}\buildsandthenre-ranthedowngradescript.AllofthelogsIhadrelocatedwerecorrectlydowngradedtotheoldconfiguration,howevernoneofthelogsthatwereleftunderthecustomlogfolderweretouched.Needlesstosaymovingthebuildlogsbacktotheirdefaultlocationsistediousanderrorproneatbest,andtheeffortisexacerbatedbylargerbuildfarmslikeourswherewehavewellover1000jobswhichwouldneedtobemigrated.This,onceagain,putsusbetweenarockandahardplace.Weareunabletocontinueusingv1.609.1duetofailurestopreservebackwardscompatibilityandifwedowngradetothepreviousversionwearegoingtolooseallofourbuildhistory,whichissubstantial-andofcriticalimportancetoourcompany-orwemustincursignificantexpensetocorrecttheissueourselves.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [core] (JENKINS-29011) Jenkins 1.609.1 reverse migration script doesn't work when using a custom log folder
Title: Message Title Kevin Phillips commented on JENKINS-29011 Re: Jenkins 1.609.1 reverse migration script doesn't work when using a custom log folder I just re-worded the defect description to reflect this new understanding of the Jenkins folder structure. 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] [core] (JENKINS-29060) Jenkins incorrectly reports timestamps are inconsistent
Title: Message Title Kevin Phillips commented on JENKINS-29060 Re: Jenkins incorrectly reports timestamps are inconsistent I probably should also pose the question: what criteria does Jenkins use to decide whether the timestamps on a job are inconsistent or not? (ie: what are they inconsistent with?) As described above, so far as I can tell all of the data stored in the actual build logs looks correct to me, however I may be overlooking something. 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] [core] (JENKINS-29011) Jenkins 1.609.1 reverse migration script doesn't work when using a custom log folder
Title: Message Title
Kevin Phillips updated an issue
Jenkins / JENKINS-29011
Jenkins 1.609.1 reverse migration script doesn't work when using a custom log folder
Change By:
Kevin Phillips
WerecentlyupgradedourJenkinsLTSinstancefromv1.532.3tothelatest1.609.1version,afterwhichwediscoveredsomecriticaldefectsthatrequiredustorollbacktothepriorversion,1.596.3.Insodoingweencounteredissuesloadingbuildlogsandsuchduetotheincompatibleconfigurationchangesappliedby1.609.1.Weproceededtorunthedowngradescriptasdescribed[here|https://wiki.jenkins-ci.org/display/JENKINS/JENKINS-24380+Migration]tonoavail.Thescriptappearedtohavecompletedwithouterrorbutitdidn'tactuallyapplyanychangestotheconfiguration.Furtherad-hoctesting seemstoindicate reveals that theunderlyingproblemhastodowiththewaynewerversionsofJenkinsstoretheirbuildlogs.Forexample,fromwhatIcantell,ifyouinstall1.609.1on onecontributingfactoristhatwehaveset a cleansystemitwillplacebuildlogsunder custompathfor the ./jobssubfolderalongwiththejobtheyareassociatedwith.Howeverinolder Jenkins versionsthebuild logs werestoredunderthe./logsfolder,disconnectedfromthejobconfigurations.Theinterestingbitisthatwhenyouupdatefromthelegacyversionstothelatestversionthebuildlogsdon'tappeartogetmovedtothenewlocationunder./jobs.The onour master appearstohavesomewayofindicatingtoitselfthatlegacybuild configuration(ie:${JENKINS_HOME}\ logs existedduringtheupgrade \builds\${ITEM_FULL_NAME}) and thatitshouldcontinue thisseems to maintain confuse the logsinthatlocationinsteadofthenewlocation.Everything,thatis,exceptforthis reversemigrationscript. To check test mytheoryImovedafewofourbuildlogfoldersoutof the./logs ourcustom folderandintotheir moremodern default locationunder ./ ${JENKINS_HOME}\ jobs \${ITEM_FULL_NAME}\builds andthenre-ranthedowngradescript.AllofthelogsIhadrelocatedwerecorrectlydowngradedtotheoldconfiguration,howevernoneofthelogsthatwereleftunderthe oldlogs customlog folderweretouched.Needlesstosaymovingthebuildlogs back to thenewlocation theirdefaultlocations istediousanderrorproneatbest,andtheeffortisexacerbatedbylargerbuildfarmslikeourswherewehavewellover1000jobswhichwouldneedtobemigrated.This,onceagain,putsusbetweenarockandahardplace.Weareunabletocontinueusingv1.609.1duetofailurestopreservebackwardscompatibilityandifwedowngradetothepreviousversionwearegoingtolooseallofourbuildhistory,whichissubstantial-andofcriticalimportancetoourcompany-orwemustincursignificantexpensetocorrecttheissueourselves.
Add Comment
[JIRA] [core] (JENKINS-29011) Jenkins 1.609.1 reverse migration script doesn't work when using a custom log folder
Title: Message Title Kevin Phillips updated an issue Jenkins / JENKINS-29011 Jenkins 1.609.1 reverse migration script doesn't work when using a custom log folder Change By: Kevin Phillips Summary: Jenkins1.609.1reversemigrationscriptdoesn't always work afteranupgrade whenusingacustomlogfolder 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] [core] (JENKINS-29011) Jenkins 1.609.1 reverse migration script doesn't work when using a custom log folder
Title: Message Title Kevin Phillips commented on JENKINS-29011 Re: Jenkins 1.609.1 reverse migration script doesn't work when using a custom log folder I probably should mention that I have managed to take those few sample projects I downgraded as part of my debugging work for this defect and extrapolate a pattern from the changes the downgrade script made to the folders and XML files, which allowed me to create a simple Python script that essentially walked the build logs sub-tree and corrected the legacy logs so they work correctly with the 1.596.3 edition. This has (thankfully) gotten us out of this particular difficult situation, however it probably would be good to still correct your reverse migration script so others don't hit this problem 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] [build-blocker-plugin] (JENKINS-28513) Build-Blocker-Plugin blocks on builds queued leading to deadlock
Title: Message Title Kevin Phillips commented on JENKINS-28513 Re: Build-Blocker-Plugin blocks on builds queued leading to deadlock Also, 1.609.1 (or rather 1.607) changed how slave configs are stored. Downgrading will probably lose those entirely. Thanks for the heads up. We actually had no alternative recourse but to attempt a downgrade to 1.596.3 and noticed this problem immediately. Luckily it was relatively easy to hack around by moving some XML declarations around in the configuration files. 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] [core] (JENKINS-29011) Jenkins 1.609.1 reverse migration script doesn't always work after an upgrade
Title: Message Title Kevin Phillips commented on JENKINS-29011 Re: Jenkins 1.609.1 reverse migration script doesn't always work after an upgrade ah - my appologies. We must have customized that early on years ago when we first adopted Jenkins. That being the case, it would seem that this defect would apply to users who have customized the location of the logs folder then. The downgrading script appears to ignore those settings. 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] [build-blocker-plugin] (JENKINS-28513) Build-Blocker-Plugin blocks on builds queued leading to deadlock
Title: Message Title Kevin Phillips commented on JENKINS-28513 Re: Build-Blocker-Plugin blocks on builds queued leading to deadlock Why were such large changes rushed into an LTS release? My sentiments exactly. We hit at least 6 or 7 hugely critical, production stop bugs just like this when doing our latest upgrade and we've had to devote significant time and effort just to get back to a state similar to what we were in before the upgrade - and that work is still ongoing today after weeks of effort. I'd like to say this is an isolated circumstance but the last 2 or 3 upgrades we've tried since our adoption of the tool a couple of years ago have had similar results. In fact, I've even gone so far as to question whether there is any value whatsoever in adopting the LTS edition at all. It's benefit is supposed to provide a stable working environment for production use but in-so-far as upgrades are concerned, that seems far from the truth. Then, to make matters worse, fixes for the critical bugs are expected to be rolled out and tested on the mainline first, meaning that fixes take way longer to get released on the LTS branch - which compounds the problem. Really, we love the tool - when it works. But managing upgrades is so painful that we may need to consider adopting a different tool in the longer term. We just can't afford to spend this amount of time and effort managing the tool, and the cost of the downtime it causes for our production teams. 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] [core] (JENKINS-29011) Jenkins 1.609.1 reverse migration script doesn't always work after an upgrade
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-29011 Jenkins 1.609.1 reverse migration script doesn't always work after an upgrade Issue Type: Bug Assignee: Unassigned Components: core Created: 22/Jun/15 11:39 AM Priority: Major Reporter: Kevin Phillips We recently upgraded our Jenkins LTS instance from v1.532.3 to the latest 1.609.1 version, after which we discovered some critical defects that required us to roll back to the prior version, 1.596.3. In so doing we encountered issues loading build logs and such due to the incompatible configuration changes applied by 1.609.1. We proceeded to run the downgrade script as described here to no avail. The script appeared to have completed without error but it didn't actually apply any changes to the configuration. Further ad-hoc testing seems to indicate that the underlying problem has to do with the way newer versions of Jenkins store their build logs. For example, from what I can tell, if you install 1.609.1 on a clean system it will place build logs under the ./jobs subfolder along with the job they are associated with. However in older Jenkins versions the build logs were stored under the ./logs folder, disconnected from the job configurations. The interesting bit is that when you update from the legacy versions to the latest version the build logs don't appear to get moved to the new location under ./jobs. The master appears to have some way of indicating to itself that legacy build logs existed during the upgrade and that it should continue to maintain the logs in that location instead of the new location. Everything, that is, except for this
[JIRA] [build-blocker-plugin] (JENKINS-28513) Build-Blocker-Plugin blocks on builds queued leading to deadlock
Title: Message Title Kevin Phillips commented on JENKINS-28513 Re: Build-Blocker-Plugin blocks on builds queued leading to deadlock NOTE: It appears the maintainer of this plugin is aware that deadlocks are potentially (or, dare I say guaranteed) when using this plugin. There is a TODO on the plugin information page stating just that: https://wiki.jenkins-ci.org/display/JENKINS/Build+Blocker+Plugin I am concerned that this may indicate a pre-existing bug that somehow has just been exploited or exacerbated in some way to changes to the Jenkins core. We never had this problem prior to our upgrade, but we were using a very old version of the core (1.532.3) so it may be hard to track down which change to which version may be the culprit. 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] [core] (JENKINS-18671) Clock Difference broken on Manage Nodes page
Title: Message Title Kevin Phillips commented on JENKINS-18671 Re: Clock Difference broken on Manage Nodes page Can anyone tell me whether this change has been backported to the LTS release branch? We just upgraded our Jenkins master and slaves to the latest LTS edition (1.609.1) and it appears we are experiencing the same problem as described here. As previously mentioned, all of our agents including the master are being synchronized to the same NTP server and visual confirmation of the system time as reported by the OS does show that the master is in sync with the agents (to within 1 second anyway) so it appears the information presented on the dashboard is actually incorrect. 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] [build-blocker-plugin] (JENKINS-28513) Build-Blocker-Plugin blocks on builds queued leading to deadlock
Title: Message Title Kevin Phillips commented on JENKINS-28513 Re: Build-Blocker-Plugin blocks on builds queued leading to deadlock We just recently (like yesterday) upgraded to the latest LTS edition (1.609.1) and discovered this bug exists there as well. Downgrading to an older Jenkins version is not an option for us as we've already migrated all of our production servers to the new version and it would be significant effort to do so. However, seeing as how this bug is debilitating (ie: completely blocks dozens of jobs, affecting hundreds more that depend on them, thus affecting many different development teams) I would appreciate any feedback that would allow us to work around or fix the problem asap. Really, any input from anyone would be helpful! 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] [build-blocker-plugin] (JENKINS-28513) Build-Blocker-Plugin blocks on builds queued leading to deadlock
Title: Message Title Kevin Phillips commented on JENKINS-28513 Re: Build-Blocker-Plugin blocks on builds queued leading to deadlock Szymon Stasik My thoughts exactly. 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] [core] (JENKINS-28926) Jenkins queue self-locking without apparent reason?
Title: Message Title Kevin Phillips commented on JENKINS-28926 Re: Jenkins queue self-locking without apparent reason? Can anyone here confirm whether this fix will address the problem described here? Further, I have confirmed the problem (at least as described under JENKINS-28513) is reproducible on the latest LTS release as well (v1.609.1). We just recently finishing rolling out this LTS edition into production on our build farm yesterday and have had numerous cases already where this bug is affecting our production teams. As it stands we've had severely detrimental effects on our development teams as a result of this defect so the sooner it can be backported the better! 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] [core] (JENKINS-28926) Jenkins queue self-locking without apparent reason?
Title: Message Title Kevin Phillips commented on JENKINS-28926 Re: Jenkins queue self-locking without apparent reason? Since we have experienced severe regression problems with every single Jenkins upgrade we have ever performed, we now have a sandbox environment setup for testing new versions (although apparently our test environment is insufficient to catch all problems since we still managed to miss this one). I only mention that here because I can probably test out 1.618 fairly quickly to see if I can reproduce the problem on our particular configuration, which I would be happy to do if it means we can get the fix backported sooner. Just let me know if I can help. 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] [core] (JENKINS-20327) “Form too large” errors submitting view configurations with many jobs
Title: Message Title Kevin Phillips commented on JENKINS-20327 Re: “Form too large” errors submitting view configurations with many jobs In my latest case the view was a Sectioned View type, with maybe 10 sub-sections of type List View. Each list view subsection has a regular _expression_ for the job filter, and there are few if any jobs that are checked off individually. I suspect I can reproduce the problem on other view types as well. If I get some time today to try that out I'll let you know the results. 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] [core] (JENKINS-20327) “Form too large” errors submitting view configurations with many jobs
Title: Message Title Kevin Phillips commented on JENKINS-20327 Re: “Form too large” errors submitting view configurations with many jobs I decided to just take some time right away to do some further tests and I can't seem to reproduce the problem on other view types. I have tried the following: nested views list views categorized jobs view build pipeline view my view status view dashboard view Also, for some of our views of type Sectioned View with a smaller number of sub-sections on them, the error doesn't appear to occur. The combination of a view of type Sectioned View with a large number of sub-sections of type List View seems to be the problematic case. Also, our build farm has a large number of jobs on it (1200 atm). If the Sectioned View were submitting information about each of these jobs for each of the list sub-views that could explain why the error only happens in this one use case. Either way, the hack mentioned above for overriding the maxFormContentSize property for Jetty seems to prevent the problem, at least for us. This at least unblocks us for the time being. Still, it would be good to try and get a fix for this if possible. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [core] (JENKINS-20327) “Form too large” errors submitting view configurations with many jobs
Title: Message Title Kevin Phillips commented on JENKINS-20327 Re: “Form too large” errors submitting view configurations with many jobs It's different as it should be easier to default to a large value without negative effects.. Yeah - that's what I suspected. ...large requests will still happen depending on plugin. Yeah - this is I guess one of the unfortunate down-sides to the modular / plugin design of Jenkins. When something like this form size limit changes it takes time for that news to propagate out to all of the different maintainers of the different plugins, and even longer for them all to fix their plugins to compensate for the change. 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] [sectioned-view-plugin] (JENKINS-28716) Form Too Large error when changing view options
Title: Message Title Kevin Phillips commented on JENKINS-28716 Re: Form Too Large error when changing view options This bug seems to be a symptom of the same problem described here. From what I can tell views of other types, and job configurations, no longer suffer from this issue so the problem appears to be isolated to just the Sectioned View. Hence the reason I created a new defect for 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] [sectioned-view-plugin] (JENKINS-28716) Form Too Large error when changing view options
Title: Message Title Kevin Phillips updated an issue Jenkins / JENKINS-28716 Form Too Large error when changing view options Change By: Kevin Phillips Labels: lts-candidate 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] [sectioned-view-plugin] (JENKINS-28716) Form Too Large error when changing view options
Title: Message Title Kevin Phillips commented on JENKINS-28716 Re: Form Too Large error when changing view options NOTE: Anyone who may be experiencing this problem in a production environment may be interested to know there is a workaround described on JENKINS-20327 that may be of interest: https://issues.jenkins-ci.org/browse/JENKINS-20327?focusedCommentId=190285page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-190285 This workaround worked for us in our case 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] [core] (JENKINS-20327) “Form too large” errors submitting view configurations with many jobs
Title: Message Title Kevin Phillips commented on JENKINS-20327 Re: “Form too large” errors submitting view configurations with many jobs Please file an issue against Sectioned View Plugin to investigate whether the form size can be reduced there. Done: JENKINS-28716 It's reasonable to limit the size of submitted forms to a sensible value by default... Agreed. The only debatable point is what value is 'sensible' in this context. In our context / use case it is obviously not sensible. Not really a hack, just a legitimate option. I'm not sure I agree with your assessment. As a user of the Jenkins product I expect the tool to work right out of the box with minimal manual modification / tweaking. Unfortunately, in this case, this was not possible. To make matters worse the bug itself was not obvious at first glance, and the root cause and workaround to the problem were also not directly obvious from the error produced. In fact, the only reason I knew of the existence of this maxFormContentSize option was by searching through bug reports until I came across this one which made mention of it. Hardly a simple process. Conversely, I suspect that if you were to select a sufficiently large form size limit such that large scale users such as us wouldn't encounter this problem in the first place it would have little to no effect on the other users of the tool. That would be a preferable solution than having your users manually modify configuration files to make the tool work. Hence my assessment that this is in fact a 'hack'. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You
[JIRA] [sectioned-view-plugin] (JENKINS-28716) Form Too Large error when changing view options
Title: Message Title Kevin Phillips created an issue Jenkins / JENKINS-28716 Form Too Large error when changing view options Issue Type: Bug Assignee: Timothy Bingaman Components: sectioned-view-plugin Created: 03/Jun/15 1:10 PM Environment: win7x64 Priority: Minor Reporter: Kevin Phillips While testing the latest LTS edition (v1.596.3) for potential rollout on our build farm I discovered a bug that prevents the modification of Sectioned Views. In the use cases described below, attempting to make any modification to a Sectioned View, no matter how trivial, results in a Form Too Large error being thrown by Jenkins. This effectively prevents users from making any modifications to the affected views. From what I can tell there are 2 specific factors that cause this error to occur: 1. the number of jobs in total managed by the Jenkins instance (in our case, we have 1200 jobs) 2. the number of sub-sections on the view of type list view (in our test cases, views with just one or two list view subsections seem to work fine, but ones with 5-10 subsections of this type don't)
[JIRA] [core] (JENKINS-20327) “Form too large” errors submitting view configurations with many jobs
Title: Message Title Kevin Phillips commented on JENKINS-20327 Re: “Form too large” errors submitting view configurations with many jobs PS: Sorry for the rant. I have been spending days / weeks testing the latest LTS edition of Jenkins in preparation for an upgrade to our build farm and I've been dealing with bug after bug, which are supposed to be 'resolved' by hack after hack and it has just been wearing on me. This experience is unfortunately reducing my confidence in the tool as a whole, and in the LTS maintenance stream in particular. We chose to use the LTS edition instead of the head / master version to avoid problems just like 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] [core] (JENKINS-20327) “Form too large” errors submitting view configurations with many jobs
Title: Message Title Kevin Phillips commented on JENKINS-20327 Re: “Form too large” errors submitting view configurations with many jobs Yes, the problem is related to submitting changes to view configurations. Was there some specific information you'd like me to provide that hasn't already been stated above? 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] [core] (JENKINS-20327) “Form too large” errors submitting view configurations with many jobs
Title: Message Title Kevin Phillips updated an issue Jenkins / JENKINS-20327 “Form too large” errors submitting view configurations with many jobs Change By: Kevin Phillips Labels: 1.565.1-fixedjetty lts-candidate performanceview 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] [core] (JENKINS-20327) “Form too large” errors submitting view configurations with many jobs
Title: Message Title Kevin Phillips commented on JENKINS-20327 Re: “Form too large” errors submitting view configurations with many jobs I just noticed that this bug also affects the latest LTS edition as well - v1.596.3 at the current moment. I haven't compared the behavior with latest weekly builds, but assuming this defect has been successfully repaired on the master version it should probably be backported to the LTS branch as well. I added the lts-candidate label for reference as well. Not sure if that will make any difference seeing as how the issue has already been resolved but at least it's there. 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] [core] (JENKINS-9104) Visual studio builds started by Jenkins fail with Fatal error C1090 because mspdbsrv.exe gets killed
Title: Message Title Kevin Phillips updated an issue Jenkins / JENKINS-9104 Visual studio builds started by Jenkins fail with Fatal error C1090 because mspdbsrv.exe gets killed Change By: Kevin Phillips Labels: lts-candidate 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] [core] (JENKINS-23147) Jenkins won't restart itself through the GUI
Title: Message Title Kevin Phillips commented on JENKINS-23147 Re: Jenkins won't restart itself through the GUI I have reproduced this same problem in the latest LTS edition (1.596.3 atm) on a clean Windows 7 x64 OS as well. I'm using Java 64bit v1.7.0_80-b15 in case that is a factor. I've tried setting up the Jenkins service to run under the local system account as well as a local administrative user and neither setting works correctly. I have confirmed that the command line interface for the service, jenkins.exe, does correctly control the Windows service. Performing jenkins start, jenkins stop, jenkins restart, jenkins uninstall and jenkins install all work correctly when run from a command prompt using the same local user profile the service runs within. I have also tried explicitly adding WMI permissions to all relevant users / groups as well using the process found here in case this was some kind of security problem but that had no effect either. Finally, unlike other defects in the issue tracker like JENKINS-23395 and JENKINS-22685 , I see no errors or warnings of any kind related to the service reboot. In fact the only reference to the reboot request at all in any of the logs is this short snippet I found in the jenkins.err.log file: Jun 01, 2015 12:10:43 PM jenkins.model.Jenkins$22 run SEVERE: Restarting VM as requested by anonymous If I try performing a safe restart (ie: http://jenkins/safeRestart), the results are the same but I get a couple of extra lines in the error log as shown below: May 26, 2015 8:41:05 AM hudson.model.UpdateCenter doSafeRestart INFO: Scheduling Jenkins reboot May 26, 2015 8:41:05 AM jenkins.model.Jenkins$23 run INFO: Restart in 10 seconds May 26, 2015 8:41:15 AM jenkins.model.Jenkins$23 run SEVERE: Restarting VM as requested by anonymous Also, after requesting the reboot, say via the http://jenkins/reboot REST call, the application does mark itself as preparing for shutdown but since the reboot never actually happens the service stays in this intermediate state indefinitely. You basically have to log into the server and manually for the service to restart. Add Comment
[JIRA] [core] (JENKINS-23147) Jenkins won't restart itself through the GUI
Title: Message Title Kevin Phillips commented on JENKINS-23147 Re: Jenkins won't restart itself through the GUI One other strategy I tried to work around this issue was to move the Jenkins installation folder to different locations, thinking that maybe putting it under Program Files may have caused some permission issues or something. However even if I relocate the folder to a new folder off the root partition (ie: c:\jenkins ) the same behavior ensues. I only mention it here just in case this helps isolate the cause of the problem. 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] [core] (JENKINS-23147) Jenkins won't restart itself through the GUI
Title: Message Title
Kevin Phillips edited a comment on JENKINS-23147
Re: Jenkins won't restart itself through the GUI
IhavereproducedthissameprobleminthelatestLTSedition(1.596.3atm)onacleanWindows7x64OSaswell.I'musingJava64bitv1.7.0_80-b15incasethatisafactor.I'vetriedsettinguptheJenkinsservicetorununderthelocalsystemaccountaswellasalocaladministrativeuserandneithersettingworkscorrectly.Ihaveconfirmedthatthecommandlineinterfacefortheservice,jenkins.exe,doescorrectlycontroltheWindowsservice.Performingjenkinsstart,jenkinsstop,jenkinsrestart,jenkinsuninstallandjenkinsinstallallworkcorrectlywhenrunfromacommandpromptusingthesamelocaluserprofiletheservicerunswithin.IhavealsotriedexplicitlyaddingWMIpermissionstoallrelevantusers/groupsaswellusingtheprocessfound[here|https://technet.microsoft.com/en-us/library/cc771551.aspx]incasethiswassomekindofsecurityproblembutthathadnoeffecteither.Finally,unlike thedescriptionaboveand otherdefectsintheissuetrackerlikeJENKINS-23395andJENKINS-22685,Iseenoerrorsorwarningsofanykindrelatedtotheservicereboot.InfacttheonlyreferencetotherebootrequestatallinanyofthelogsisthisshortsnippetIfoundinthejenkins.err.logfile:{panel}Jun01,201512:10:43PMjenkins.model.Jenkins$22runSEVERE:RestartingVMasrequestedbyanonymous{panel}IfItryperformingasaferestart(ie:http://jenkins/safeRestart),theresultsarethesamebutIgetacoupleofextralinesintheerrorlogasshownbelow:{panel}May26,20158:41:05AMhudson.model.UpdateCenterdoSafeRestartINFO:SchedulingJenkinsrebootMay26,20158:41:05AMjenkins.model.Jenkins$23runINFO:Restartin10secondsMay26,20158:41:15AMjenkins.model.Jenkins$23runSEVERE:RestartingVMasrequestedbyanonymous{panel}Also,afterrequestingthereboot,sayviathehttp://jenkins/rebootRESTcall,theapplicationdoesmarkitselfaspreparingforshutdownbutsincetherebootneveractuallyhappenstheservicestaysinthisintermediatestateindefinitely.Youbasicallyhavetologintotheserverandmanuallyfortheservicetorestart.
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] [core] (JENKINS-9104) Visual studio builds started by Jenkins fail with Fatal error C1090 because mspdbsrv.exe gets killed
Title: Message Title Kevin Phillips commented on JENKINS-9104 Re: Visual studio builds started by Jenkins fail with Fatal error C1090 because mspdbsrv.exe gets killed Just a quick ping-back on this issue. Outstanding for like 4 years, no comments for months now, and all for a debilitating, crippling problem in the system! I did notice the pull request Daniel Webber created, which does seem to have some more recent activity on it but still no complete resolution to the issue even in the latest LTS release. Are there plans for finishing this work any time soon? We are still stuck on an LTS version from like a year or two ago because we can not accept this bug into our production environment. If there is any way to get this fix in sooner rather than later I know I'd appreciate it and I'm sure many others would 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] [core] (JENKINS-9104) Visual studio builds started by Jenkins fail with Fatal error C1090 because mspdbsrv.exe gets killed
Title: Message Title Kevin Phillips commented on JENKINS-9104 Re: Visual studio builds started by Jenkins fail with Fatal error C1090 because mspdbsrv.exe gets killed PS: Sorry for the rant. My team and I have been aggravated for some time now, hoping this bug would be fixed so we can move off the old version of Jenkins we're currently stuck on and thus able to pick up some new bug fixes both in the core as well as in numerous plugins which only support newer versions. Hopefully I don't come across as overly adversarial. 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] [core] (JENKINS-9104) Visual studio builds started by Jenkins fail with Fatal error C1090 because mspdbsrv.exe gets killed
Title: Message Title Kevin Phillips commented on JENKINS-9104 Re: Visual studio builds started by Jenkins fail with Fatal error C1090 because mspdbsrv.exe gets killed @steve carter First, let me thank you for summarizing the earlier comment threads. That does help bring everything into focus. 4) Jenkins, in order to catch rogue processes at job end (i.e. those that have broken ties with their parent process) scans the whole process space for those with the particular BUILD_ID in their environment, and kills them. This is correct and good behavior by Jenkins. Agreed. This is a perfectly valid and useful enhancement for the majority of cases. However, given the debilitating effect it has on this specific use case combined with the fact that the change was included on an LTS release which is expected to be kept as stable as possible is where I take issue. I see this problem as a bug, albeit a difficult to detect bug and admittedly a bug that is really caused by some questionable behavior provided by the Microsoft build tools, but a bug none the less. In that case critical, production halt kind of bugs like this should be fixed immediately or reverted until an appropriate fix can be made. Doing otherwise reduces users' confidence in the stability of the tool. There is a reason shops like ours choose to use LTS editions for production work - to avoid problems like this that may be found on the latest, cutting edge versions. 8) Solution 1: start pdbsrv with a BUILD_ID that doesn't match the build jobs. Then pdbsrv will not be killed at the end of the job. This should be called a workaround or hack rather than a solution. That point aside, this workaround again won't work for our particular build environment. We use the BUILD_ID throughout our build processes to embed metadata in the binary files we generate. If we reset that environment variable as part of our build this metadata will essentially get corrupted. Changing our tooling to use an alternative environment variable would require significant effort as well, having to be propagated out to dozens of products across several release branches each. 9) Solution 2: use Daniel's whitelist feature to not kill pdbsrv at the end of the job. Based on my review of his pull request, Daniel's feature has not yet been completed nor has it been included in any actual LTS release. I do believe this would be a reasonable and appropriate solution to this defect though, so hopefully this work can be completed sooner rather than later. 10) The problem with Solutions 1 and 2 are this: pdbsrv still has a timeout, so you will get sporadic failures when the server goes away. I know some earlier posters did indicate that this was an issue for them I have not been able to reproduce the problem as described. When a compile begins and this process is running it makes use of the existing process, and if the process is not already running it starts it. I have never had a compile running and seen the mspdbsrv process terminate mid-compile without any other background process or system event occurring. Also, I work with many development teams including many dozens of developers
