[JIRA] (JENKINS-57025) Unable to pull hooks in github organization folder type
Title: Message Title John Mellor commented on JENKINS-57025 Re: Unable to pull hooks in github organization folder type This used to work, but failed sometime in the last 6 months of plugin changes. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57025) Unable to pull hooks in github organization folder type
Title: Message Title John Mellor commented on JENKINS-57025 Re: Unable to pull hooks in github organization folder type Job discovery in a github organization folder works correctly. Discovery of the PR and other branches works as expected. Manual builds of these jobs also works as expected. However, the PR verification builds are not being triggered, and instead give the traceback about not being able to find a post-commit hook to download. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57025) Unable to pull hooks in github organization folder type
Title: Message Title John Mellor edited a comment on JENKINS-57025 Re: Unable to pull hooks in github organization folder type It would appear that projects with a dedicated config seem to work ok. However, projects that inherit their config from the parent organization folder always get it wrong, and the hook pulls fail. So, projects that directly have their own config.xml (multibranch builds, ad-hoc builds) function correctly, but github organization type do not. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57025) Unable to pull hooks in github organization folder type
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-57025 Unable to pull hooks in github organization folder type Change By: John Mellor Summary: Unable to pull hooks in github user incorrectly constructed, org name being assumed organization folder type Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57025) github user incorrectly constructed, org name being assumed
Title: Message Title John Mellor commented on JENKINS-57025 Re: github user incorrectly constructed, org name being assumed It would appear that projects with a dedicated config seem to work ok. However, projects that inherit their config from the parent organization folder always get it wrong, and the hook pulls fail. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57025) github user incorrectly constructed, org name being assumed
Title: Message Title John Mellor created an issue Jenkins / JENKINS-57025 github user incorrectly constructed, org name being assumed Issue Type: Bug Assignee: Kirill Merkushev Components: github-plugin Created: 2019-04-16 16:38 Environment: Fully updated Jenkins LTS with fully-updated plugins. Jenkins 2.164.2 Installed plugins are as follows: Datadog Plugin (datadog): 0.7.1 REST API for Blue Ocean (blueocean-rest): 1.14.0 Active Choices Plug-in (uno-choice): 2.1 Config File Provider Plugin (config-file-provider): 3.6 Build Monitor View (build-monitor-plugin): 1.12+build.201809061734 Pipeline: Nodes and Processes (workflow-durable-task-step): 2.30 Trilead API Plugin (trilead-api): 1.0.3 Pipeline: Basic Steps (workflow-basic-steps): 2.15 user build vars plugin (build-user-vars-plugin): 1.5 Authentication Tokens API Plugin (authentication-tokens): 1.3 Gitlab Hook Plugin (gitlab-hook): 1.4.2 Infrastructure plugin for Publish Over X (publish-over): 0.22 REST Implementation for Blue Ocean (blueocean-rest-impl): 1.14.0 Rebuilder (rebuild): 1.30 Kubernetes plugin (kubernetes): 1.14.9 Pipeline: Stage Tags Metadata (pipeline-stage-tags-metadata): 1.3.8 Mailer Plugin (mailer): 1.23 Javadoc Plugin (javadoc): 1.5 Git Pipeline for Blue Ocean (blueocean-git-pipeline): 1.14.0 JWT for Blue Ocean (blueocean-jwt): 1.14.0 ruby-runtime (ruby-runtime): 0.12 Pipeline SCM API for Blue Ocean (blueocean-pipeline-scm-api): 1.14.0 Git client plugin (git-client): 2.7.7 Credentials Binding Plugin (credentials-binding): 1.18 Shared Objects Plugin (shared-objects): 0.44 Gerrit Trigger (gerrit-trigger): 2.29.0 Environment Injector Plugin (envinject): 2.1.6 GitLab Plugin (gitlab-plugin): 1.5.11 bouncycastle API Plugin (bouncycastle-api): 2.17 Configuration as Code Plugin (configuration-as-code): 1.11 Pipeline (workflow-aggregator): 2.6 Pipeline: Declarative Extension Points API (pipeline-model-extensions): 1.3.8 Variant Plugin (variant): 1.2 Build With Parameters (build-with-parameters): 1.4 Display URL API (display-url-api): 2.3.1 Job Configuration History Plugin (jobConfigHistory): 2.20 Plain Credentials Plugin (plain-credentials): 1.5 Metrics Plugin (metrics): 4.0.2.3 Run Condition Plugin (run-condition): 1.2 GitHub Branch Source Plugin (github-branch-source): 2.4.5 JSch dependency plugin (jsch): 0.1.55 JDK Tool Plugin (jdk-tool): 1.2 Matrix Project Plugin (matrix-project): 1.14 Pipeline: AWS Steps (pipeline-aws): 1.36 Config API for Blue Ocean (blueocean-config): 1.14.0 JIRA plugin (jira): 3.0.6 AnsiColor (ansicolor): 0.6.2 Cppcheck Plug-in (cppcheck): 1.24 WMI Windows Agents
[JIRA] (JENKINS-54864) github multibranch builds fail to build with latest branch api update
Title: Message Title John Mellor commented on JENKINS-54864 Re: github multibranch builds fail to build with latest branch api update Instead of suggesting that people apply the workaround, having to fix hundreds of thousands of jobs worldwide, how about just reverting the breaking change? I alone have 3570 jobs to inspect and make a code change to because of this error. How do I get back to the point of NOT having to make this change, and simply have the github functionality work as expected? Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54864) github multibranch builds fail to build with latest branch api update
Title: Message Title John Mellor commented on JENKINS-54864 Re: github multibranch builds fail to build with latest branch api update Thanks Steve, but I still do not have enough context. I do not have that section in the job configs like you do. What plugin provides that configuration section? Screenshot of what I see attached. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54864) github multibranch builds fail to build with latest branch api update
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-54864 github multibranch builds fail to build with latest branch api update Change By: John Mellor Attachment: Screenshot from 2018-12-11 11-54-26.png Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54864) github multibranch builds fail to build with latest branch api update
Title: Message Title John Mellor commented on JENKINS-54864 Re: github multibranch builds fail to build with latest branch api update Sorry for being obtuse, but pull requests ARE in the build stategies already. I do not see what I should have to add to all the jobs. Typical job screenshot attached. What needs to be added? Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54864) github multibranch builds fail to build with latest branch api update
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-54864 github multibranch builds fail to build with latest branch api update Change By: John Mellor Attachment: Screenshot from 2018-12-11 08-53-26.png Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54864) github multibranch builds fail to build with latest branch api update
Title: Message Title John Mellor commented on JENKINS-54864 Re: github multibranch builds fail to build with latest branch api update Can someone please detail the alleged workaround details? I do not see the config sections noted by Steve Mason and Jon Tancer in either of my sites. I see the note above explaining what I should alter in the github section config when I use the deprecated and replaced organization plugin, but not how to do this in an up-to-date system. Is it possible to perform a workaround without using the do-not-use plugins? Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54864) github multibranch builds fail to build with latest git plugin update
Title: Message Title John Mellor created an issue Jenkins / JENKINS-54864 github multibranch builds fail to build with latest git plugin update Issue Type: Bug Assignee: Mark Waite Components: git-plugin Created: 2018-11-26 16:34 Environment: Jenkins 2.138.3 on Ubuntu git plugin 3.9.1 and branch api plugin 2.1.1 is broken. git plugin 3.9.0 and branch api plugin 2.0.21 is ok. Priority: Blocker Reporter: John Mellor The latest updates broke github multibranch builds. The branches are being discovered, but all automaticdiscovery of all new changes on all branches results in the following typical log entries: Checking pull-requests... Checking pull request #3 ‘Jenkinsfile’ found
[JIRA] (JENKINS-53432) Unable to automatically discover and build git tags with Jenkins multibranch pipelines and the Git Plugin
Title: Message Title John Mellor commented on JENKINS-53432 Re: Unable to automatically discover and build git tags with Jenkins multibranch pipelines and the Git Plugin With the latest set of updates, multibranch is discovering all branches like it should, but skipping all builds not manually triggered. Critical issue. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53319) Restart after plugin updates not respecting jobs in progress
Title: Message Title
John Mellor edited a comment on JENKINS-53319
Re: Restart after plugin updates not respecting jobs in progress
Excerpt from a failed build log, showing inability to complete:{quote}[info] Compiling 2 Scala sources to /var/lib/jenkins/workspace/teel-alert-processor_master-BGGUGXUXB6BJYZHP7P65LURLIXLCLTBTC2GMBJEPRV4HZIHOCW4A/processor/target/scala-2.12/test-classes ...Resuming build at Wed Aug 29 08:29:31 EDT 2018 after Jenkins restartWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: ???Cannot contact sbt1: hudson.remoting.ChannelClosedException: Channel "unknown": Remote call on sbt1 failed. The channel is closing down or has closed downWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineWaiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offlineReady to run at Wed Aug 29 08:38:05 EDT 2018[Pipeline] }[Pipeline] // stage[Pipeline] }[Pipeline] // node[Pipeline] End of Pipeline GitHub has been notified of this commit’s build resultERROR: missing workspace /var/lib/jenkins/workspace/teel-alert-processor_master-BGGUGXUXB6BJYZHP7P65LURLIXLCLTBTC2GMBJEPRV4HZIHOCW4A on sbt1Finished: FAILURE {quote}
Add Comment
[JIRA] (JENKINS-53319) Restart after plugin updates not respecting jobs in progress
Title: Message Title John Mellor commented on JENKINS-53319 Re: Restart after plugin updates not respecting jobs in progress Excerpt from a failed build log, showing inability to complete: [info] Compiling 2 Scala sources to /var/lib/jenkins/workspace/teel-alert-processor_master-BGGUGXUXB6BJYZHP7P65LURLIXLCLTBTC2GMBJEPRV4HZIHOCW4A/processor/target/scala-2.12/test-classes ... Resuming build at Wed Aug 29 08:29:31 EDT 2018 after Jenkins restart Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: ??? Cannot contact sbt1: hudson.remoting.ChannelClosedException: Channel "unknown": Remote call on sbt1 failed. The channel is closing down or has closed down Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Waiting to resume part of Advanced Threat Analytics » bluesteel-alert-processor » master #34: sbt1 is offline Ready to run at Wed Aug 29 08:38:05 EDT 2018 [Pipeline] } [Pipeline] // stage [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Add Comment
[JIRA] (JENKINS-53319) Restart after plugin updates not respecting jobs in progress
Title: Message Title John Mellor created an issue Jenkins / JENKINS-53319 Restart after plugin updates not respecting jobs in progress Issue Type: Bug Assignee: Unassigned Attachments: yyy Components: core Created: 2018-08-29 12:48 Environment: up-to-date Jenkins 2.121.3 on Ubuntu-16 Labels: regression Priority: Major Reporter: John Mellor A normal restart after plugin updates is not respecting pipeline jobs in progress. Example pipeline attached. This job aborted in the middle of the "Build and test" stage. Add Comment
[JIRA] (JENKINS-51049) Folders Plugin GitHub Scanning Time not being copied into the Jobs
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-51049 Folders Plugin GitHub Scanning Time not being copied into the Jobs Change By: John Mellor Labels: plugin regression scm Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51049) Folders Plugin GitHub Scanning Time not being copied into the Jobs
Title: Message Title John Mellor commented on JENKINS-51049 Re: Folders Plugin GitHub Scanning Time not being copied into the Jobs I upgraded to Jenkins 2.118 overnight, and picked up a dozen small updates to the plugins at the same time. The problem behaviour is unaltered. Attaching a slightly-redacted folder config and typical subjob config that has the problem per request. Looking back, I cannot locate a job where this is working, so I am unsure when it broke. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51049) Folders Plugin GitHub Scanning Time not being copied into the Jobs
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-51049 Folders Plugin GitHub Scanning Time not being copied into the Jobs Change By: John Mellor Attachment: subjob_config.xml Attachment: folder_config.xml Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51049) Folders Plugin GitHub Scanning Time not being copied into the Jobs
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-51049 Folders Plugin GitHub Scanning Time not being copied into the Jobs Change By: John Mellor The Folders Plugin is not replicating required information into the sub-jobs.The Folders plugin is used in a Multi-Configuration project for multiple related jobs. The job configuration is specified in the folder, and prints-thru into the individual job configurations. However, the github scan time is not replicating into the jobs, and is instead defaulting to an unacceptable 1-hour for unknown reasons. It is not possible to alter the individual job configurations to compensate for plugin defects, as there is no save button on the sub-jobs. Screenshots are attached of (a) an offending folder an showing the requested 5-minute scan time, and (b) a typical folder sub- job showing the misconfiguration are attached and defaulting to 1-hour instead of the 5-minutes specified in the folder .This error makes the jobs almost unusable for normal development purposes, as source scans only occur a few times per day. Critical error. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
[JIRA] (JENKINS-51049) Folders Plugin GitHub Scanning Time not being copied into the Jobs
Title: Message Title John Mellor created an issue Jenkins / JENKINS-51049 Folders Plugin GitHub Scanning Time not being copied into the Jobs Issue Type: Bug Assignee: Devin Nusbaum Attachments: Screenshot from 2018-04-30 15-35-34.png, Screenshot from 2018-04-30 15-36-14.png Components: cloudbees-folder-plugin Created: 2018-04-30 19:39 Environment: Cloudbees Folders Plugin 6.4 Jenkins 2.114 Ubuntu 14.04 w/ full updates Labels: plugin scm regression Priority: Blocker Reporter: John Mellor The Folders Plugin is not replicating required information into the sub-jobs. The Folders plugin is used in a Multi-Configuration project for multiple related jobs. The job configuration is specified in the folder, and prints-thru into the individual job configurations. However, the github scan time is not replicating into the jobs, and is instead defaulting to an unacceptable 1-hour for unknown reasons. It is not possible to alter the individual job configurations to compensate for plugin defects, as there is no save button on the sub-jobs. Screenshots of an offending folder an a job showing the misconfiguration are attached. This error makes the jobs almost unusable for normal development purposes, as source scans only occur a few times per day. Critical error.
[JIRA] (JENKINS-47821) vsphere plugin 2.16 not respecting slave disconnect settings
Title: Message Title John Mellor commented on JENKINS-47821 Re: vsphere plugin 2.16 not respecting slave disconnect settings The target vsphere cloud is running an esxi-5.5 cluster managed by vcenter-5.5, and using unshared local disks in RAID-6 as the VMFS volumes. Not sure what else I can give you. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-47821) vsphere plugin 2.16 not respecting slave disconnect settings
Title: Message Title John Mellor commented on JENKINS-47821 Re: vsphere plugin 2.16 not respecting slave disconnect settings Name of this Cloud: QA Cluster vSphere Host: https://vsphere.internal Disable Certificate Verification: checked Credentials: Templates: FYI, There are several types of clouds configured at this site: google, vmware, k8s, etc. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-47821) vsphere plugin 2.16 not respecting slave disconnect settings
Title: Message Title John Mellor commented on JENKINS-47821 Re: vsphere plugin 2.16 not respecting slave disconnect settings For some reason, I am unable to screenshot a typical config into this ticket. When I configure a high-use build node, I generally set it up for: Availability: Take this agent online when in demand, and offline when idle Disconnect after limited builds: 1 What to do when the slave is disconnected: Revert and Restart If it is a low-use node, then I instead configure for: What to do when the slave is disconnected: Shutdown Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-47821) vsphere plugin 2.16 not respecting slave disconnect settings
Title: Message Title John Mellor commented on JENKINS-47821 Re: vsphere plugin 2.16 not respecting slave disconnect settings With the limited testing that I've been able to perform, it looks like this change is provisionally not working. If I queue up multiple jobs for a single node, and configure the node to do nothing upon end-of-job and reset back to snapshot upon startup, then I do not see an expected reset-to-startup between each job. It looks like it just starts the job on the already-polluted machine and skips the reset-to-snapshot for some reason. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-47821) vsphere plugin 2.16 not respecting slave disconnect settings
Title: Message Title John Mellor commented on JENKINS-47821 Re: vsphere plugin 2.16 not respecting slave disconnect settings Yes, exactly. I never do incremental builds as they are a severely-broken dev practice. I typically setup a node to disconnect after one build, and reset back to a vmware snapshot upon restart. That way I can easily debug a build problem because the machine is left in the state where the build failed, and the next job does not have artifacts present like dependency packages, config files or docker images added by the previous build. However I am now in a situation where sometimes a queued build runs on the node without going through the reset-back-to-snapshot step, breaking it. I have a crude workaround of powering the node down after every build, forcing it to go through the power-up steps which will then revert back to snapshot. However, this maximizes the downtime for the node between builds, and prevents some debugging actions because you lose the in-memory structures this way. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49750) Promoted Builds plugin fails to trigger a downstream job
Title: Message Title John Mellor closed an issue as Fixed The update to 3.0.0 corrects the issue. Thanks Oleg!!! Jenkins / JENKINS-49750 Promoted Builds plugin fails to trigger a downstream job Change By: John Mellor Status: Open Closed Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit
[JIRA] (JENKINS-49750) Promoted Builds plugin fails to trigger a downstream job
Title: Message Title John Mellor edited a comment on JENKINS-49750 Re: Promoted Builds plugin fails to trigger a downstream job The update to 3.0 .0 corrects the issue. Thanks Oleg!!! Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49750) Promoted Builds plugin fails to trigger a downstream job
Title: Message Title John Mellor created an issue Jenkins / JENKINS-49750 Promoted Builds plugin fails to trigger a downstream job Issue Type: Bug Assignee: Oleg Nenashev Attachments: Screenshot from 2018-02-26 11-31-49.png, Screenshot from 2018-02-26 11-44-28.png, Screenshot from 2018-02-26 11-46-05.png Components: promoted-builds-plugin Created: 2018-02-26 16:50 Environment: Jenkins 2.108, Promoted Builds Plugin 2.31.1, Ubuntu 16.04.3 Labels: plugin Priority: Major Reporter: John Mellor The Promoted Builds plugin does not trigger a downstream job, even though it is configured to do just that. We are using the promotion step to trigger a deployment job. We can see that the promotion step runs, but the job is not triggered. There are no corresponding system log entries noted, and no errors in the promotion. Screenshot of the (a) promotion step attached, (b) promotion screen and (c) promotion log showing the missing job triggering action. Note that it does nothing other than trigger this job, but instead it silently ignores the triggering.
[JIRA] (JENKINS-20342) Jenkins 1.536 fails to load plugin ruby-runtime
Title: Message Title John Mellor commented on JENKINS-20342 Re: Jenkins 1.536 fails to load plugin ruby-runtime Still happening in Jenkins 2.108 Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49741) Failure to load ruby-runtime-plugin
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-49741 Failure to load ruby-runtime-plugin Change By: John Mellor Environment: Jenkins 2.108, Gerrit Trigger Gitlab hook plugin 2 1 . 27.3 42 , 2.27.5, Ubuntu 16.04.3 Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49741) Failure to load ruby-runtime-plugin
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-49741 Failure to load ruby-runtime-plugin Change By: John Mellor Failure to install ruby-runtime plugin due to NPE.The ruby runtime plugin is a prerequisite for the gerrit trigger gitlab hook plugin, breaking it as well.Traceback during plugin updates screen shot attached. Blocking issue. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49741) Failure to load ruby-runtime-plugin
Title: Message Title John Mellor created an issue Jenkins / JENKINS-49741 Failure to load ruby-runtime-plugin Issue Type: Bug Assignee: R. Tyler Croy Attachments: Screenshot from 2018-02-26 08-47-18.png Components: ruby-runtime-plugin Created: 2018-02-26 13:57 Environment: Jenkins 2.108, Gerrit Trigger plugin 2.27.3, 2.27.5, Ubuntu 16.04.3 Priority: Blocker Reporter: John Mellor Failure to install ruby-runtime plugin due to NPE. The ruby runtime plugin is a prerequisite for the gerrit trigger plugin, breaking it as well. Traceback during plugin updates screen shot attached. Blocking issue. Add Comment
[JIRA] (JENKINS-49513) pipeline finally not reporting errors
Title: Message Title
John Mellor created an issue
Jenkins / JENKINS-49513
pipeline finally not reporting errors
Issue Type:
Bug
Assignee:
Unassigned
Components:
pipeline
Created:
2018-02-12 17:56
Environment:
Jenkins 2.101 on Ubuntu-16.04.3, pipeline 2.5, pipeline API 2.24
Priority:
Major
Reporter:
John Mellor
Finally in a pipeline does not report critical errors, leading to mysterious failures. E.g: this following pipeline excerpt does not construct the dependency-check-report.html file for archiving, and no error is logged. However, the build silently fails as a result. try { stage('Build and test') { sh 'sbt -no-colors rebuild doc swaggerJson manifest' } } finally { stage('Archive coverage report') { archiveArtifacts "target/scala-2.12/scoverage-report/**" publishHTML(target: [reportName: "Code coverage report", reportDir: "target/scala-2.12/scoverage-report", reportFiles: "index.html"]) } stage('Archive vulnerability report') { archiveArtifacts "target/scala-2.12/dependency-check-report.html" publishHTML(target: [reportName: "Vulnerabilty report", reportDir: "target/scala-2.12", reportFiles: "dependency-check-report.html"]) } }
[JIRA] (JENKINS-41339) Environment variables referencing other variables broken
Title: Message Title John Mellor commented on JENKINS-41339 Re: Environment variables referencing other variables broken Confirmed, restart needed after downgrading. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41339) Environment variables referencing other variables broken
Title: Message Title John Mellor commented on JENKINS-41339 Re: Environment variables referencing other variables broken I do not see a 1.14 plugin available, so I assume that this fix is in fact not released yet. As per the conversation in https://groups.google.com/forum/#!msg/jenkinsci-users/LN057YL_Xis/wyIBfAbfCwAJ, I downgraded the durable tasks plugin from 1.13 to 1.12 and the pipeline plugins to try to work around this killer bug. Interestingly, this apparently does not require a reboot (not sure if that is another bug or not). However, after reverting the plugin, I still cannot run simple shell commands as part of the pipeline. How do I get back to working pipelines? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41457) thread dump via signal not working on master node
Title: Message Title John Mellor created an issue Jenkins / JENKINS-41457 thread dump via signal not working on master node Issue Type: Bug Assignee: Unassigned Components: core Created: 2017/Jan/25 10:09 PM Environment: Ubuntu, openjdk-7, Jenkins 1.656 Priority: Minor Reporter: John Mellor Unable to obtain a thread dump when Jenkins is stuck coming up. According to https://wiki.jenkins-ci.org/display/JENKINS/Obtaining+a+thread+dump you should be able to obtain a thread dump by sending SIGQUIT on the master node. While the PID of Jenkins changes (indicating that SIGQUIT was acted upon), no thread dump is observed on stdout/stderr or /var/log/jenkins/jenkins.log. Since I am trying to diagnose why the Jenkins takes 2hrs to start up, the /threadDump method in the GUI is not suitable in this case. Add Comment
[JIRA] (JENKINS-41260) Docker Image Removal Prevents Job Email emission
Title: Message Title John Mellor created an issue Jenkins / JENKINS-41260 Docker Image Removal Prevents Job Email emission Issue Type: Bug Assignee: Nicolas De Loof Attachments: Capture.PNG Components: docker-custom-build-environment-plugin Created: 2017/Jan/20 3:31 PM Environment: Ubuntu, Jenkins 1.656, openjdk-7-jre-headless 7u121-2.6.8-1ubuntu0.12.04.1, CloudBees Docker Custom Build Environment Plugin 1.6.5, Email Extension Plugin 2.63 Labels: plugin robustness Priority: Major Reporter: John Mellor I have a long-running test sequence that runs every night in a Docker image, and sends the build email to a Dev at the end. The Docker image appears to be torn down immediately after the run finishes and there is no apparent means of waiting for the master node to do its final actions like sending the post-build step emails before teardown. The email that triggers other non-Jenkins actions is not sent. The only /var/log/jenkins/jenkins.log log entry near the end of the job appears to be unrelated: a GC error of unknown cause: Jan 20, 2017 5:27:53 AM hudson.remoting.Channel export WARNING: Unable to send GC command hudson.remoting.ChannelClosedException: channel is already closed
[JIRA] (JENKINS-39920) Pipeline job type has no ability to specify the node labels it can run on
Title: Message Title John Mellor resolved as Fixed I added the label as noted, and it works. Thanks! Jenkins / JENKINS-39920 Pipeline job type has no ability to specify the node labels it can run on Change By: John Mellor Status: Open Resolved Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit
[JIRA] (JENKINS-39921) Pipeline job type unable to run in specified docker image
Title: Message Title John Mellor created an issue Jenkins / JENKINS-39921 Pipeline job type unable to run in specified docker image Issue Type: Bug Assignee: Unassigned Components: pipeline-build-step-plugin Created: 2016/Nov/21 8:24 PM Environment: Jenkins 1.656, Ubuntu Labels: regression Priority: Major Reporter: John Mellor The ability to run a pipeline job in a specified Docker image is missing in the job configuration. This means that unlike freestyle jobs using the Cloudbees Docker plugin, Jenkins slave images with the appropriate tools added on a slave are not able to be used to build product. Add Comment
[JIRA] (JENKINS-39920) Pipeline job type has no ability to specify the node labels it can run on
Title: Message Title John Mellor created an issue Jenkins / JENKINS-39920 Pipeline job type has no ability to specify the node labels it can run on Issue Type: Bug Assignee: Unassigned Components: pipeline Created: 2016/Nov/21 8:18 PM Environment: Jenkins 1.656, Ubuntu Labels: regression Priority: Blocker Reporter: John Mellor A pipeline job type is missing the ability to specify a node label to restrict where it will build. I have different platforms and version of tools on various slave nodes, and it is critical that the job be restricted to a set of nodes where the correct tools and platform are present in order to build successfully. I use node labels to do this with every other job type. Without this functionality, I can see no means of using pipelines on any more-than-trivial job type. Add Comment
[JIRA] (JENKINS-39869) NodeLabel Parameter Plugin does not work
Title: Message Title John Mellor created an issue Jenkins / JENKINS-39869 NodeLabel Parameter Plugin does not work Issue Type: Bug Assignee: Dominik Bartholdi Attachments: NodeLabel-failure.PNG Components: nodelabelparameter-plugin Created: 2016/Nov/18 3:16 PM Environment: Jenkins 1.656 on Ubuntu Priority: Major Reporter: John Mellor The NodeLabel Parameter plugin simply does not work. The label parameter type appears to not match the actual node labels, leaving jobs stalled in the queue. The node parameter type correctly identifies the matching nodes, but the selected node is not used when the build starts. I installed this plugin as a workaround for the pipeline job type having no apparent means of identifying the node labels that are capable of running the job without adding it. That's probably another bug. In this specific case, the node that is identified is part of a VMware-managed cloud, and is online and accessible while it is being ignored by the queue manager.
[JIRA] (JENKINS-34803) Update to version 1.3 of build-graph-view plugin crashes Jenkins hard
Title: Message Title John Mellor closed an issue as Fixed Shown to be working in plugin version 1.4 Jenkins / JENKINS-34803 Update to version 1.3 of build-graph-view plugin crashes Jenkins hard Change By: John Mellor Status: Resolved Closed Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36507) git plugin 2.5.2 breaks builds which use a narrow refspec but expect all refs were fetched
Title: Message Title John Mellor commented on JENKINS-36507 Re: git plugin 2.5.2 breaks builds which use a narrow refspec but expect all refs were fetched I’ve installed the prototype build, and come up with 4 use-case combinations that test the behaviour change. I believe that the prototype is working, as all 4 use-cases work as intended. Thumbs up!!! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36889) Extreme docker plugin logging cannot be turned off
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-36889 Extreme docker plugin logging cannot be turned off Change By: John Mellor Summary: Extreme docker plugin loggin logging cannot be turned off Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36889) Extreme docker plugin loggin cannot be turned off
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-36889 Extreme docker plugin loggin cannot be turned off Change By: John Mellor When building a docker image from a Dockerfile to run the build in, extreme docker build logging cannot be turned off.This issue makes the first 20 pages of the build log essentially useless.Filtering it or adding the -q flag would resolve this.E.g. from a typical build log with verbose logging flag not enabled :10:51:06 $ docker build --file /home/esadmin/build/Dockerfile.precise /home/esadmin/build10:51:06 Sending build context to Docker daemon 557.1 kBSending build context to Docker daemon 1.114 MBSending build context to Docker daemon 1.671 MBSending build context to Docker daemon 2.228 MBSending build context to Docker daemon 2.785 MBSending build context to Docker daemon 3.342 MBSending build context to Docker daemon 3.899 MBSending build context to Docker daemon 4.456 MBSending build context to Docker daemon 5.014 MBSending build context to Docker daemon 5.571 MBSending build context to Docker daemon 6.128 MBSending build context to Docker daemon 6.685 MBSending build context to Docker daemon 7.242 MBSending build context to Docker daemon 7.799 MBSending build context to Docker daemon 8.356 MBSending build context to Docker daemon 8.913 MBSending build context to Docker daemon 9.47 MBSending build context to Docker daemon 10.03 MBSending build context to Docker daemon 10.58 MBSending build context to Docker daemon 11.14 MBSending build context to Docker daemon 11.7 MB. . . (for 20 pages) Add Comment
[JIRA] (JENKINS-36889) Extreme docker plugin loggin cannot be turned off
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-36889 Extreme docker plugin loggin cannot be turned off Change By: John Mellor Summary: Extreme docker plugin loggin cannot ge be turned off Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36889) Extreme docker plugin loggin cannot ge turned off
Title: Message Title John Mellor created an issue Jenkins / JENKINS-36889 Extreme docker plugin loggin cannot ge turned off Issue Type: Bug Assignee: Nicolas De Loof Components: docker-custom-build-environment-plugin Created: 2016/Jul/22 8:01 PM Environment: Jenkins 1.656, Ubuntu Linux Labels: user-experience plugins Priority: Minor Reporter: John Mellor When building a docker image from a Dockerfile to run the build in, extreme docker build logging cannot be turned off. This issue makes the first 20 pages of the build log essentially useless. Filtering it or adding the -q flag would resolve this. E.g. from a typical build log: 10:51:06 $ docker build --file /home/esadmin/build/Dockerfile.precise /home/esadmin/build 10:51:06 Sending build context to Docker daemon 557.1 kB Sending build context to Docker daemon 1.114 MB Sending build context to Docker daemon 1.671 MB Sending build context to Docker daemon 2.228 MB Sending build context to Docker daemon 2.785 MB Sending build context to Docker daemon 3.342 MB Sending build context to Docker daemon 3.899 MB Sending build context to Docker daemon 4.456 MB Sending build context to Docker daemon 5.014 MB Sending build context to Docker daemon 5.571 MB Sending build context to Docker daemon 6.128 MB Sending build context to Docker daemon 6.685 MB Sending build context to Docker daemon 7.242 MB Sending build context to Docker daemon 7.799 MB Sending build context to Docker daemon 8.356 MB Sending build context to Docker daemon 8.913 MB Sending build context to Docker daemon 9.47 MB Sending build context to Docker daemon
[JIRA] (JENKINS-29946) Console Output blown up with refreshed line content
Title: Message Title John Mellor commented on JENKINS-29946 Re: Console Output blown up with refreshed line content JENKINS-36886 appears to be a more generic issue with the same cause. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36886) Terminal escape sequences being shown
Title: Message Title John Mellor commented on JENKINS-36886 Re: Terminal escape sequences being shown A specific problem resulting from this more generic issue Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36886) Terminal escape sequences being shown
Title: Message Title John Mellor created an issue Jenkins / JENKINS-36886 Terminal escape sequences being shown Issue Type: Bug Assignee: Nicolas De Loof Components: docker-custom-build-environment-plugin Created: 2016/Jul/22 7:29 PM Environment: Ubuntu Linux, Jenkins 1.656, output from Robot, pip, many others. Labels: regression user-experience plugins Priority: Minor Reporter: John Mellor ANSI escape sequences in jobs run directly on a Jenkins slave are either not present or stripped out. These escape sequences are not stripped when running in a docker image being managed by this plugin. This makes dockerized build output parsing different, and unxexpectedly tricky for postbuild actions, and in many cases makes the output much noisier than necessary. e.g: a job that does a simple "ls --color=auto" can be easily shown in a docker machine to have color escapes present in the log, but not present in a non-docker build. Doing the same action on a docker image and on a real machine, we can see that the output in colorized in both cases, narrowing the issue down to a problem in the Jenkins plugin.
[JIRA] (JENKINS-36507) git plugin 2.5.2 breaks builds which use a narrow refspec but expect all refs were fetched
Title: Message Title John Mellor commented on JENKINS-36507 Re: git plugin 2.5.2 breaks builds which use a narrow refspec but expect all refs were fetched Mark asked: > I'm not understanding enough of the use case yet When integrating with the Gerrit plugin, it is normally necessary to trigger a "verification" build to check that every commit actually builds and unit-tests. The Gerrit verification builds normally build special refs/for/ branches, which may be merged into the in git at a future date after code review is complete. In this particular case, is "develop", but gerrit will trigger a build for any branch in the refs/for/* tree as required with the introduction of short-lived feature and bugfix branches. These refs/for branches are deleted by Gerrit upon successful merge to the , and either a pushbutton build or a merge trigger from Gerrit will trigger the build. Make sense now? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36507) git plugin 2.5.2 breaks builds which use a narrow refspec but expect all refs were fetched
Title: Message Title John Mellor commented on JENKINS-36507 Re: git plugin 2.5.2 breaks builds which use a narrow refspec but expect all refs were fetched Mark requested: > Could you try a different experiment? I should note that because of the Gerrit plugin, I have to specify the refspec as $GERRIT_REFSPEC parameter to the build, and this is sometimes overloaded by the Gerrit plugin when building a verification build, which would then change $GERRIT_REFSPEC to refs/for/ where it sees a change. I have a check in my build scripting to differentiate between a Gerrit verification build and a build on the branch that this build is watching, in order to prevent attempts to promote verification builds, etc. The integration between Gerrit and Git plugins is poorly done, but that's a different problem. Using Git plugin 2.4.4, that one does not work either: 12:59:11 > /usr/bin/git init /var/lib/jenkins/workspace/soc-dashboard_dev_nightly # timeout=10 12:59:11 Fetching upstream changes from ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git 12:59:11 > /usr/bin/git --version # timeout=10 12:59:11 > /usr/bin/git -c core.askpass=true fetch --tags --progress ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git +refs/heads/:refs/remotes/origin/ 12:59:34 > /usr/bin/git config remote.origin.url ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git # timeout=10 12:59:34 > /usr/bin/git config --add remote.origin.fetch +refs/heads/:refs/remotes/origin/ # timeout=10 12:59:34 > /usr/bin/git config remote.origin.url ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git # timeout=10 12:59:34 Fetching upstream changes from ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git 12:59:34 > /usr/bin/git -c core.askpass=true fetch --tags --progress ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git ref/heads/develop:refs/remotes/origin/develop 12:59:34 ERROR: Error fetching remote repo 'origin' Add Comment This message was sent by Atlassian JIRA
[JIRA] (JENKINS-36507) git plugin 2.5.2 breaks builds which use a narrow refspec but expect all refs were fetched
Title: Message Title John Mellor commented on JENKINS-36507 Re: git plugin 2.5.2 breaks builds which use a narrow refspec but expect all refs were fetched I tried your suggested fix, and it breaks the git fetch pretty spectacularly using the git plugin 2.4.4 plugin version: 09:57:18 Building remotely on docker-trusty2 (dockerhost docker-2) in workspace /var/lib/jenkins/workspace/soc-dashboard_develop 09:57:18 Wiping out workspace first. 09:57:18 Cloning the remote Git repository 09:57:18 Cloning repository ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git 09:57:18 > /usr/bin/git init /var/lib/jenkins/workspace/soc-dashboard_develop # timeout=10 09:57:18 Fetching upstream changes from ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git 09:57:18 > /usr/bin/git --version # timeout=10 09:57:18 > /usr/bin/git -c core.askpass=true fetch --tags --progress ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git +refs/heads/:refs/remotes/origin/ 09:57:30 > /usr/bin/git config remote.origin.url ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git # timeout=10 09:57:30 > /usr/bin/git config --add remote.origin.fetch +refs/heads/:refs/remotes/origin/ # timeout=10 09:57:30 > /usr/bin/git config remote.origin.url ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git # timeout=10 09:57:30 Fetching upstream changes from ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git 09:57:30 > /usr/bin/git -c core.askpass=true fetch --tags --progress ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git refs/heads/develop +refs/heads/:refs/remotes/origin/ 09:57:30 ERROR: Error fetching remote repo 'origin' Screenshots of the parameters, git config and gerrit config settings for this build attached: I have separate builds for each production branch for this kind of project. What need to happen in this case is to only trigger this build when Gerrit sees a change on develop branch, and not on just any branch. How should this be configured to thread the needle? Does your suggested fix only work with git plugin 2.5.2, or should it also work with the older and functioning plugin? Can the "fix" be reverted, and the people with poorly-constructed huge git repos maybe suck it up? Add Comment
[JIRA] (JENKINS-36507) git plugin 2.5.2 breaks builds which use a narrow refspec but expect all refs were fetched
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-36507 git plugin 2.5.2 breaks builds which use a narrow refspec but expect all refs were fetched Change By: John Mellor Attachment: gerrit-config.PNG Attachment: Parameters.PNG Attachment: slave-config.PNG Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36507) git plugin 2.5.2 breaks some existing builds
Title: Message Title John Mellor created an issue Jenkins / JENKINS-36507 git plugin 2.5.2 breaks some existing builds Issue Type: Bug Assignee: Mark Waite Attachments: slave-config.PNG Components: git-plugin Created: 2016/Jul/07 8:38 PM Environment: Ubuntu, Jenkins 1.656, VSphere plugin 2.53, Git plugin 2.5.1 or 2.5.2 Priority: Blocker Reporter: John Mellor The git plugin is unable to find revisions to build in environments where the current user is not Jenkins. This problem was introduced in git 2.5.1, 2 releases, and was not present in the 2.5.0 release. On builds where the build user is not Jenkins (the slave is running as a different user), the job aborts due to git errors. e.g: 14:48:47 Started by user jmellor 14:48:47 Starting limited count build: 1 14:48:47 [EnvInject] - Loading node environment variables. 14:48:47 Building remotely on robot-testbuilder-1 (robot-testbuilder) in workspace /var/lib/jenkins/workspace/soc-dashboard_dev_nightly 14:48:50 Wiping out workspace first. 14:48:50 Cloning the remote Git repository 14:48:50 Cloning repository ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git 14:48:50 > /usr/bin/git init /var/lib/jenkins/workspace/soc-dashboard_dev_nightly # timeout=10 14:48:50 Fetching upstream changes from ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git 14:48:50 > /usr/bin/git --version # timeout=10 14:48:50 > /usr/bin/git -c core.askpass=true fetch --tags --progress ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git refs/heads/develop 14:49:13 > /usr/bin/git config remote.origin.url
[JIRA] (JENKINS-27314) NextBuildNumber Plugin hangs with latest Jenkins
Title: Message Title John Mellor closed an issue as Cannot Reproduce Unable to reproduce as of build 1.651 Jenkins / JENKINS-27314 NextBuildNumber Plugin hangs with latest Jenkins Change By: John Mellor Status: Open Closed Resolution: Cannot Reproduce Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit
[JIRA] [core] (JENKINS-33405) 1.652 breaks multi-branch build configuration
Title: Message Title John Mellor closed an issue as Fixed Upgrading from broken Jenkins 1.652 to 1.656 has fixed something, and the issue no longer presents. Jenkins / JENKINS-33405 1.652 breaks multi-branch build configuration Change By: John Mellor Status: Resolved Closed 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-33405) 1.652 breaks multi-branch build configuration
Title: Message Title John Mellor resolved as Fixed Unable to reproduce in Jenkins 1.656 release. Jenkins / JENKINS-33405 1.652 breaks multi-branch build configuration Change By: John Mellor Status: Open Resolved Resolution: Fixed 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] [buildgraph-view-plugin] (JENKINS-34803) Update to version 1.3 of build-graph-view plugin crashes Jenkins hard
Title: Message Title John Mellor created an issue Jenkins / JENKINS-34803 Update to version 1.3 of build-graph-view plugin crashes Jenkins hard Issue Type: Bug Assignee: Unassigned Attachments: buildgraph-view-plugin.partial-traceback.txt Components: buildgraph-view-plugin Created: 2016/May/13 1:43 PM Environment: Jenkins 1.656 Ubuntu 12.04 openjdk-7-jre-headless=7u9-2.3.3-0ubuntu1~12.04.1 Labels: jenkins plugins exception Priority: Blocker Reporter: John Mellor Upgrading from buildgraph-viewer 1.2 to 1.3 crashes Jenkins hard. Apparent nullpointer exception in plugin loader. Partial traceback attached, as cut from the screen. Manually reverting the plugin by renaming the jpi files gets
[JIRA] [core] (JENKINS-33405) 1.652 breaks multi-branch build configuration
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-33405 1.652 breaks multi-branch build configuration Capture.PNG image of part of the Configure page after downgradfing from 1.652 back to 1.651, showing normal configuration page operation. Change By: John Mellor Attachment: Capture.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] [core] (JENKINS-33405) 1.652 breaks multi-branch build configuration
Title: Message Title John Mellor created an issue Jenkins / JENKINS-33405 1.652 breaks multi-branch build configuration Issue Type: Bug Assignee: Unassigned Attachments: Screenshot from 2016-03-08 11 04 54.png Components: core Created: 08/Mar/16 6:09 PM Environment: Jenkins 1.652 (latest) Branch API plugin 1.3 (latest) Multi Branch Project Plugin 0.4.1 (latest) Labels: jenkins regression user-experience exception fatal Priority: Blocker Reporter: John Mellor Upgrade from Jenkins 1.651 to 1.652 breaks the multi-branch project configuration page. Reverting back to 1.651 works around the issue. Screenshot of the breakage attached. Since everything is grayed-out, no further actions are
[JIRA] [promoted-builds-plugin] (JENKINS-29688) Promotion sometimes fails to copy artifacts to workspace
Title: Message Title John Mellor resolved as Cannot Reproduce This issue has not been seen for the last 29 minor Jenkins releases. Assumed fixed. Jenkins / JENKINS-29688 Promotion sometimes fails to copy artifacts to workspace Change By: John Mellor Status: Open Resolved Resolution: Cannot Reproduce 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] [cluster-stats-plugin] (JENKINS-32864) Cluster Stats Plugin: Add a skip list of known log-running jobs
Title: Message Title John Mellor created an issue Jenkins / JENKINS-32864 Cluster Stats Plugin: Add a skip list of known log-running jobs Issue Type: New Feature Assignee: Unassigned Components: cluster-stats-plugin Created: 09/Feb/16 8:34 PM Priority: Minor Reporter: John Mellor The build timings provided the the cluster-stats plugin are highly skewed by a few long-running jobs - notably integration test suite runs and field deployment runs. In my case, most builds take 5 to 30 minutes to compile and unit-test. However, there are a dozen full integration testsuite runs that take most of the night to run, as well as deployment runs that can take many days to push the new products out. The numbers provided by the plugin are not useful as a result of this skewing. ENHANCEMENT REQUEST: Add a skiplist of jobs to ignore when compiling stats. Add Comment
[JIRA] [core] (JENKINS-26813) Missing configuration sections in freestyle multibranch projects
Title: Message Title John Mellor reopened an issue I do not understand the previous comment and reason for incorrectly closing this issue. The problem is still present, and is in a Jenkins plugin that is being tracked in Jira. If the issue is not in the multi-branch plugin, then where is it? I assume that this is in Core. Jenkins / JENKINS-26813 Missing configuration sections in freestyle multibranch projects Change By: John Mellor Resolution: Not A Defect Status: Resolved Reopened 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] [jqs-monitoring-plugin] (JENKINS-32774) Master node not part of the slave status block
Title: Message Title John Mellor created an issue Jenkins / JENKINS-32774 Master node not part of the slave status block Issue Type: Bug Assignee: Unassigned Components: jqs-monitoring-plugin Created: 04/Feb/16 2:31 PM Priority: Minor Reporter: John Mellor In sites where the master node accepts build jobs, the slave list should also include the master node. It does not. Add Comment This message was
[JIRA] [jqs-monitoring-plugin] (JENKINS-32773) slave drill-down references a nonexistent path
Title: Message Title John Mellor created an issue Jenkins / JENKINS-32773 slave drill-down references a nonexistent path Issue Type: Bug Assignee: Unassigned Components: jqs-monitoring-plugin Created: 04/Feb/16 2:28 PM Priority: Minor Reporter: John Mellor When attempting to drill down to a specific slave machine, the referenced URL is not valid. There is an invalid "jqs-monitoring" component in the path. If the jqs-monitoring part of the path is stripped out, then the referenced URL is corrected. Add Comment
[JIRA] [jqs-monitoring-plugin] (JENKINS-32775) Intentionally-offline slaves marked red, should be green
Title: Message Title John Mellor commented on JENKINS-32775 Re: Intentionally-offline slaves marked red, should be green There may be a case for marking these incorrectly-coloured nodes some other colour than green - perhaps transparent, perhaps yellow for unknown-but-assumed-ok status. 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] [jqs-monitoring-plugin] (JENKINS-32775) Intentionally-offline slaves marked red, should be green
Title: Message Title John Mellor created an issue Jenkins / JENKINS-32775 Intentionally-offline slaves marked red, should be green Issue Type: Bug Assignee: Unassigned Components: jqs-monitoring-plugin Created: 04/Feb/16 2:36 PM Priority: Minor Reporter: John Mellor Intentionally offline slaves should not be marked red. Red implies an alert situation, which is incorrectly being assumed in common instances. These slaves are either (a) manually marked offline for various reasons, or (b) offline-until-demand or dynamically constructed from a template using the vsphere plugin to manage the node. Add Comment
[JIRA] [jqs-monitoring-plugin] (JENKINS-32772) Back to Jenkins button goes to nonexistent web page
Title: Message Title John Mellor created an issue Jenkins / JENKINS-32772 Back to Jenkins button goes to nonexistent web page Issue Type: Bug Assignee: Unassigned Components: jqs-monitoring-plugin Created: 04/Feb/16 2:23 PM Environment: Jenkins 1.646 Priority: Minor Reporter: John Mellor The "Back to Jenkins" button references the a nonexistent and incorrect URL. It references the "jqs-monitoring" subdir, which (a) does not exist, and (b) is not the correct URL. The correct URL for this button should be the top-level Jenkins URL, or the parent of the referenced location. Add Comment
[JIRA] [core] (JENKINS-32751) Offlined slaves still being pinged, overwriting the offline cause comment
Title: Message Title John Mellor created an issue Jenkins / JENKINS-32751 Offlined slaves still being pinged, overwriting the offline cause comment Issue Type: Bug Assignee: Unassigned Attachments: gratuitous-ping-wipes-out-reason.PNG Components: core Created: 03/Feb/16 3:29 PM Environment: Ubuntu, Jenkins 1.646 Priority: Minor Reporter: John Mellor When a slave is taken offline, I normally give it a reason comment. With the slave offline and several minutes later, this comment is overwritten with a new message about ping timeouts. An offline slave should not be inspected for accessibility. There is a missing if. The specific overwriting message observed is "Ping response time is too long or timed out."
[JIRA] [core] (JENKINS-32752) Wipe out Repository fails to delte workspace entities with no permissions for the Jenkins user
Title: Message Title John Mellor created an issue Jenkins / JENKINS-32752 Wipe out Repository fails to delte workspace entities with no permissions for the Jenkins user Issue Type: Bug Assignee: Unassigned Attachments: traceback-wipe-failure.PNG, wipe-permission-issue.PNG Components: core Created: 03/Feb/16 3:44 PM Environment: Ubuntu, Jenkins 1.646 Priority: Minor Reporter: John Mellor In the "Source Code Management" block, if you add an "Additional Behaviours" of "Wipe out repository & force clone", this step fails if the Jenkins user has no permission to delete some objects in the workspace tree. This situation occurs in my specific situation because dirt left by a prior Docker build is owned by the wrong user. It should instead be deleting the tree using sudo or similar. A workaround can sometimes be performed, by adding a script step in the previous build to clean out the workspace correctly. This will obviously not
[JIRA] [core] (JENKINS-32752) Wipe out Repository fails to delete workspace entities with no permissions for the Jenkins user
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-32752 Wipe out Repository fails to delete workspace entities with no permissions for the Jenkins user Change By: John Mellor Summary: Wipe out Repository fails to delte delete workspace entities with no permissions for the Jenkins user 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-32116) Can't use "Restrict where this project can be run" due to the NPE in Cloud implementation
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-32116 Can't use "Restrict where this project can be run" due to the NPE in Cloud implementation Change By: John Mellor Issue Type: Improvement Bug 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-32418) Missing "Restrict where this project can be run" setting in project configuration
Title: Message Title John Mellor commented on JENKINS-32418 Re: Missing "Restrict where this project can be run" setting in project configuration I am having a possibly-related issue with the vsphere cloud plugin, that may have started at the same time. I cannot start up vsphere slaves on the timer - only from manual. If this is not related, my apologies. The system log is repeatedly showing: Jan 13, 2016 9:54:45 AM SEVERE hudson.triggers.SafeTimerTask run Timer task hudson.slaves.NodeProvisioner$NodeProvisionerInvoker@64e4acbe failed java.lang.NullPointerException at org.jenkinsci.plugins.vSphereCloud.getTemplate(vSphereCloud.java:176) at org.jenkinsci.plugins.vSphereCloud.canProvision(vSphereCloud.java:233) at hudson.model.Label.getClouds(Label.java:227) at hudson.model.Label.isEmpty(Label.java:435) at jenkins.model.Jenkins.getLabels(Jenkins.java:1653) at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:796) at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:50) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) 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.
[JIRA] [core] (JENKINS-32418) Missing "Restrict where this project can be run" setting in project configuration
Title: Message Title
John Mellor edited a comment on JENKINS-32418
Re: Missing "Restrict where this project can be run" setting in project configuration
Daniel asked:> Do you have static slaves? Clouds?Yes and yes. All slaves are variants of Ubuntu, with some always-up and some spun-down vmware machines that are spun up by the vcloud plugin.> What kind of project is affected, a freestyle job, or something else?All jobs are freestyle. There are about 200 of them, all exhibiting the same symptoms.I 'm on latest Jenkins (1.644) and latest plugins, to pick up the security fixes.I am having a possibly-related issue with the vsphere cloud plugin, that may have started at the same time. I cannot start up vsphere slaves on the timer - only from manual. If this is not related, my apologies. The system log is repeatedly showing:{quote}Jan 13, 2016 9:54:45 AM SEVERE hudson.triggers.SafeTimerTask runTimer task hudson.slaves.NodeProvisioner$NodeProvisionerInvoker@64e4acbe failedjava.lang.NullPointerException at org.jenkinsci.plugins.vSphereCloud.getTemplate(vSphereCloud.java:176) at org.jenkinsci.plugins.vSphereCloud.canProvision(vSphereCloud.java:233) at hudson.model.Label.getClouds(Label.java:227) at hudson.model.Label.isEmpty(Label.java:435) at jenkins.model.Jenkins.getLabels(Jenkins.java:1653) at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:796) at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:50) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722){quote}
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received
[JIRA] [core] (JENKINS-32418) Missing "Restrict where this project can be run" setting in project configuration
Title: Message Title John Mellor commented on JENKINS-32418 Re: Missing "Restrict where this project can be run" setting in project configuration I'm not sure at what point this field disappeared in the GUI, but probably in the last 5 releases or so. The config.xml file still contains the labels and the jobs appear to execute on the right slave machines. I can see no errors in the logs, but the restrict checkbox is not showing. However, if I add a new label on the master, I can temporarily see the checkbox until I check on the same job again. It looks like a reversed check for the master having a label or something similar. Given that almost everyone runs slave machines, can this check be removed? 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-32418) Missing "Restrict where this project can be run" setting in project configuration
Title: Message Title
John Mellor edited a comment on JENKINS-32418
Re: Missing "Restrict where this project can be run" setting in project configuration
Daniel asked:> Do you have static slaves? Clouds?Yes and yes. All slaves are variants of Ubuntu, with some always-up and some spun-down vmware machines that are spun up by the vcloud plugin.> What kind of project is affected, a freestyle job, or something else?All jobs are freestyle. There are about 200 of them, all exhibiting the same symptoms. I am having a possibly-related issue with the vsphere cloud plugin, that may have started at the same time. I cannot start up vsphere slaves on the timer - only from manual. If this is not related, my apologies. The system log is repeatedly showing:{quote}Jan 13, 2016 9:54:45 AM SEVERE hudson.triggers.SafeTimerTask runTimer task hudson.slaves.NodeProvisioner$NodeProvisionerInvoker@64e4acbe failedjava.lang.NullPointerException at org.jenkinsci.plugins.vSphereCloud.getTemplate(vSphereCloud.java:176) at org.jenkinsci.plugins.vSphereCloud.canProvision(vSphereCloud.java:233) at hudson.model.Label.getClouds(Label.java:227) at hudson.model.Label.isEmpty(Label.java:435) at jenkins.model.Jenkins.getLabels(Jenkins.java:1653) at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:796) at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:50) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722){quote}
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"
[JIRA] [workflow-plugin] (JENKINS-31152) 2.0: Pipeline as code in front & center
Title: Message Title John Mellor commented on JENKINS-31152 Re: 2.0: Pipeline as code in front & center I have one project that has ~130 sub-builds, in a fairly complex ordering tree with some build threads in parallel and then some in serial, and then some in parallel again. Almost all steps are freestyle builds running autotools and make or a modified debuild. Are we going to be able to bring the job steps together into several choke-points throughout the pipeline, or is the proposed solution going to be more simplistic? 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-29876) NPE when triggering downstream job
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-29876 NPE when triggering downstream job Change By: John Mellor Environment: Jenkins 1.621+ Windows 2003 all platforms 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-29807) NullPointerException when triggering dependent builds
Title: Message Title John Mellor commented on JENKINS-29807 Re: NullPointerException when triggering dependent builds The critical problem here is that all of the dependent builds after a disabled dependency in the list are not triggered, thus breaking the entire build tree. This means that in real use, the entire toolchain needs to externally work around Jenkins instead of relying on it. This affect a LOT of users. Can we please get this fixed in the 1.628 release? 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-29807) NullPointerException when triggering dependent builds
Title: Message Title John Mellor commented on JENKINS-29807 Re: NullPointerException when triggering dependent builds This issue is not fixed by moving up to 1.625 release. It appears to be caused only whenever the list of dependent builds includes a disabled build. 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] [promoted-builds-plugin] (JENKINS-29688) Promotion sometimes fails to copy artifacts to workspace
Title: Message Title John Mellor commented on JENKINS-29688 Re: Promotion sometimes fails to copy artifacts to workspace The conditions where CopyArtifact skips the artifact copying are unknown. All builds that were occasionally exhibiting this incorrect behaviour had the following general steps during promotion: 1) Script to build product on multiple platforms and then merge the deliverables into one subdirectory (artifacts). 2) copy artifacts to master so that they are on a known host. 3) wait for manual promotion, sometimes delayed by weeks until test results are accepted. 4) promote specific build: 4a) copy artifacts from another project (always our own project: $PROMOTED_JOB_NAME or exact test of the name) to get it to the current host. 4b) script to promote to an internal Debian repo mechanism I have abandoned this CopyArtifact mechanism in steps (2 and 4a) because of the inconsistency, and can no longer reproduce the issue as a consequence. The following is the promotion job build.xml from a simpler project that only builds one platform: ?xml version='1.0' encoding='UTF-8'? hudson.plugins.promoted__builds.Promotion plugin=promoted-builds@2.21 actions hudson.model.ParametersAction parameters/ /hudson.model.ParametersAction hudson.plugins.promoted__builds.PromotionTargetAction jobNamedart/jobName number13/number /hudson.plugins.promoted__builds.PromotionTargetAction hudson.model.CauseAction causes hudson.model.Cause_-UserCause authenticationNamejmellor/authenticationName /hudson.model.Cause_-UserCause /causes /hudson.model.CauseAction hudson.plugins.copyartifact.CopyArtifact_-EnvAction plugin=copyartifact@1.35.2/ hudson.tasks.Fingerprinter_-FingerprintAction record entry stringdart_1.3.0-1_amd64.changes/string string128238385dd8db61072b21c0f6bbfc54/string /entry entry stringdart_1.3.0-1.dsc/string stringd863b418a7676b7a0cbff649ace198e1/string /entry entry stringdart_1.3.0-1_amd64.deb/string stringbf06f5b64673b029f352110747c515c9/string /entry /record /hudson.tasks.Fingerprinter_-FingerprintAction /actions queueId6179/queueId timestamp1439392433073/timestamp startTime1439392433073/startTime resultFAILURE/result duration291/duration charsetUTF-8/charset keepLogfalse/keepLog builtOnbuildslave1/builtOn workspace/var/lib/jenkins/workspace/dart/workspace hudsonVersion1.623/hudsonVersion scm class=hudson.scm.NullChangeLogParser/ culprits class=com.google.common.collect.EmptyImmutableSortedSet/ /hudson.plugins.promoted__builds.Promotion Add Comment This message was sent by
[JIRA] [core] (JENKINS-29807) NullPointerException when triggering dependent builds
Title: Message Title John Mellor created an issue Jenkins / JENKINS-29807 NullPointerException when triggering dependent builds Issue Type: Bug Assignee: Unassigned Components: core Created: 05/Aug/15 1:23 PM Environment: Ubuntu 12.04.1, Jenkins 1.622 and 1.623 Priority: Minor Reporter: John Mellor Build completes satisfactorily, but NPE while triggering dependent builds. I upgraded to 1.623 to see if that resolved the fault, but the results are identical. The log shows only 4 of 10 builds triggered, but it may not have been flushed at the point of the fault. All builds are freestyle using multiple shell steps, with no Java or Groovy components or steps. This problem is 100% repeatable with certain builds. Tail of an example failing build: 17:44:08 Archiving artifacts 17:44:11 Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered 17:44:11 Triggering a new build of trap 17:44:11 Triggering a new build of snort-e 17:44:11 Triggering a new build of tcparchive_982 17:44:11 Triggering a new build of deepinspect 17:44:11 FATAL: null 17:44:11 java.lang.NullPointerException 17:44:11 at jenkins.triggers.ReverseBuildTrigger.shouldTrigger(ReverseBuildTrigger.java:111) 17:44:11 at
[JIRA] [promoted-builds-plugin] (JENKINS-29680) Crash after artifact promotion
Title: Message Title John Mellor created an issue Jenkins / JENKINS-29680 Crash after artifact promotion Issue Type: Bug Assignee: Unassigned Components: promoted-builds-plugin Created: 28/Jul/15 2:17 PM Environment: Jenkins 1.620 on Ubuntu 12.04.1 with multiple slave machines Labels: crash Priority: Major Reporter: John Mellor Immediately after a promotion, the slave executing the promotion crashed and did not recover. The explanation on the help page say submit an issue, so here it is. The Jenkins log on the crashed slave shows no issues. The master log shows: Jul 28, 2015 9:29:31 AM INFO hudson.model.Run execute dns-hijacker/promotion/manual #4 main build action completed: FAILURE Jul 28, 2015 9:29:44 AM SEVERE hudson.model.Executor run Unexpected executor death java.lang.IllegalStateException:
[JIRA] [promoted-builds-plugin] (JENKINS-29688) Promotion sometimes fails to copy artifacts to workspace
Title: Message Title
John Mellor updated an issue
Jenkins / JENKINS-29688
Promotion sometimes fails to copy artifacts to workspace
Change By:
John Mellor
Sometimestheartifactcopystepisskippedforunknownreasons,resultinginabadpromotion.Icanlocatenousefullogstoidentifytheissue,otherthanthepromotionlogitselfshowingamissedcriticalstep.Allpromotionsaremanual,andrunashellscriptastheactualpromotion.Logheadfromanincorrectpromotionexamplelog:{quote}StartedbyuserilijabBuildingremotelyonbuildslave4inworkspace/var/lib/jenkins/workspace/esensor-corePromotingesensor-core#93[esensor-core]$/bin/bash-xe/tmp/hudson5568737232874898866.sh...{quote}Logheadfromacorrectpromotionofthesamejob,runearlierinthedaywithnoproductorbuildchanges:{quote}StartedbyuserwfangBuildingremotelyonbuildslave1inworkspace/var/lib/jenkins/workspace/esensor-corePromotingesensor-core#92{color:red}Copied2artifactsfromesensor-corebuildnumber92{color}buildhudson.plugins.copyartifact.CopyArtifact@144ec690SUCCESS{quote}...Ascanbeseen,thepromotionsometimescopiesthecorrectartifactsfrommaster,andsometimesincorrectlydecidesnotto.Sincethepromotion runs andtherelatedbuildprocesseswillrun onanarbitraryhostinthecluster,oldworkspacecontentsaregenerallypresentanditisnotclearwhyitdecidestowronglyskipthecopystep.
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,
[JIRA] [promoted-builds-plugin] (JENKINS-29688) Promotion sometimes fails to copy artifacts to workspace
Title: Message Title
John Mellor created an issue
Jenkins / JENKINS-29688
Promotion sometimes fails to copy artifacts to workspace
Issue Type:
Bug
Assignee:
Unassigned
Components:
promoted-builds-plugin
Created:
28/Jul/15 5:31 PM
Environment:
Jenkins 1.620 on Ubuntu 12 with multiple slaves, promoted-builds plugin version 2.21 (latest)
Priority:
Critical
Reporter:
John Mellor
Sometimes the artifact copy step is skipped for unknown reasons, resulting in a bad promotion. I can locate no useful logs to identify the issue, other than the promotion log itself showing a missed critical step. All promotions are manual, and run a shell script as the actual promotion.
Log head from an incorrect promotion example log: {{Started by user ilijab Building remotely on buildslave4 in workspace /var/lib/jenkins/workspace/esensor-core Promoting esensor-core #93 [esensor-core] $ /bin/bash -xe /tmp/hudson5568737232874898866.sh . . .}}
Log head from a correct promotion of the same job, run earlier in the day with no product or build changes: {{Started by user wfang Building remotely on buildslave1 in workspace /var/lib/jenkins/workspace/esensor-core Promoting esensor-core #92 Copied 2 artifacts from esensor-core build number 92 build
[JIRA] [promoted-builds-plugin] (JENKINS-29688) Promotion sometimes fails to copy artifacts to workspace
Title: Message Title
John Mellor updated an issue
Jenkins / JENKINS-29688
Promotion sometimes fails to copy artifacts to workspace
Change By:
John Mellor
Sometimestheartifactcopystepisskippedforunknownreasons,resultinginabadpromotion.Icanlocatenousefullogstoidentifytheissue,otherthanthepromotionlogitselfshowingamissedcriticalstep.Allpromotionsaremanual,andrunashellscriptastheactualpromotion.Logheadfromanincorrectpromotionexamplelog:{ { quote} StartedbyuserilijabBuildingremotelyonbuildslave4inworkspace/var/lib/jenkins/workspace/esensor-corePromotingesensor-core#93[esensor-core]$/bin/bash-xe/tmp/hudson5568737232874898866.sh... {quote } } Logheadfromacorrectpromotionofthesamejob,runearlierinthedaywithnoproductorbuildchanges:{ { quote} StartedbyuserwfangBuildingremotelyonbuildslave1inworkspace/var/lib/jenkins/workspace/esensor-corePromotingesensor-core#92{color:red}Copied2artifactsfromesensor-corebuildnumber92{color}buildhudson.plugins.copyartifact.CopyArtifact@144ec690SUCCESS {quote } } ...Ascanbeseen,thepromotionsometimescopiesthecorrectartifactsfrommaster:,andsometimesincorrectlydecidesnotto.Sincethepromotionrunsonanarbitraryhostinthecluster,oldworkspacecontentsaregenerallypresentanditisnotclearwhyitdecidestowronglyskipthecopystep.
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
[JIRA] [promoted-builds-plugin] (JENKINS-29688) Promotion sometimes fails to copy artifacts to workspace
Title: Message Title
John Mellor updated an issue
Jenkins / JENKINS-29688
Promotion sometimes fails to copy artifacts to workspace
Change By:
John Mellor
Sometimestheartifactcopystepisskippedforunknownreasons,resultinginabadpromotion.Icanlocatenousefullogstoidentifytheissue,otherthanthepromotionlogitselfshowingamissedcriticalstep.Allpromotionsaremanual,andrunashellscriptastheactualpromotion.Logheadfromanincorrectpromotionexamplelog:{quote}StartedbyuserilijabBuildingremotelyonbuildslave4inworkspace/var/lib/jenkins/workspace/esensor-corePromotingesensor-core#93[esensor-core]$/bin/bash-xe/tmp/hudson5568737232874898866.sh...{quote}Logheadfromacorrectpromotionofthesamejob,runearlierinthedaywithnoproductorbuildchanges:{quote}StartedbyuserwfangBuildingremotelyonbuildslave1inworkspace/var/lib/jenkins/workspace/esensor-corePromotingesensor-core#92{color:red}Copied2artifactsfromesensor-corebuildnumber92{color}buildhudson.plugins.copyartifact.CopyArtifact@144ec690SUCCESS{quote}...Ascanbeseen,thepromotionsometimescopiesthecorrectartifactsfrommaster : ,andsometimesincorrectlydecidesnotto.Sincethepromotionrunsonanarbitraryhostinthecluster,oldworkspacecontentsaregenerallypresentanditisnotclearwhyitdecidestowronglyskipthecopystep.
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
[JIRA] [docker-build-step-plugin] (JENKINS-27821) Docker Build Step Plugin: Unable to correctly install
Title: Message Title John Mellor closed an issue as Fixed Recommended solution to move from JDK-6 to JDK-7 works and seems reasonable. Jenkins / JENKINS-27821 Docker Build Step Plugin: Unable to correctly install Change By: John Mellor Status: Resolved Closed 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-28069) Build failures due to artifacts being lost by jenkins 1.610
Title: Message Title John Mellor updated an issue Jenkins / JENKINS-28069 Build failures due to artifacts being lost by jenkins 1.610 Change By: John Mellor Summary: Builf Build failuresduetoartifactsbeinglostbyjenkins1.610 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] [promoted-builds-plugin] (JENKINS-15980) Promotion job doesn't execute on the same machine that the build job executed on.
Title: Message Title John Mellor commented on JENKINS-15980 Re: Promotion job doesn't execute on the same machine that the build job executed on. Can we bump this up in priority and get a fix? Its a royal pain to have to hack around it, since it is normal for the promotion to pick a different server than the build artifacts exist on. Simply forcing the promotion to run on the same machine would resolve most of the angst with this plugin and remove most of the need for the published hack of using the copy-artifact plugin to another host, to work around the real issue. My local unix/linux workaround for this issue is to add a stanza to the promotion script to copy the artifacts to the current host. Its not pretty, but it works until this issue gets fixed. HACK: The artifacts may be on a different build host mkdir -p $ARTIFACTS PROMOTED_HOST=`echo $PROMOTED_URL | sed 's%^http://#40;.*#41;:.*%\1%'` scp $PROMOTED_HOST:jobs/$PROMOTED_JOB_NAME/builds/$PROMOTED_NUMBER/archive/$ARTIFACTS/* $ARTIFACTS 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-28069) Builf failures due to artifacts being lost by jenkins 1.610
John Mellor created JENKINS-28069 Builf failures due to artifacts being lost by jenkins 1.610 Issue Type: Bug Assignee: Unassigned Components: core Created: 23/Apr/15 2:10 PM Description: Updating from Jenkins 1.609 to 1.610 causes artifacts that are actually present to become invisible to Jenkins, causing incorrect product build failures. I have multiple builds showing the same problem using several different build mechanisms. All show a bogus failure to see the artifact. All components and plugins are up-to-date. Reverting back to Jenkins 1.609 corrects the problem. Example build log excerpt showing impossible operation follows. The artifact is successfully moved to a subdir, followed by several empty build steps (commented out to isolate the bug), followed by artifact archiving in the post-build actions. The missing artifact is actually present in the expected place, as verified manually. However, Jenkins cannot see it. Possible fatal error in the artifact archiving code in 1.610? . . . 00:05:26.255 + mkdir -p build/trusty 00:05:26.257 + mv build/cape_1.6.0-1~develop~e239_amd64.deb build/trusty/ 00:05:26.275 + exit 0 00:05:26.295 cape_develop $ /bin/bash -xe /tmp/hudson3392614376804147389.sh 00:05:26.339 cape_develop $ /bin/bash -xe /tmp/hudson150957069606062707.sh 00:05:26.376 cape_develop $ /bin/bash -xe /tmp/hudson2456916382110583231.sh 00:05:26.417 cape_develop $ /bin/bash -xe /tmp/hudson782672795510148539.sh 00:05:26.454 cape_develop $ /bin/bash -xe /tmp/hudson3270660334305912197.sh 00:05:27.502 Archiving artifacts 00:05:32.094 ERROR: Failed to archive artifacts: build/trusty/*.deb 00:05:32.094 java.io.IOException: Failed to extract /var/lib/jenkins/workspace/cape_develop/transfer of 1 files 00:05:32.094 at hudson.FilePath.readFromTar(FilePath.java:2299) 00:05:32.094 at hudson.FilePath.copyRecursiveTo(FilePath.java:2208) 00:05:32.094 at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61) 00:05:32.094 at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:219) 00:05:32.094 at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) 00:05:32.094 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 00:05:32.094 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) 00:05:32.094 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) 00:05:32.094 at hudson.model.Build$BuildExecution.post2(Build.java:183) 00:05:32.094 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) 00:05:32.094 at hudson.model.Run.execute(Run.java:1766) 00:05:32.094 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 00:05:32.094 at hudson.model.ResourceController.execute(ResourceController.java:98) 00:05:32.094 at hudson.model.Executor.run(Executor.java:374) 00:05:32.094 Caused by: java.io.IOException: Truncated TAR archive 00:05:32.094 at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.read(TarArchiveInputStream.java:614) 00:05:32.094 at java.io.InputStream.read(InputStream.java:101) 00:05:32.094 at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1792) 00:05:32.094 at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1769) 00:05:32.094 at org.apache.commons.io.IOUtils.copy(IOUtils.java:1744) 00:05:32.094 at hudson.util.IOUtils.copy(IOUtils.java:40) 00:05:32.094 at hudson.FilePath.readFromTar(FilePath.java:2289) 00:05:32.094 ... 13 more 00:05:32.094 Build step 'Archive the artifacts' changed build result to FAILURE Environment: Ubuntu 12.04.1 64bit, JDK-6 (the default openJDK6b24-1.11.5) Project: Jenkins Priority: Major Reporter: John Mellor
[JIRA] [docker-build-step-plugin] (JENKINS-27821) Docker Build Step Plugin: Unable to correctly install
John Mellor created JENKINS-27821 Docker Build Step Plugin: Unable to correctly install Issue Type: Bug Assignee: vjuranek Components: docker-build-step-plugin Created: 07/Apr/15 5:25 PM Description: Unable to successfully install the docker buildstep plugin - apparent API mismatch. Plugin install log: java.io.IOException: Failed to dynamically deploy this plugin at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1322) at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1121) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:110) at java.lang.Thread.run(Thread.java:679) Caused by: java.io.IOException: Failed to initialize docker-build-step plugin at hudson.PluginManager.dynamicLoad(PluginManager.java:488) at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1318) ... 6 more Caused by: org.jvnet.hudson.reactor.ReactorException: java.lang.Error: java.lang.reflect.InvocationTargetException at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:269) at jenkins.InitReactorRunner.run(InitReactorRunner.java:44) at hudson.PluginManager.dynamicLoad(PluginManager.java:486) ... 7 more Caused by: java.lang.Error: java.lang.reflect.InvocationTargetException at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:110) at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:176) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:282) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:210) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) ... 1 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:106) ... 7 more Caused by: java.lang.UnsupportedClassVersionError: com/github/dockerjava/api/model/ExposedPort : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:634) at jenkins.util.AntClassLoader.defineClassFromData(AntClassLoader.java:1138) at hudson.ClassicPluginStrategy$AntClassLoader2.defineClassFromData(ClassicPluginStrategy.java:799) at jenkins.util.AntClassLoader.getClassFromStream(AntClassLoader.java:1309) at jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1365) at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1325) at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1078) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) at org.jenkinsci.plugins.dockerbuildstep.PluginImpl.addXStreamAliases(PluginImpl.java:19) ... 12 more Environment: Ubuntu 12.04.1, Jenkins 1.607, no out-of-date components Project: Jenkins Labels: plugin exception installation failed Priority: Major Reporter: John Mellor
[JIRA] [next-build-number-plugin] (JENKINS-27314) NextBuildNumber Plugin hangs with latest Jenkins
John Mellor updated JENKINS-27314 NextBuildNumber Plugin hangs with latest Jenkins Thread dump as requested, while the web page is not responding. Web page and components saved as a single .tar.gz file Change By: John Mellor (10/Mar/15 5:34 PM) Attachment: ThreadDump.tgz 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] [next-build-number-plugin] (JENKINS-27314) NextBuildNumber Plugin hangs with latest Jenkins
John Mellor created JENKINS-27314 NextBuildNumber Plugin hangs with latest Jenkins Issue Type: Bug Assignee: Dean Yu Components: next-build-number-plugin Created: 10/Mar/15 3:22 PM Description: Somewhere between Jenkins 1.590 and 1.602, something broke wrt. the NextBuildNumber plugin. I've been replicating a number of freestyle multi-branch jobs as numerous freestyle simple jobs (b/c the multi-branch plugin is also no longer functioning properly), and needed to change the next build number to correspond to the numbers in the old multi-branch jobs. When you confirm the number change, the plugin never returns to the user, although it does alter the next build number. With default logging, nothing is logged - it just does not come back until you eventually get a browser timeout. Environment: Jenkins 1.602 (latest), Ubuntu 12.04.1, java-6-openjdk-amd64, next-build-number plugin 1.1 (latest) Project: Jenkins Priority: Major Reporter: John Mellor 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] [promoted-builds-plugin] (JENKINS-27032) Promotion of a build in a multi-branch project fails totally
John Mellor created JENKINS-27032 Promotion of a build in a multi-branch project fails totally Issue Type: Bug Assignee: Unassigned Attachments: promotion-traceback.txt Components: promoted-builds-plugin Created: 19/Feb/15 3:57 PM Description: Starting a promotion of a build in a specific branch of a multi-branch project gives an empty promotions page. There is no promotion possible. Stepping back out to the parent multi-branch project and clicking the promotion icon gives a promotion rule unexpectedly. At this layer of a multi-branch project, the promotion plugin has no means of identifying which branch to promote. Running it anyways results in an attempt to promote artifacts from the parent project directory, resulting in an inability to find the artifacts and a traceback. Traceback attached. Promotion not working. Workaround available: The promotion runs a shellscript that signs the artifact debian packages and pushes them to a repository. Manually running the script completes normally. It would appear that the multi-branch plugin and the promotion plugin do not work together, as the promotion plugin is too brittle to handle $WORKSPACE being down one more directory level than in a single-branch project. Environment: Ubuntu 12.04.1, Jenkins 1.599 (latest), promoted builds plugin 2.20 (latest), multi-branch plugin 0.1.3 Project: Jenkins Priority: Major Reporter: John Mellor 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] [freestyle-multibranch-plugin] (JENKINS-26815) Per-branch trigger configuration
John Mellor commented on JENKINS-26815 Per-branch trigger configuration (Literate projects, which also use the multibranch system, keep the list of all build steps in a file in SCM. . . . This looks interesting. However, according to its current description, the Literate plugin is not production-ready, and should only be used in test environments. Is this view now outdated and how safe is it? How far from release is it? Unfortunately, with 180+ active projects being built on-demand here, I do not have enough time left in a day to also debug and work around problems in the plugin. 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] [freestyle-multibranch-plugin] (JENKINS-26815) Per-branch trigger configuration
John Mellor updated JENKINS-26815 Per-branch trigger configuration Jenkins systemInfo output via wget from one of my build machines. Builds are all Debian packages built from primarily C++ and a small amounts of Python, Perl and _javascript_, with a smattering of other languages. There are no Java components being built. Change By: John Mellor (06/Feb/15 7:10 PM) Attachment: systemInfo 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.
