[JIRA] [cli] (JENKINS-33942) jenkins-cli.jar: set-build-description command fails with NPE for non-existent build
Title: Message Title Paul Sokolovsky commented on JENKINS-33942 Re: jenkins-cli.jar: set-build-description command fails with NPE for non-existent build Thanks for quick turnaround! 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] [cli] (JENKINS-33943) jenkins-cli.jar: list-changes command produces the same result for non-existent build and build with no changes recorded
Title: Message Title Paul Sokolovsky created an issue Jenkins / JENKINS-33943 jenkins-cli.jar: list-changes command produces the same result for non-existent build and build with no changes recorded Issue Type: Bug Assignee: Unassigned Components: cli Created: 2016/Mar/31 2:46 PM Priority: Minor Reporter: Paul Sokolovsky Running jenkins-cli.jar list-changes gerrit_bot 330 and jenkins-cli.jar list-changes gerrit_bot 830 Where build 330 exists, but has "No changes", and 830 doesn't exist, produces the same result: empty output on stdout, 0 exit code. Success exit code is definitely not ideal in the case of non-existing build. Add Comment
[JIRA] [cli] (JENKINS-33942) jenkins-cli.jar: set-build-description command fails with NPE for non-existent build
Title: Message Title Paul Sokolovsky created an issue Jenkins / JENKINS-33942 jenkins-cli.jar: set-build-description command fails with NPE for non-existent build Issue Type: Bug Assignee: Unassigned Components: cli Created: 2016/Mar/31 2:38 PM Priority: Minor Reporter: Paul Sokolovsky We use "jenkins-cli.jar set-build-description" command for integration with external CI systems - they record build number, do their processing, then post status back to jenkins by updating build description. Sometimes, recorded build number no longer exists (e.g. was expired), and in thsi case, set-build-description command fails with NullPointerException (and exist code of 255). Of course, NPE isn't selective enough to differentiate "build doesn't exist" (warning-like condition) from more serious error which may require closer attention. It would be nice if set-build-description checked build existence, and exited with specific error message and specific exit code for easy scripting. Add Comment
[JIRA] [cli] (JENKINS-33942) jenkins-cli.jar: set-build-description command fails with NPE for non-existent build
Title: Message Title Paul Sokolovsky updated an issue Jenkins / JENKINS-33942 jenkins-cli.jar: set-build-description command fails with NPE for non-existent build Change By: Paul Sokolovsky Labels: cli set-build-description 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] [cli] (JENKINS-29883) set-build-description no longer appends descriptions.
Title: Message Title Paul Sokolovsky commented on JENKINS-29883 Re: set-build-description no longer appends descriptions. As the command name is "set-build-description", not "append-build-description", I'd say the new behavior is correct (though it of course sucks when the behavior changes behind your back). Perhaps, it warrants adding an "--append" flag. 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] [jobconfighistory-plugin] (JENKINS-28413) For some jobs, changes are not displayed after certain day
Title: Message Title Paul Sokolovsky commented on JENKINS-28413 Re: For some jobs, changes are not displayed after certain day We're experiencing the same problem with the plugin version 2.12 (the latest as of now). There's no stacktrace in the log related to affect job, but behavior is the same: all changes past a particular date (2016-02-01 in our case, i.e. it started not long ago), ar enot shown on job history page (https://android-build.linaro.org/jenkins/job/JOBNAME/jobConfigHistory/). Changes are properly recorded in the filesystem. And clicking around, I found that using global "Show all configs" link (https://android-build.linaro.org/jenkins/jobConfigHistory/?filter=all), I see the latest changes done to the affected job. Just the same, I see them in "Show job configs only" (https://android-build.linaro.org/jenkins/jobConfigHistory/?filter=jobs). So, only per-job change listing is affected. Currently, we're aware of a single job which exhibits such behavior, but maybe there's more (but it's definitely not the case that all jobs are affected). Our server is generally public, but this particular job is private, so I can't provide a link to it (and of course, change browsing is not available to anonymous). If there any other information I can provide, let me know. 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] [jobconfighistory-plugin] (JENKINS-29773) stable sort order of AuthorizationMatrixProperty.java
Title: Message Title Paul Sokolovsky commented on JENKINS-29773 Re: stable sort order of AuthorizationMatrixProperty.java It's indeed quite unhelpful to see spurious changes flipping back and forth, so +1 for resolving 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] [ec2-plugin] (JENKINS-27193) EC2 plugin still misdetects not-yet-started slaves, produces zombie slaves
Paul Sokolovsky resolved JENKINS-27193 as Duplicate EC2 plugin still misdetects not-yet-started slaves, produces zombie slaves Duplicate of JENKINS-26797, alternative patch was provided for that issue and was merged. 2 days of running - so far, so good Change By: Paul Sokolovsky (02/Apr/15 6:20 PM) Status: Open Resolved Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ec2-plugin] (JENKINS-27193) EC2 plugin still misdetects not-yet-started slaves, produces zombie slaves
Paul Sokolovsky closed JENKINS-27193 as Duplicate EC2 plugin still misdetects not-yet-started slaves, produces zombie slaves Change By: Paul Sokolovsky (02/Apr/15 6:20 PM) Status: Resolved Closed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-client-plugin] (JENKINS-27093) Spurious gits scm poll change detection
Paul Sokolovsky commented on JENKINS-27093 Spurious gits scm poll change detection Kevin Normoyle: Thanks for this survey and cross-referencing other issues. Just for information, our job, for which this issue was originally reported (https://ci.linaro.org/job/trigger-linux-ltsi), doesn't have branch parametrized, it is set statically in the job config. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-client-plugin] (JENKINS-27093) Spurious gits scm poll change detection
Paul Sokolovsky commented on JENKINS-27093 Spurious gits scm poll change detection I'm totally confused now. I may not be able to reproduce the problem Well, I personally got an impression that the issues we faced might have been related to the fact that between plugin versions upgrades, polling methods changed, and "new" method may have lacked some metadata, not generated by previous method. Something like that. Anyway, I suggested a short-circuit fix for this issue, and it was applied, so just need to wait for 2.36 release (we also have busy production systems, so building and testing debug builds is complicated). We're on Jenkins LTS releases btw (still on 1.580.3, waiting for maintenance window to upgrade to 1.596). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ec2-plugin] (JENKINS-27193) EC2 plugin still misdetects not-yet-started slaves, produces zombie slaves
Paul Sokolovsky commented on JENKINS-27193 EC2 plugin still misdetects not-yet-started slaves, produces zombie slaves @Francis Upton: Any chance you could look at this one-line patch? Thanks in advance! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ec2-plugin] (JENKINS-27193) EC2 plugin still misdetects not-yet-started slaves, produces zombie slaves
Paul Sokolovsky created JENKINS-27193 EC2 plugin still misdetects not-yet-started slaves, produces zombie slaves Issue Type: Bug Assignee: Francis Upton Components: ec2-plugin Created: 02/Mar/15 2:54 PM Description: Background: "Zombie slaves" (build slaves started by EC2 plugin, but not used for builds, and not shutdown properly) has been a problem with EC2 plugin since we started to use it. With older EC2 plugin versions, such slaves were visible in Jenkins, marked as "offline". We upgraded to newer plugin version (from 1.18 to 1.24, then 1.25/1.26) and rejoiced, as zombie slave issues appeared to have been gone. Until we checked our AWS web console and saw bunch of zombie slaves . So, the only change is that they're no longer visible in Jenkins, and thus only harder to notice. So, I went to investigate what's up with it now. Here's typical exception regarding a zombie slave in Jenkins log: Mar 02, 2015 6:36:57 AM hudson.slaves.NodeProvisioner update WARNING: Provisioned slave Kernel cloud (ami-cb2509a2) failed to launch com.amazonaws.AmazonServiceException: The instance ID 'i-ebe58f04' does not exist (Service: AmazonEC2; Status Code: 400; Error Code: InvalidInstanceID.NotFound; Request ID: 2d4058ea-e5ca-44c8-aeb5-08d4fe637d41) at com.amazonaws.http.AmazonHttpClient.handleErrorResponse(AmazonHttpClient.java:886) at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:484) at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:256) at com.amazonaws.services.ec2.AmazonEC2Client.invoke(AmazonEC2Client.java:8798) at com.amazonaws.services.ec2.AmazonEC2Client.createTags(AmazonEC2Client.java:4990) at hudson.plugins.ec2.SlaveTemplate.updateRemoteTags(SlaveTemplate.java:732) at hudson.plugins.ec2.SlaveTemplate.provisionOndemand(SlaveTemplate.java:426) at hudson.plugins.ec2.SlaveTemplate.provision(SlaveTemplate.java:287) at hudson.plugins.ec2.EC2Cloud$1.call(EC2Cloud.java:398) at hudson.plugins.ec2.EC2Cloud$1.call(EC2Cloud.java:394) at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Looking at hudson.plugins.ec2.SlaveTemplate.provisionOndemand(SlaveTemplate.java:426) (https://github.com/jenkinsci/ec2-plugin/blob/master/src/main/java/hudson/plugins/ec2/SlaveTemplate.java#L426), there's already a loop to try to perform operation with sleep between attempts. But it checks for "InvalidInstanceRequestID" error. Note that there was already https://github.com/jenkinsci/ec2-plugin/commit/9a596f0577b29a3e1835143f5d51520babdd7c1f to correct "typo in error code". However, looking at http://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html , there's no "InvalidInstanceRequestID" error selector (as currently in the code), but there's "InvalidInstanceID" (as in the exception above). So the proper fix appears to be to replace error code in https://github.com/jenkinsci/ec2-plugin/blob/master/src/main/java/hudson/plugins/ec2/SlaveTemplate.java#L429 to "InvalidInstanceID.NotFound". Project: Jenkins Priority: Major Reporter: Paul Sokolovsky This message is automatically generated by JIRA. If you think it was sent incorrectly, please
[JIRA] [ec2-plugin] (JENKINS-25029) Service: AmazonEC2; Status Code: 400; Error Code: InvalidInstanceID.NotFound; Request ID: abcdef)
Paul Sokolovsky commented on JENKINS-25029 Service: AmazonEC2; Status Code: 400; Error Code: InvalidInstanceID.NotFound; Request ID: abcdef) Unfortunately, Tomasz' patch never seemed to have worked as expected, see JENKINS-27193 for analysis and (typo/thinko) fix. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ec2-plugin] (JENKINS-27193) EC2 plugin still misdetects not-yet-started slaves, produces zombie slaves
Paul Sokolovsky commented on JENKINS-27193 EC2 plugin still misdetects not-yet-started slaves, produces zombie slaves I did more log grepping and googling, and am now pretty sure analysis above is correct, so I submitted a pull request: https://github.com/jenkinsci/ec2-plugin/pull/137 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-client-plugin] (JENKINS-27093) Spurious gits scm poll change detection
Paul Sokolovsky commented on JENKINS-27093 Spurious gits scm poll change detection As I mentioned, this is pretty busy production system, but I checked with its stakeholders, they've done with release builds for now. So yes, we appreciate your looking into this and can do more testing like deploying test stuff. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-client-plugin] (JENKINS-27093) Spurious gits scm poll change detection with git-plugin 2.3.5 git-client-plugin 1.16.1
Paul Sokolovsky updated JENKINS-27093 Spurious gits scm poll change detection with git-plugin 2.3.5 git-client-plugin 1.16.1 build.xml's from builds #159, #160 of the job above are attached. Change By: Paul Sokolovsky (25/Feb/15 5:10 PM) Attachment: 159-build.xml Attachment: 160-build.xml This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-client-plugin] (JENKINS-27093) Spurious gits scm poll change detection with git-plugin 2.3.5 git-client-plugin 1.16.1
Paul Sokolovsky commented on JENKINS-27093 Spurious gits scm poll change detection with git-plugin 2.3.5 git-client-plugin 1.16.1 Thanks for the replies and commits already made. So, our situation is that we have pretty busy production Jenkins system, so there's only limited experimentation can be done there, and in limited time I had to look into this issue, I traced it just to the source line in the original description above. This is also 1st time I looked into SCM polling, so I don't know how related data is stored and other details. But job we had issues to is actually public: https://ci.linaro.org/job/trigger-linux-ltsi/ . As you can see (note: builds in question may expire in a week or two), from build #132 Feb 23, 2015 11:33:10 AM to build #161 Feb 23, 2015 1:58:09 PM , build triggered every 5 mins, which is SCM polling period for that job. But typical poll log looks like: https://ci.linaro.org/job/trigger-linux-ltsi/160/pollingLog/ (content quoted above in the original description). Kanstantsin: The repo is public, running git command from poll log, I get the expected output (I also thought that maybe there's stray space or something gets parsed, but I confirmed it all looks ok). Will try to look up those build.xml's as a next step. $ /usr/bin/git -c core.askpass=true ls-remote -h git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 8e63197ffe7750c94c8ea9d159ce3e46a76bfcf2 refs/heads/linux-2.6.11.y d04a37911968d919fa842ad40fa9e9ff1dd10904 refs/heads/linux-2.6.12.y 816e9c6c226227c4862b2067aace0f450cc92635 refs/heads/linux-2.6.13.y 789f444285aedfb04af7aa3748aa52e99ac4bd8f refs/heads/linux-2.6.14.y f70602f4f6248735a02c61a1323c9151a33a3775 refs/heads/linux-2.6.15.y 6b0daf99dd2392b024bdca05530e4e761bc3cdae refs/heads/linux-2.6.16.y 78ace17e51d4968ed2355e8f708d233d1cc37f6d refs/heads/linux-2.6.17.y 299a2479bca6211f845158761920ec480f35a229 refs/heads/linux-2.6.18.y 09780ab3b26507776671900e0ed7920f297498ed refs/heads/linux-2.6.19.y f3815da6b4fd508cc3574399248e2e15cb8a617f refs/heads/linux-2.6.20.y a31a9035702124423c3aa5aa848937f165753a4f refs/heads/linux-2.6.21.y 37579d1574f6c18f1f648201c6b0850ac94094cd refs/heads/linux-2.6.22.y 6531868a73a6c91bf0e3e60ded7d1440ee24dfa8 refs/heads/linux-2.6.23.y 928bb8c418b5f9e96dbccc8d7eafb6635ae81548 refs/heads/linux-2.6.24.y 00935daeb04cd54a67b66c9e3babc23389251a98 refs/heads/linux-2.6.25.y 63e0e67b17dc233f93f709610971bbfadc97f75e refs/heads/linux-2.6.26.y bc4e1a77b06519a01e7aed1125695598e27ddeb2 refs/heads/linux-2.6.27.y 5861c853a3f529b9c6a338dd7c4a7afec397ea7a refs/heads/linux-2.6.28.y 12010107aaf417503b7e413d84f2554080aebfe2 refs/heads/linux-2.6.29.y 0d0675cf44c85bd3c0d891845aa02f9249cd7c68 refs/heads/linux-2.6.30.y a389e98d2c6e1900f035befe215f541436bcb0b2 refs/heads/linux-2.6.31.y 3bd0d1ad14c3566107e391732e4df658b005ad67 refs/heads/linux-2.6.32.y 86a705267a2a502a3d62ef0797e449677b25835f refs/heads/linux-2.6.33.y 5878e067ecac4bd2320e933ec485c01190a5b881 refs/heads/linux-2.6.34.y 675f7660ffb0e1880011f6b3c4f9ac241491e3cd refs/heads/linux-2.6.35.y 69ad303ab8321656d6144d13b2444a5595bb6581 refs/heads/linux-2.6.36.y e396c9d8699c95d52b2abcc2d4d5f9616e839734 refs/heads/linux-2.6.37.y 4b7a6d2528bfb625cc359d89ac16439b0ec744ea refs/heads/linux-2.6.38.y ea0dc0dc1c1dca25e50384e300a528db57ee7de5 refs/heads/linux-2.6.39.y 5dba9ddd98cbc7ad319d687887981a0ea0062c75 refs/heads/linux-3.0.y 9bb1282f6a7754955c18be912fbc2b55d133f1b9 refs/heads/linux-3.1.y 5cfc71ce138e79ceb6250f78137dd05ba52e9d34 refs/heads/linux-3.10.y 5ee54f38171b9b3541c5e9cf9c3a9e53455fd8b4 refs/heads/linux-3.11.y 22ccf8f1a5450ac5a6bc2bb519699838017ce1ea refs/heads/linux-3.12.y 2d20120bba8475c963a8d28dd0ffa13637fa3ad7 refs/heads/linux-3.13.y a74f1d1204a5c892466b52ac68ee6443c1e459d7 refs/heads/linux-3.14.y f35b5e46feabab668a44df5b33f3558629f94dfc refs/heads/linux-3.15.y d0335e4feea0d3f7a8af3116c5dc166239da7521 refs/heads/linux-3.16.y bc15d4627aa8f562a1c5ec9d84076b8db25bab31 refs/heads/linux-3.17.y a17f9bf1f7cd3412b9920577a7c0ec34cb81b233 refs/heads/linux-3.18.y bfa76d49576599a4b9f9b7a71f23d73d6dcff735 refs/heads/linux-3.19.y fd623507bdcee1f7a387ae86adb7a66b431dd056 refs/heads/linux-3.2.y 845720650c557a75262b629b0bc228fffcf64638 refs/heads/linux-3.3.y 28895317f9a7d726cd13fc9b5447cb5dcb5cd22c refs/heads/linux-3.4.y f2b152564afdf9c9917c17d1c41c1082c82067bd refs/heads/linux-3.5.y b2824f4e0990716407b0c0e7acee75bb6353febf refs/heads/linux-3.6.y 356d8c6fb2a7cf49e836742738a8b9a47e77cfea
[JIRA] [git-client-plugin] (JENKINS-27093) Spurious gits scm poll change detection with git-plugin 2.3.5 git-client-plugin 1.16.1
Paul Sokolovsky created JENKINS-27093 Spurious gits scm poll change detection with git-plugin 2.3.5 git-client-plugin 1.16.1 Issue Type: Bug Assignee: Nicolas De Loof Components: git-client-plugin, git-plugin Created: 23/Feb/15 7:02 PM Description: We were running jenkins 1.580.2, git-plugin 2.3.3, git-client-plugin 1.15.0, before upgrading to jenkins 1.580.3, git-plugin 2.3.5, git-client-plugin 1.16.1. After the upgrade, some our SCM poll jobs started to behave erratically, as shown by following poll log: Started on Feb 23, 2015 1:33:00 PM Using strategy: Default [poll] Last Built Revision: Revision a74f1d1204a5c892466b52ac68ee6443c1e459d7 (refs/remotes/origin/linux-3.14.y) /usr/bin/git --version # timeout=10 /usr/bin/git -c core.askpass=true ls-remote -h git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git # timeout=10 [poll] Latest remote head revision on origin/linux-3.14.y is: a74f1d1204a5c892466b52ac68ee6443c1e459d7 Done. Took 0.69 sec Changes found So, as the log above shows, "Last Built Revision" and "Latest remote head revision" are the same, and yet "Changes found". And this "Changes found" happened at each poll point (every 5 mins in our case), with build triggering, building that revision, and then doing it over again. After closer look at by job owners, it turned out that after upgrade, this job started to use optimized workspace-less polling (using git ls-remote), whereas previously, it used workspace-ful polling. Looking at https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L590 , turns out that while poll log talks about "Last Built Revision" and "Latest remote head revision", the actual logic for detecting whether change has happened is different. So, "Latest remote head revision" is taken, then some kind of data structure is queried for a build number associated with that change, and if there's no such build, it is triggered. And in our case, apparently exactly this querying part what failed, because otherwise revision values were ok. Summing up: 2.3.5/1.16.1 appear to have made WS-less polling optimization more aggressive, which I don't really see noted in changelog. That's not bad on its own, but apparently that mode has some bugs. In this particular case, the problems can be avoided by adding an extra stop-gap check of "Last Built Revision" and "Latest remote head revision" being equal - if they're, then there're for sure no changes, regardless of presence of detailed revision-to-build mapping. I would recommend plugin maintainers to add such a condition, to make plugin more robust. Thanks! Project: Jenkins Priority: Major Reporter: Paul Sokolovsky This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ec2-plugin] (JENKINS-26531) Slave does not start if the temp dir is not set to anything after upgrade to 1.25
Paul Sokolovsky commented on JENKINS-26531 Slave does not start if the temp dir is not set to anything after upgrade to 1.25 Thumbs up, thanks for quick turnaround. Confirming that upgrading from 1.24 directly to 1.26 works as expected, without any additional actions. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ec2-plugin] (JENKINS-26531) Slave does not start if the temp dir is not set to anything after upgrade to 1.25
Paul Sokolovsky commented on JENKINS-26531 Slave does not start if the temp dir is not set to anything after upgrade to 1.25 yes, it should probably handle the empty temp dir better +1 on that hunch. So, https://github.com/francisu/ec2-plugin/commit/716497f3df642a3e0df097ce05364213179bbb88 is a commit which introduce breakage. Specific line with the issue appers to be: https://github.com/francisu/ec2-plugin/commit/716497f3df642a3e0df097ce05364213179bbb88#diff-634d86776ce3255b6bbd6d5eacf0680aR105 , and the issue is that ".tmpDir != null" construct should be "fixEmpty(tmpDir) != null" (possibly, fixEmptyAndTrim()). @Francis Upton : Please let everyone know if you're working on fixing this critical issue and on driving 1.26 release with the fix ASAP, or if you expect someone else to do that (or something else). Thanks. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-24929) Deleting job via dropdown menu in job list fails due to crumb issues
Paul Sokolovsky created JENKINS-24929 Deleting job via dropdown menu in job list fails due to crumb issues Issue Type: Bug Assignee: Unassigned Components: core Created: 30/Sep/14 3:00 PM Description: To reproduce: 1. From a main Jenkins page, listing jobs, hover mouse over a target job, for dropdown triangle to appear. 2. Click triangle to open dropdown menu. 3. Select "Delete Project". 4. Choose "OK" in confirmation dialog. Error received: HTTP ERROR 403 Problem accessing /jenkins/job/JOB/doDelete. Reason: No valid crumb was included in the request Powered by Jetty:// This looks very similar to JENKINS-18032, but that one apparently happened with "Delete" link on job information page. This one, again, happens in job lists, when using context/dropdown menu. Project: Jenkins Priority: Minor Reporter: Paul Sokolovsky This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [scriptler] (JENKINS-24325) Tokem macro expansion doesn't happen in Run a script parameters
Paul Sokolovsky
created JENKINS-24325
Tokem macro expansion doesnt happen in Run a script parameters
Issue Type:
Bug
Affects Versions:
current
Assignee:
Dominik Bartholdi
Components:
scriptler
Created:
19/Aug/14 12:49 PM
Description:
When running script via "Run a script" action (/scriptler/runScript), it turns out that values supplied to script parameters are not expanded using Token Macro plugin.
This is highly confusing, as the docs page https://wiki.jenkins-ci.org/display/JENKINS/Scriptler+Plugin#ScriptlerPlugin-TokenMacroSupport explicitly says "as a consumer, scriptler accepts tokens in the passed arguments".
Overall, with a freshly installed Jenkins, it is impossible to easily test and try token macro facility. After trying this and that, I finally thought that Scriptler would be my best friend for testing token macros, but turned out to be another wall to bang head against.
So, in the end, it turns out that tokens are expanded in values for Scriptler actions specified as job's build step. Again, they are not expanded when running script directly.
Steps to reproduce:
1. Create a token macro handler in Scriptler itself, based on the example in docs: https://wiki.jenkins-ci.org/display/JENKINS/Scriptler+Plugin#ScriptlerPlugin-TokenMacroSupport
2. Create another Scriptler script with just "println param", then try to run it, setting "param" argument to "${SCRIPTLER, scriptId="superscript.groovy"}"
Expected result: date string to be printed
Actual result: "${SCRIPTLER, scriptId="superscript.groovy"}" is printed literally.
Project:
Jenkins
Priority:
Major
Reporter:
Paul Sokolovsky
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [scriptler] (JENKINS-24325) Token macro expansion doesn't happen in Run a script parameters
Paul Sokolovsky updated JENKINS-24325 Token macro expansion doesnt happen in Run a script parameters Change By: Paul Sokolovsky (19/Aug/14 12:49 PM) Summary: Tokem Token macroexpansiondoesnthappeninRunascriptparameters This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [scriptler] (JENKINS-24325) Scriptler: Token macro expansion doesn't happen in Run a script parameters
Paul Sokolovsky updated JENKINS-24325 Scriptler: Token macro expansion doesnt happen in Run a script parameters Change By: Paul Sokolovsky (19/Aug/14 12:50 PM) Summary: Scriptler: TokenmacroexpansiondoesnthappeninRunascriptparameters This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [crowd2] (JENKINS-19212) Crowd 2 plugin silentlly and confusingly assumes that everyone uses cookie SSO, wants to use SSO, and can use SSO
Paul Sokolovsky commented on JENKINS-19212 Crowd 2 plugin silentlly and confusingly assumes that everyone uses cookie SSO, wants to use SSO, and can use SSO This issue was fixed. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [crowd2] (JENKINS-19212) Crowd 2 plugin silentlly and confusingly assumes that everyone uses cookie SSO, wants to use SSO, and can use SSO
Paul Sokolovsky resolved JENKINS-19212 as Fixed Crowd 2 plugin silentlly and confusingly assumes that everyone uses cookie SSO, wants to use SSO, and can use SSO Change By: Paul Sokolovsky (06/Mar/14 6:52 AM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [ssh-slaves] (JENKINS-7641) Slaves hang when archiving artifacts
Paul Sokolovsky commented on JENKINS-7641 Slaves hang when archiving artifacts Woo-hoo, the patch in the previous comment works: 00:18:59.873 FATAL: HTML Publisher failure 00:18:59.873 hudson.util.IOException2: hudson.util.IOException2: Failed to extract /srv/jenkins/workspace/job/doc/html/*/ 00:18:59.873 at hudson.FilePath.readFromTar(FilePath.java:2066) 00:18:59.873 at hudson.FilePath.copyRecursiveTo(FilePath.java:1978) 00:18:59.873 at hudson.FilePath.copyRecursiveTo(FilePath.java:1889) 00:18:59.873 at hudson.FilePath.copyRecursiveTo(FilePath.java:1872) 00:18:59.873 at htmlpublisher.HtmlPublisher.perform(HtmlPublisher.java:213) 00:18:59.873 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 00:18:59.873 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:785) 00:18:59.873 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:757) 00:18:59.873 at hudson.model.Build$BuildExecution.post2(Build.java:183) 00:18:59.873 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:706) 00:18:59.873 at hudson.model.Run.execute(Run.java:1690) 00:18:59.873 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) 00:18:59.873 at hudson.model.ResourceController.execute(ResourceController.java:88) 00:18:59.873 at hudson.model.Executor.run(Executor.java:246) 00:18:59.873 Caused by: java.io.IOException: High-level timeout waiting for activity on pipe 00:18:59.873 at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:180) 00:18:59.873 at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61) 00:18:59.873 at com.jcraft.jzlib.InflaterInputStream.fill(InflaterInputStream.java:175) 00:18:59.873 at com.jcraft.jzlib.InflaterInputStream.read(InflaterInputStream.java:106) 00:18:59.873 at org.apache.tools.tar.TarBuffer.readBlock(TarBuffer.java:257) 00:18:59.873 at org.apache.tools.tar.TarBuffer.readRecord(TarBuffer.java:223) 00:18:59.873 at hudson.org.apache.tools.tar.TarInputStream.getNextEntry(TarInputStream.java:228) 00:18:59.873 at hudson.FilePath.readFromTar(FilePath.java:2044) 00:18:59.873 ... 13 more So, the timeout as it is now is 1000s. Trying to cut that in 2 and see if any false positive timeouts would happen. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [ssh-slaves] (JENKINS-7641) Slaves hang when archiving artifacts
Paul Sokolovsky commented on JENKINS-7641 Slaves hang when archiving artifacts Ok, so this is probably as old as Jenkins itself, and probably ready to become (if not already) its businesscard - what's that Jenkins thing? Ah, it does some CI and bunch of server hanging around. And the biggest problem is not that the issue described here happens, it's what shown by this log: 01:53:56.709 Archiving artifacts 12:02:21.094 ERROR: Failed to archive artifacts: *.sum 12:02:21.096 hudson.util.IOException2: hudson.util.IOException2: Failed to extract /home/buildslave/workspace/cbuild/transfer of 1 files 12:02:21.096 Caused by: java.io.IOException 12:02:21.096 at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:175) So, it hanged build server for 10hrs. As it usually happens, there're more jobs accumulate for this build slave, other builds waiting for this build to complete, so entire CI system comes to a halt, followed by kaboom. And if nobody's looking, Jenkins will happily and shamelessly lock up your servers for days. So, why this happens? Surely, there's no single reason, but carefully selected assorti of toxic stuff: 1. Bugs in JVM/Java - just because there're comments above that switching to another JDK version/provider seem to alleviate it. 2. Bugs in Jenkins - just because every new release brings only security fixes as if previous version was something like 0.0.1, so you may imagine there's lot to fix yet. 3. But most importantly, that's the way Jenkins is written. To illustrate that, let's look at linked JENKINS-11586, comment straight from Kohsuke: "The ping currently is supposed to wait for 4 minutes before it gives up and kills the channel. But I have a hard time believing that the channel did really clog for 4 minutes." Here we go. Network over which that channel goes is UNRELIABLE. Everything you find hard to believe about it is actually true. It may fail to deliver stuff, it may clog for 4 or 40 minutes, RIAA may knock on your door telling you download forbidden torrents which you never did. Or take another example, straight from FastPipedInputStream.java as quoted in stacktrace above. In its header, it confesses to be java.io.PipedInputStream equivalent, which just "uses proper synchronization" and "doesn't rely on polling". A seasonal engineer would recognize smartness and forthlooking of Java engineers who did not trust Java to do synchronization and instead used strings-and-stick method. Now smart kids came who thought they could make it better, and now their code locks up servers throughout the world. Ok, enough intro to problem area. Let's look straight into FastPipedInputStream.java:175 which was caught red-handed in the stacktrace above: https://github.com/jenkinsci/remoting/blob/master/src/main/java/hudson/remoting/FastPipedInputStream.java#L163 And what we see immediately is infinite loop. Just see yourself: it blocks in wait on buffer for 10s, then does some liveness checks (which, as we already learned, will fail to detect any issues regularly), the checks for updates from outside, and if nothing happens, it will hang there forever. Here it is, Jenkins coding style. Here's the patch: https://github.com/pfalcon/remoting/commit/239b3dcf26498ff296fabf770dffc7a456b2878c So, why am I writing all this? Over time, I learned that if people come to me with artifact archiving issues, the best thing I can suggest them is AVOID NATIVE JENKINS ARTIFACT ARCHIVING LIKE A PLAGUE. People listen, and that job whose stack trace is quoted above is no longer uses it (rest of our jobs didn't use it for years). So, while I hacked up the patch above, I don't really have sandbox to test it with. So, if you experience this issue, I encourage you to try that patch and share results. Just to clarify - the patch above is not going to fix this issue (if you want it not fail, then Java and Jenkins are wrong technologies). But instead it makes it fail fast and not waste the resources (it also addresses only one infinite loop, I'm sure there're dozens more). The stacktrace above happened with Jenins 1.532.1 on Linux/Ubuntu master/slave (x86, x64, arm slaves affected). Thanks for listening to the rant, and happy (or sour) Jenkinsing! This message is automatically generated by JIRA. If you think it was sent incorrectly,
[JIRA] (JENKINS-15239) Tags feature is broken
Paul Sokolovsky commented on JENKINS-15239 Tags feature is broken Confirming the same happens for us. Stacktrace looks the same, not even trying to paste it here. Please fix . This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-6604) Possible race condition in RemoteClassLoader renders slave unusable
[
https://issues.jenkins-ci.org/browse/JENKINS-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=160396#comment-160396
]
Paul Sokolovsky commented on JENKINS-6604:
--
We started to see these issues today with EC2 build slaves, haven't ever seen
errors like this before for a year we run this infrastructure. The only change
happened before today is that some additional plugins were installed. We're
still on Jenkins 1.419.
Possible race condition in RemoteClassLoader renders slave unusable
---
Key: JENKINS-6604
URL: https://issues.jenkins-ci.org/browse/JENKINS-6604
Project: Jenkins
Issue Type: Bug
Components: core
Affects Versions: current
Environment: CentOS 5.3, Sun JDK 1.6.0_19 64-bit
Reporter: michal_grzejszczak
Priority: Minor
We are restarting hudson each Sunday afternoon to evade problems with memory
leaks and have a couple of nightly builds that kick in at midnight. The
scenario is that Hudson is fresh when multiple builds kick in, that is its
remote class loader did not have a chance to read any classes yet. We have 3
executors defined. I suppose that the SCM poll action that is sent in many
build procedures causes multiple requests to load classes for the SCM (we use
slightly hacked version of CVS SCM). We are getting the following exception:
java.lang.LinkageError: loader (instance of
hudson/remoting/RemoteClassLoader): attempted duplicate class definition for
name: hudson/model/ModelObject
I have looked around on the web and found this
(http://jira.codehaus.org/browse/JETTY-418) that lead me to believe that lack
of synchronization while loading classes in remote class loader is the cause.
Full stack trace:
{code}
Started on May 24, 2010 12:00:54 AM
FATAL: remote file operation failed: /home/hudson-slave/workspace/BPE_8.1SR
at hudson.remoting.Channel@1219b8c:slave-81
hudson.util.IOException2: remote file operation failed:
/home/hudson-slave/workspace/BPE_8.1SR at
hudson.remoting.Channel@1219b8c:slave-81
at hudson.FilePath.act(FilePath.java:743)
at hudson.FilePath.act(FilePath.java:729)
at com.syncron.hudson.cvs2.CVS2.isUpdatable(CVS2.java:813)
at com.syncron.hudson.cvs2.CVS2.pollChanges(CVS2.java:310)
at hudson.scm.SCM.poll(SCM.java:370)
at hudson.model.AbstractProject.poll(AbstractProject.java:1153)
at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:330)
at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:359)
at
hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: Remote call on slave-81 failed
at hudson.remoting.Channel.call(Channel.java:560)
at hudson.FilePath.act(FilePath.java:736)
... 14 more
Caused by: java.lang.LinkageError: loader (instance of
hudson/remoting/RemoteClassLoader): attempted duplicate class definition for
name: hudson/model/ModelObject
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.lang.ClassLoader.defineClass(ClassLoader.java:466)
at
hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:151)
at
hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:131)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.lang.ClassLoader.defineClass(ClassLoader.java:466)
at
hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:151)
at
hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:131)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2291)
at java.lang.Class.getDeclaredField(Class.java:1880)
at
