[JIRA] (JENKINS-42768) Builds hang if ECS host leave cluster
Title: Message Title John Hovell created an issue Jenkins / JENKINS-42768 Builds hang if ECS host leave cluster Issue Type: New Feature Assignee: Jan Roehrich Components: amazon-ecs-plugin Created: 2017/Mar/14 7:39 PM Priority: Minor Reporter: John Hovell Not sure if this ECS specific or a more general JNLP issue. One of the main use cases of using Docker for builds is to isolate the VM/hardware performing builds from the build system. As such if an ECS host is removed from the cluster (scaling, spot instance gets outbid, hosts replaced/upgraded) any slave jobs running on this host will never get restarted on a different host. This manifests as a bunch of different errors mostly related to not being able to connect to the specific ECS slave that was doing the build: Example1: Cannot contact ecs-mycluster-3ec9178c860: java.io.IOException: remote file operation failed: /home/jenkins/workspace/nd_my-build-3FBTDD6B4SFOB7TWNY6VBPSYYH6DRQTTK6UHDJWRBBMUEXUBV2BQ at hudson.remoting.Channel@66dfe171:Channel to /172.31.4.13: hudson.remoting.ChannelClosedException: channel is already closed Example 2: Cannot contact ecs-majstg-3dc6b7ce91d: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected EOF while receiving the data from the channel. FIFO buffer has been already closed Is this an ECS plugin issue or a more general issue/limitation with Jenkins slaves? How are people using this plugin with spot instances or in general coordinating ECS hosts leaving/entering the cluster?
[JIRA] (JENKINS-36121) Github Branch Source plugin trips api rate limit
Title: Message Title John Hovell commented on JENKINS-36121 Re: Github Branch Source plugin trips api rate limit Michael Neale I created https://issues.jenkins-ci.org/browse/JENKINS-42387 I wasn't sure if it might be a duplicate. I am not aware of how I could use folders to mitigate this issue. Is there some documentation somewhere? With the deprecated github organization folder plugin, Googling is failing me. I do not see any obvious ways to add folders or further organization to my single github organization. Thanks! 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-42387) Ability to add or delete single repository by name
Title: Message Title John Hovell created an issue Jenkins / JENKINS-42387 Ability to add or delete single repository by name Issue Type: New Feature Assignee: Unassigned Components: github-branch-source-plugin Created: 2017/Mar/01 1:54 AM Priority: Minor Reporter: John Hovell One use case of the github-branch-source-plugin is to be able to efficiently add a single repo by name when a new project is kicked off or its builds are migrated to using a Jenkinsfile. Due to https://issues.jenkins-ci.org/browse/JENKINS-36121 as well as the fact that scanning an entire repo can take 10 minutes or more, it would be desirable when a new repository is created to simply add the repo to the organization. As a corollary when projects are no longer needed, it would be desirable to quickly remove the single repo from the list of projects. This accomplishes: much faster to add a single repo as user does not wait for entire org to be scanned fewer unintended side effects as scanning the repo may add or delete (or trigger) jobs that the user does not know about. Scales better as right now it's not really possible to do more than one org scan per hour without running out of API calls and thus disabling further scans, causing builds to get deleted and all interaction with Github API to be disabled until API call limits are reset
[JIRA] (JENKINS-40594) submitterParameter does not work without at least one actual parameter
Title: Message Title John Hovell edited a comment on JENKINS-40594 Re: submitterParameter does not work without at least one actual parameter Sorry just commented on incorrect repo ticket . Confirmed this behavior is what I see as well in 2.5 of input step plugin. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-40594) submitterParameter does not work without at least one actual parameter
Title: Message Title John Hovell commented on JENKINS-40594 Re: submitterParameter does not work without at least one actual parameter Sorry just commented on incorrect repo. Confirmed this behavior is what I see as well in 2.5 of input step plugin. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36121) Github Branch Source plugin trips api rate limit
Title: Message Title John Hovell commented on JENKINS-36121 Re: Github Branch Source plugin trips api rate limit I realize this is a bit off topic but is there a separate issue for having a feature to just add a new repository (or delete a no longer needed repo) by name instead of needing to scan the entire org to pick up a new repo? I feel like this would eliminate 99% of the use cases to need to scan the organization at all. Thanks! 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-40594) submitterParameter does not work without at least one actual parameter
Title: Message Title John Hovell updated an issue Jenkins / JENKINS-40594 submitterParameter does not work without at least one actual parameter Change By: John Hovell Comment: I realize this is a bit off topic but is there a separate issue for having a feature to just add a new repository (or delete a no longer needed repo) by name instead of needing to scan the entire org to pick up a new repo? I feel like this would eliminate 99% of the use cases to need to scan the organization at all. Thanks! 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-40594) submitterParameter does not work without at least one actual parameter
Title: Message Title John Hovell commented on JENKINS-40594 Re: submitterParameter does not work without at least one actual parameter I realize this is a bit off topic but is there a separate issue for having a feature to just add a new repository (or delete a no longer needed repo) by name instead of needing to scan the entire org to pick up a new repo? I feel like this would eliminate 99% of the use cases to need to scan the organization at all. Thanks! 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-36121) Github Branch Source plugin trips api rate limit
Title: Message Title John Hovell commented on JENKINS-36121 Re: Github Branch Source plugin trips api rate limit Noticed the collaborators call (it's in the organization sync log as well) and thought it was strange as I wasn't sure why it would be needed. Happy to provide full logs or anything else if it's of help debugging. 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-36121) Github Branch Source plugin trips api rate limit
Title: Message Title John Hovell commented on JENKINS-36121 Re: Github Branch Source plugin trips api rate limit Michael Neale - 120 repos, all but ~5 are private, most of which do not use this plugin (yet) but many which sadly have a large number of branches (I found 1 repo with 250 branches, an artifact of some other tool). We're experimenting using branch name filters for our critical projects, but since the repo filter needs to be a regex and we have a large number of repos it seems challenging to maintain a regex that includes the right repos. An aside - looks like each repo scanned is requiring ~10 API calls per repo per branch? I have been curling https://api.github.com/rate_limit as the repo refresh process is occurring & can watch it steadily drop scanning 2 branches on all repos consumed about 2000 API calls from the 5000 limit per hour github enforces for authenticated users. Still it means we need to make sure no one triggers a rescan more than once per hour at most. Jacob Foster - thank you I did see your comment earlier. I am not a Jenkins plugin developer & wasn't quite sure how to build & install a patch to a plugin. If there are some documentation on how to do this I'd definitely give it a try though I'm not sure what drawbacks exist (other than the obvious needing to keep your fork maintained as the project moves forward) Thanks for the quick response! The power of this plugin is awesome, it's changed the way we work, just challenging to keep running for larger orgs. 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
[JIRA] (JENKINS-36121) Github Branch Source plugin trips api rate limit
Title: Message Title John Hovell commented on JENKINS-36121 Re: Github Branch Source plugin trips api rate limit I'm having trouble following the 30+ comments all the other open issues surrounding Github rate limits, but this seems to have gotten much worse not better than me. Now when re-scanning hits the rate limit, not only can I not perform more builds or scan for new jobs, but the jobs that got scanned after the rate limit (myproject-c through myproject-g in my example) actually get deleted since the plugin concludes they no longer exist, then completes with "SUCCESS". Is this plugin considered experimental or do you advise downgrading to 1.x? Has anyone had luck contacting Github & getting API rate limits increased? Really feeling dead in the water here as we need to disable all Github scanning for fear of losing current jobs and not being able to perform other Github operations. Example log: ... many branches repos scanned successfully, followed by eventually many similar exceptions and finally projects that can no longer be scanned getting removed from our list of jobs: ERROR: Failed to create or update a subproject my-project-a org.jenkinsci.plugins.github_branch_source.RateLimitExceededException: GitHub API rate limit exceeded at org.jenkinsci.plugins.github_branch_source.Connector$1.onError(Connector.java:259) at org.kohsuke.github.Requester.handleApiError(Requester.java:649) at org.kohsuke.github.Requester._to(Requester.java:284) at org.kohsuke.github.Requester.to(Requester.java:225) at org.kohsuke.github.GitHub.checkApiUrlValidity(GitHub.java:669) at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource.retrieve(GitHubSCMSource.java:414) at jenkins.scm.api.SCMSource._retrieve(SCMSource.java:300) at jenkins.scm.api.SCMSource.fetch(SCMSource.java:254) at jenkins.branch.MultiBranchProjectFactory$BySCMSourceCriteria.recognizes(MultiBranchProjectFactory.java:260) at jenkins.branch.OrganizationFolder$SCMSourceObserverImpl$1.recognizes(OrganizationFolder.java:1153) at jenkins.branch.OrganizationFolder$SCMSourceObserverImpl$1.complete(OrganizationFolder.java:1168) at org.jenkinsci.plugins.github_branch_source.GitHubSCMNavigator.add(GitHubSCMNavigator.java:459) at org.jenkinsci.plugins.github_branch_source.GitHubSCMNavigator.visitSources(GitHubSCMNavigator.java:319) at jenkins.branch.OrganizationFolder.computeChildren(OrganizationFolder.java:398) at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:219) at com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:141) at jenkins.branch.OrganizationFolder$OrganizationScan.run(OrganizationFolder.java:849) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:404) [Fri Feb 10 03:44:40 UTC 2017] Finished organization scan. Scan took 9 min 21 sec Evaluating orphaned items in My Organization. Will not remove myproject-b as MyOrganization Inc. » myproject-b » master #3 is still in progress Will remove myproject-c as it is #1 in the list Will remove myproject-d as it is #2 in the list Will remove myproject-e as it is #3 in the list Will remove myproject-f as it is #4 in the list Will remove myproject-g as it is #5 in the list Finished: SUCCESS
[JIRA] (JENKINS-31396) Access to submitter ID from return value of input step
Title: Message Title John Hovell commented on JENKINS-31396 Re: Access to submitter ID from return value of input step It seems necessary to include at least one custom parameter. For example this will work: def inputResponse = input(message: 'Should we proceed', submitter: "myorg*myteam", submitterParameter: 'approver', parameters:[booleanParam(defaultValue: false, description: '', name: 'promote')] ) But the more sensible simplification returns null: def inputResponse = input(message: 'Should we proceed', submitter: "myorg*myteam", submitterParameter: 'approver' ) Is this expected? 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-41148) Jenkins Pipeline still uses --force=yes for Docker Pipeline plugin
Title: Message Title John Hovell commented on JENKINS-41148 Re: Jenkins Pipeline still uses --force=yes for Docker Pipeline plugin On closer examination, there was a bug in my code. This just happened to be the last message in the log and looked like an error, but I think the || operator renders this error harmless, just log noise Jack Brooks. 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-41148) Jenkins Pipeline still uses --force=yes for Docker Pipeline plugin
Title: Message Title John Hovell commented on JENKINS-41148 Re: Jenkins Pipeline still uses --force=yes for Docker Pipeline plugin Any known workaround? (other than don't use plugin and write docker commands in sh directly)? Just ran into this issue after upgrading to Docker 1.12.6 (from 1.11.2). Also affects Jenkins 2.32.1. Running Ubuntu Xenial 16.04. Surprised more people aren't running into this? 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.
