[JIRA] (JENKINS-61290) Hard to see if branch was skipped because of discovery strategy
Title: Message Title Jim Klimov edited a comment on JENKINS-61290 Re: Hard to see if branch was skipped because of discovery strategy As a stop-gap solution that I hopefully know how to make, I would add jenkins console logging right into the `isExcluded()` methods, where they `return true`, so at least part of investigation like the one I did, would become easier.This is sub-par because the message would not appear where it is helpful to people with access to the indexing job log, but at least is something... https://github.com/jenkinsci/github-branch-source-plugin/pull/284 Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204867.1583144626000.2600.1583151420047%40Atlassian.JIRA.
[JIRA] (JENKINS-61290) Hard to see if branch was skipped because of discovery strategy
Title: Message Title Jim Klimov commented on JENKINS-61290 Re: Hard to see if branch was skipped because of discovery strategy As a stop-gap solution that I hopefully know how to make, I would add jenkins console logging right into the `isExcluded()` methods, where they `return true`, so at least part of investigation like the one I did, would become easier. This is sub-par because the message would not appear where it is helpful to people with access to the indexing job log, but at least is something... Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204867.1583144626000.2398.1583144880134%40Atlassian.JIRA.
[JIRA] (JENKINS-61290) Hard to see if branch was skipped because of discovery strategy
Title: Message Title Jim Klimov created an issue Jenkins / JENKINS-61290 Hard to see if branch was skipped because of discovery strategy Issue Type: Improvement Assignee: Unassigned Components: github-branch-source-plugin Created: 2020-03-02 10:23 Priority: Minor Reporter: Jim Klimov I was recently trying to figure out why one of our branches got disabled and no longer built, not even looking at `Jenkinsfile` presence, and I followed a wrong trail for very long (assumed we have a github cache issue again, taking false-negative responses from old GH site bugs cached by our master... as it happened last year...) But in the end by chance found that the setup is to not process branches that also have PRs opened from them, and indeed someone made the PR So got two questions: 1) I want a message telling why a branch was skipped! I sort of found where in github-branch-source-plugin code it begins "Checking branch" https://github.com/jenkinsci/github-branch-source-plugin/blob/master/src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java#L987 ... and where it decides it is no good https://github.com/jenkinsci/github-branch-source-plugin/blob/master/src/main/java/org/jenkinsci/plugins/github_branch_source/BranchDiscoveryTrait.java#L230 ...but a lot of java voodoo happens in-between, so I have no idea where to plug in such logging that it would end up on the branch indexing console So if someone knowledgeable could pick it up to do properly, would be nice There are only a few hits of "isExcluded" and mostly in events processing (so not sure if it applies to polling/indexing discoveries) but I think they also do not have a "listener" from which I could "getLogger()". Maybe throwing an exception could do it, but would likely disrupt the existing processing loops :\ 2) is there/can someone add some complex filter to always process branches from a certain name pattern (e.g. `release/*`), even if there are PRs from them?
[JIRA] (JENKINS-60901) GitHub manages hooks even when it has not been configured to do it
Title: Message Title Jim Klimov edited a comment on JENKINS-60901 Re: GitHub manages hooks even when it has not been configured to do it This annoys me too, so finally got to try making a fix:https://github.com/jenkinsci/github-plugin/pull/226 In our use-case, there are a lot of stack traces (probably the majority of what the jenkins instance logs) while there is no credential set up AND the "Manage hooks" is unchecked. So it is supposed to not try managing, somewhat intentionally (our Jenkins is inside corporate perimeter, Github can't access it anyway).Note that according to help message for the "Manage Hooks" checkbox, there may be other places in code where it would check for credentials:> Will this configuration be used to manage credentials for repositories where it> has admin rights? If unchecked, this credentials still can be used to> manipulate commit statuses, but will be ignored to manage hooks.But the noisy (and in our case pointless) error message is only associated with register/unregister activity. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204291.158029885.1384.1582905480394%40Atlassian.JIRA.
[JIRA] (JENKINS-60901) GitHub manages hooks even when it has not been configured to do it
Title: Message Title Jim Klimov commented on JENKINS-60901 Re: GitHub manages hooks even when it has not been configured to do it This annoys me too, so finally got to try making a fix: In our use-case, there are a lot of stack traces (probably the majority of what the jenkins instance logs) while there is no credential set up AND the "Manage hooks" is unchecked. So it is supposed to not try managing, somewhat intentionally (our Jenkins is inside corporate perimeter, Github can't access it anyway). Note that according to help message for the "Manage Hooks" checkbox, there may be other places in code where it would check for credentials: > Will this configuration be used to manage credentials for repositories where it > has admin rights? If unchecked, this credentials still can be used to > manipulate commit statuses, but will be ignored to manage hooks. But the noisy (and in our case pointless) error message is only associated with register/unregister activity. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204291.158029885.1381.1582905480355%40Atlassian.JIRA.
[JIRA] (JENKINS-60673) Swarm agents sometimes disconnect and stay that way forever
Title: Message Title
Jim Klimov updated an issue
Jenkins / JENKINS-60673
Swarm agents sometimes disconnect and stay that way forever
Change By:
Jim Klimov
For context, our Jenkins master server JVM is dedicated to dispatching, with some of the infra jobs handled by an agent running on the same machine in a different account. Some time ago this agent was remade from SSH to Swarm, and over some uptime it tends to disconnect, and or not-connect when the master is too busy :(We had an outage starting a few days ago that was only noticed now as we came back to work, e.g. this being the last logged line:{code} Jan 05 08:59:37 jenkins2 bash[15117]: INFO: Failed to send back a reply to the request hudson.remoting.Request$2@525facc1: hudson.remoting.ChannelClosedException: Channel "unknown": Protocol stack cannot write data anymore. It is not open for write{code}The agent JVM continued running, so neither some logic inside the agent, nor systemd, would restart it to actually reconnect and keep the real service provided. Here the JVM seems to be alive, so nothing is restarted by the OS, and the agent just disappears from master since there is no connection.In fact, preceding lines point to insufficient memory (and I have no idea how much we should throw at it, because with whatever settings we tried it works for days and weeks and then suddenly it does not ; at the moment we have {{java -Xms64m -Xmx512m}} for the agent ).{code}Jan 05 08:59:37 jenkins2 bash[15117]: at java.lang.Thread.run(Thread.java:748)Jan 05 08:59:37 jenkins2 bash[15117]: Caused by: java.lang.OutOfMemoryError: Java heap space{code}
Add Comment
[JIRA] (JENKINS-60673) Swarm agents sometimes disconnect and stay that way forever
Title: Message Title Jim Klimov created an issue Jenkins / JENKINS-60673 Swarm agents sometimes disconnect and stay that way forever Issue Type: Improvement Assignee: Unassigned Components: swarm-plugin Created: 2020-01-07 09:11 Priority: Major Reporter: Jim Klimov For context, our Jenkins master server JVM is dedicated to dispatching, with some of the infra jobs handled by an agent running on the same machine in a different account. Some time ago this agent was remade from SSH to Swarm, and over some uptime it tends to disconnect, and or not-connect when the master is too busy We had an outage starting a few days ago that was only noticed now as we came back to work, e.g. this being the last logged line: Jan 05 08:59:37 jenkins2 bash[15117]: INFO: Failed to send back a reply to the request hudson.remoting.Request$2@525facc1: hudson.remoting.ChannelClosedException: Channel "unknown": Protocol stack cannot write data anymore. It is not open for write The agent JVM continued running, so neither some logic inside the agent, nor systemd, would restart it to actually reconnect and keep the real service provided. Here the JVM seems to be alive, so nothing is restarted by the OS, and the agent just disappears from master since there is no connection. In fact, preceding lines point to insufficient memory (and I have no idea how much we should throw at it, because with whatever settings we tried it works for days and weeks and then suddenly it does not). Jan 05 08:59:37 jenkins2 bash[15117]: at
[JIRA] (JENKINS-54126) Jenkinsfile not found in PR on GitHub -- Does not meet criteria
Title: Message Title
Jim Klimov edited a comment on JENKINS-54126
Re: Jenkinsfile not found in PR on GitHub -- Does not meet criteria
+1 for the issue that was annoying for so long now, although most often seen on real branches (masters and releases of our project that are really providing a Jenkinsfile)Yes we do use GitHub caching, advocated for it to appear, and hope it stays :) with the poor internet uplink we have, and with github REST API quotas for uncached requests abound, and no possibility to get hooks thus requiring polling, - our farm couldn't really work without it.So I set out digging in the data, and found that cached HTTP-404s in \*.0 files correlate with very short \*.1 files (the compact error message from Github REST API), so selecting those to look deeper:{code}:; find . -name '*.1' -size 1 | sed -e 's,^./,,' -e s',.1$,,' | while read F ; do egrep 'HTTP.*404' "$F.0" >&2 && echo "=== $F" && head -1 "$F.0" && ls -la "$F"* ; done{code}Due to reasons unknown however, the cached response for some of the URLs is HTTP/404 even with a valid JSON in the (gzipped) `hashstring.1` file:{code}{"message":"No commit found for the ref refs/heads/4.2.0-FTY","documentation_url":"https://developer.github.com/v3/repos/contents/"}{code}and the corresponding `hashstring.0` file looks like:{code}:; cat fbe7227813e6f1a6bbb2f1e5202a84a2.0https://api.github.com/repos/42ity/libzmq/contents/?ref=refs%2Fheads%2F4.2.0-FTYGET1Authorization: Basic NDJpdHktY2k6NjA5MDk2YTVmNzNhNTc1YzE1OWYxZjI3NDJlZmI1YjhiMTQzZmIzMw==HTTP/1.1 404 Not Found31X-OAuth-Scopes: admin:repo_hook, public_repo, repo:status, repo_deploymentX-Accepted-OAuth-Scopes:X-GitHub-Media-Type: github.v3; format=jsonContent-Encoding: gzipTransfer-Encoding: chunkedConnection: keep-aliveContent-Type: application/octet-streamX-Cache: MISS from thunderbolt.localdomainX-Cache-Lookup: MISS from thunderbolt.localdomain:8080Via: 1.1 thunderbolt.localdomain (squid/3.4.4)Server: GitHub.comDate: Thu, 28 Nov 2019 00:41:22 GMTStatus: 304 Not ModifiedX-RateLimit-Limit: 5000X-RateLimit-Remaining: 5000X-RateLimit-Reset: 1574905280Cache-Control: private, max-age=60, s-maxage=60Vary: Accept, Authorization, Cookie, X-GitHub-OTPETag: "2513f4bbc2abb8b63adbec8336a82810a4fb5dc5"Last-Modified: Wed, 05 Dec 2018 10:54:24 GMTAccess-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-TypeAccess-Control-Allow-Origin: *Strict-Transport-Security: max-age=31536000; includeSubdomains; preloadX-Frame-Options: denyX-Content-Type-Options: nosniffX-XSS-Protection: 1; mode=blockReferrer-Policy: origin-when-cross-origin, strict-origin-when-cross-originContent-Security-Policy: default-src 'none'X-GitHub-Request-Id: F066:2FC4:FE494:24E933:5DDF17B1OkHttp-Sent-Millis: 1574901681913OkHttp-Received-Millis:
[JIRA] (JENKINS-54126) Jenkinsfile not found in PR on GitHub -- Does not meet criteria
Title: Message Title
Jim Klimov edited a comment on JENKINS-54126
Re: Jenkinsfile not found in PR on GitHub -- Does not meet criteria
+1 for the issue that was annoying for so long now , although most often seen on real branches (masters and releases of our project that are really providing a Jenkinsfile) Yes we do use GitHub caching, advocated for it to appear, and hope it stays :) with the poor internet uplink we have, and with github REST API quotas for uncached requests abound, and no possibility to get hooks thus requiring polling, - our farm couldn't really work without it.So I set out digging in the data, and found that cached HTTP-404s in \*.0 files correlate with very short \*.1 files (the compact error message from Github REST API), so selecting those to look deeper:{code}:; find . -name '*.1' -size 1 | sed -e 's,^./,,' -e s',.1$,,' | while read F ; do egrep 'HTTP.*404' "$F.0" >&2 && echo "=== $F" && head -1 "$F.0" && ls -la "$F"* ; done{code}Due to reasons unknown however, the cached response for some of the URLs is HTTP/404 even with a valid JSON in the (gzipped) `hashstring.1` file:{code}{"message":"No commit found for the ref refs/heads/4.2.0-FTY","documentation_url":"https://developer.github.com/v3/repos/contents/"}{code}and the corresponding `hashstring.0` file looks like:{code}:; cat fbe7227813e6f1a6bbb2f1e5202a84a2.0https://api.github.com/repos/42ity/libzmq/contents/?ref=refs%2Fheads%2F4.2.0-FTYGET1Authorization: Basic NDJpdHktY2k6NjA5MDk2YTVmNzNhNTc1YzE1OWYxZjI3NDJlZmI1YjhiMTQzZmIzMw==HTTP/1.1 404 Not Found31X-OAuth-Scopes: admin:repo_hook, public_repo, repo:status, repo_deploymentX-Accepted-OAuth-Scopes:X-GitHub-Media-Type: github.v3; format=jsonContent-Encoding: gzipTransfer-Encoding: chunkedConnection: keep-aliveContent-Type: application/octet-streamX-Cache: MISS from thunderbolt.localdomainX-Cache-Lookup: MISS from thunderbolt.localdomain:8080Via: 1.1 thunderbolt.localdomain (squid/3.4.4)Server: GitHub.comDate: Thu, 28 Nov 2019 00:41:22 GMTStatus: 304 Not ModifiedX-RateLimit-Limit: 5000X-RateLimit-Remaining: 5000X-RateLimit-Reset: 1574905280Cache-Control: private, max-age=60, s-maxage=60Vary: Accept, Authorization, Cookie, X-GitHub-OTPETag: "2513f4bbc2abb8b63adbec8336a82810a4fb5dc5"Last-Modified: Wed, 05 Dec 2018 10:54:24 GMTAccess-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-TypeAccess-Control-Allow-Origin: *Strict-Transport-Security: max-age=31536000; includeSubdomains; preloadX-Frame-Options: denyX-Content-Type-Options: nosniffX-XSS-Protection: 1; mode=blockReferrer-Policy: origin-when-cross-origin, strict-origin-when-cross-originContent-Security-Policy: default-src 'none'X-GitHub-Request-Id: F066:2FC4:FE494:24E933:5DDF17B1OkHttp-Sent-Millis: 1574901681913OkHttp-Received-Millis:
[JIRA] (JENKINS-54126) Jenkinsfile not found in PR on GitHub -- Does not meet criteria
Title: Message Title
Jim Klimov edited a comment on JENKINS-54126
Re: Jenkinsfile not found in PR on GitHub -- Does not meet criteria
+1 for the issue that was annoying for so long nowYes we do use GitHub caching, advocated for it to appear, and hope it stays :) with the poor internet uplink we have, and with github REST API quotas for uncached requests abound, and no possibility to get hooks thus requiring polling, - our farm couldn't really work without it. So I set out digging in the data, and found that cached HTTP-404s in \*.0 files correlate with very short \*.1 files (the compact error message from Github REST API), so selecting those to look deeper: {code} :; find . -name '*.1' -size 1 | sed -e 's,^./,,' -e s',.1$,,' | while read F ; do egrep 'HTTP.*404' "$F.0" >&2 && echo "=== $F" && head -1 "$F.0" && ls -la "$F"* ; done {code} Due to reasons unknown however, the cached response for some of the URLs is HTTP/404 even with a valid JSON in the (gzipped) `hashstring.1` file: {code} {"message":"No commit found for the ref refs/heads/4.2.0-FTY","documentation_url":"https://developer.github.com/v3/repos/contents/"} {code} and the corresponding `hashstring.0` file looks like: {code} :; cat fbe7227813e6f1a6bbb2f1e5202a84a2.0https://api.github.com/repos/42ity/libzmq/contents/?ref=refs%2Fheads%2F4.2.0-FTYGET1Authorization: Basic NDJpdHktY2k6NjA5MDk2YTVmNzNhNTc1YzE1OWYxZjI3NDJlZmI1YjhiMTQzZmIzMw==HTTP/1.1 404 Not Found31X-OAuth-Scopes: admin:repo_hook, public_repo, repo:status, repo_deploymentX-Accepted-OAuth-Scopes:X-GitHub-Media-Type: github.v3; format=jsonContent-Encoding: gzipTransfer-Encoding: chunkedConnection: keep-aliveContent-Type: application/octet-streamX-Cache: MISS from thunderbolt.localdomainX-Cache-Lookup: MISS from thunderbolt.localdomain:8080Via: 1.1 thunderbolt.localdomain (squid/3.4.4)Server: GitHub.comDate: Thu, 28 Nov 2019 00:41:22 GMTStatus: 304 Not ModifiedX-RateLimit-Limit: 5000X-RateLimit-Remaining: 5000X-RateLimit-Reset: 1574905280Cache-Control: private, max-age=60, s-maxage=60Vary: Accept, Authorization, Cookie, X-GitHub-OTPETag: "2513f4bbc2abb8b63adbec8336a82810a4fb5dc5"Last-Modified: Wed, 05 Dec 2018 10:54:24 GMTAccess-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-TypeAccess-Control-Allow-Origin: *Strict-Transport-Security: max-age=31536000; includeSubdomains; preloadX-Frame-Options: denyX-Content-Type-Options: nosniffX-XSS-Protection: 1; mode=blockReferrer-Policy: origin-when-cross-origin, strict-origin-when-cross-originContent-Security-Policy: default-src 'none'X-GitHub-Request-Id: F066:2FC4:FE494:24E933:5DDF17B1OkHttp-Sent-Millis: 1574901681913OkHttp-Received-Millis:
[JIRA] (JENKINS-54126) Jenkinsfile not found in PR on GitHub -- Does not meet criteria
Title: Message Title
Jim Klimov commented on JENKINS-54126
Re: Jenkinsfile not found in PR on GitHub -- Does not meet criteria
+1 for the issue that was annoying for so long now Yes we do use GitHub caching, advocated for it to appear, and hope it stays So I set out digging in the data, and found that cached HTTP-404s in *.0 files correlate with very short *.1 files (the compact error message from Github REST API), so selecting those to look deeper: :; find . -name '.1' -size 1 | sed -e 's,^./,,' -e s',.1$,,' | while read F ; do egrep 'HTTP.*404' "$F.0" >&2 && echo "=== $F" && head -1 "$F.0" && ls -la "$F" ; done Due to reasons unknown however, the cached response for some of the URLs is HTTP/404 even with a valid JSON in the (gzipped) `hashstring.1` file: {"message":"No commit found for the ref refs/heads/4.2.0-FTY","documentation_url":"https://developer.github.com/v3/repos/contents/"} and the corresponding `hashstring.0` file looks like: :; cat fbe7227813e6f1a6bbb2f1e5202a84a2.0 https://api.github.com/repos/42ity/libzmq/contents/?ref=refs%2Fheads%2F4.2.0-FTY GET 1 Authorization: Basic NDJpdHktY2k6NjA5MDk2YTVmNzNhNTc1YzE1OWYxZjI3NDJlZmI1YjhiMTQzZmIzMw== HTTP/1.1 404 Not Found 31 X-OAuth-Scopes: admin:repo_hook, public_repo, repo:status, repo_deployment X-Accepted-OAuth-Scopes: X-GitHub-Media-Type: github.v3; format=json Content-Encoding: gzip Transfer-Encoding: chunked Connection: keep-alive Content-Type: application/octet-stream X-Cache: MISS from thunderbolt.localdomain X-Cache-Lookup: MISS from thunderbolt.localdomain:8080 Via: 1.1 thunderbolt.localdomain (squid/3.4.4) Server: GitHub.com Date: Thu, 28 Nov 2019 00:41:22 GMT Status: 304 Not Modified X-RateLimit-Limit: 5000 X-RateLimit-Remaining: 5000 X-RateLimit-Reset: 1574905280 Cache-Control: private, max-age=60, s-maxage=60 Vary: Accept, Authorization, Cookie, X-GitHub-OTP ETag: "2513f4bbc2abb8b63adbec8336a82810a4fb5dc5" Last-Modified: Wed, 05 Dec 2018 10:54:24 GMT Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type Access-Control-Allow-Origin: * Strict-Transport-Security: max-age=31536000; includeSubdomains; preload X-Frame-Options: deny X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin Content-Security-Policy: default-src 'none' X-GitHub-Request-Id: F066:2FC4:FE494:24E933:5DDF17B1 OkHttp-Sent-Millis: 1574901681913 OkHttp-Received-Millis: 1574901682110 TLS_RSA_WITH_AES_128_GCM_SHA256 2
[JIRA] (JENKINS-50191) Multibranch Pipeline tends to keep rebuilding same commits
Title: Message Title Jim Klimov commented on JENKINS-50191 Re: Multibranch Pipeline tends to keep rebuilding same commits For the bit about PR-merge builds, yes this is expected to re-run (once per seen target branch update though!) and part of the design idea about such ephemeral merge branches. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.189212.1521113141000.11213.1573220880417%40Atlassian.JIRA.
[JIRA] (JENKINS-55512) Safe shutdown/restart should not block completion of complex jobs (that spawn child jobs)
Title: Message Title Jim Klimov commented on JENKINS-55512 Re: Safe shutdown/restart should not block completion of complex jobs (that spawn child jobs) See also https://github.com/jenkinsci/jenkins/pull/3920 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.196645.154712346.9308.1572963000218%40Atlassian.JIRA.
[JIRA] (JENKINS-55512) Safe shutdown/restart should not block completion of complex jobs (that spawn child jobs)
Title: Message Title Jim Klimov commented on JENKINS-55512 Re: Safe shutdown/restart should not block completion of complex jobs (that spawn child jobs) For some more alternative approaches, as I recently dug in some other plugins, I wondered if a solution could come from a cannibalized (and adapted by a non-Java developer) copy of `lockable-resources-plugin`? It already has ways to block startup of jobs (waiting for "this resource" which has no instances available) after all, so it seems feasible to just replace the logic from locked resources processing by what I originally proposed for jobs/builds/causes relationships, and allow or block the builds. In fact, it would be less work to make this behavior optional and used only by specific jobs rather than server-wide, because the lockable resource abilities are something one configures in a job (and it would be some effort to find and rip out the relevant bits, going this way). Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.196645.154712346.9309.1572963000232%40Atlassian.JIRA.
[JIRA] (JENKINS-59514) Use @POST instead of @RequirePOST for form submission endpoints
Title: Message Title Jim Klimov commented on JENKINS-59514 Re: Use @POST instead of @RequirePOST for form submission endpoints As long as this does not block "form"al resubmission suggestions for GET URLs, like below, this is LGTM This URL requires POST The URL you're trying to access requires that requests be sent using POST (like a form submission). The button below allows you to retry accessing this URL using POST. URL being accessed: https://jenkins.domain/quietDown If you were sent here from an untrusted source, please proceed with caution. With a 2.198 weekly running, this seems to still work. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202137.156934393.2455.1570451700703%40Atlassian.JIRA.
[JIRA] (JENKINS-59317) Spurious SCM change with a failed git call (e.g. network error)
Title: Message Title
Jim Klimov created an issue
Jenkins / JENKINS-59317
Spurious SCM change with a failed git call (e.g. network error)
Issue Type:
Improvement
Assignee:
Mark Waite
Components:
git-plugin
Created:
2019-09-11 14:07
Priority:
Minor
Reporter:
Jim Klimov
Our internal build farm's connection to the internet has its flaws, ups and downs, and sometimes during the downs we see gems like this: an effectively failed SCM poll ("Couldn't get remote head revision") is interpreted as a "Changes found" situation, and causes a build "Started by an SCM change", as the (failed) build's Polling Log says: Polling Log This page captures the polling log that triggered this build. Started on Sep 7, 2019 6:15:15 AM Using strategy: Specific revision [poll] Last Built Revision: Revision dee1deac2b8bc60039ea3cd2907afa708a967486 (release/IPM_Infra-1.4) using credential 955c217d-8133-41c2-9235-9ce3936ddca6 > git --version # timeout=10 using GIT_ASKPASS to set credentials 42ity-ci GH Token as password Setting http proxy: thunderbolt.roz.lab.etn.com:8081 > git ls-remote -h https://github.com/42ity/fty-outage.git # timeout=10 Unexpected ls-remote output line '' [poll] Couldn't get remote head revision Done. Took 23 sec Changes found In this particular situation (outage) as a result, this build fails quickly during checkout of sources with ``` ... Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress https://github.com/42ity/fty-outage.git +refs/heads/release/IPM_Infra-1.4:refs/remotes/origin/release/IPM_Infra-1.4" returned status code 128: stdout: stderr: fatal: unable to access 'https://github.com/42ity/fty-outage.git/': The requested URL returned error: 503 ... ``` which is a reasonable outcome of a network outage (our proxy failed to fetch => 503)... however when the network comes back, the last-tried (green, long ago) revision is the same as the current HEAD, so no need to rebuild, as the branch's Git polling log says: Git Polling Log
[JIRA] (JENKINS-58935) For pipeline context, devise a way to generalize the config options and notification steps for all IM protocols
Title: Message Title
Jim Klimov created an issue
Jenkins / JENKINS-58935
For pipeline context, devise a way to generalize the config options and notification steps for all IM protocols
Issue Type:
Improvement
Assignee:
Christopher Orr
Components:
gcm-notification-plugin, instant-messaging-plugin, ircbot-plugin, jabber-plugin, skype-plugin
Created:
2019-08-14 15:27
Priority:
Minor
Reporter:
Jim Klimov
The instant-messaging-plugin since release 1.37 provides the shareable core functionality for pipeline integration, used by step implementations in ircbot-plugin (since 2.31) and jabber-plugin (merge and release pending). Hopefully over time other protocol plugins would catch up. It sounds reasonable to implement a generic notification step (and `options{}` support eventually) that would send messages with a single command in the pipeline script without worries about which IM protocols are set up in a particular build farm, making the codebase and recipes for it more portable.
Add Comment
[JIRA] (JENKINS-58934) For pipeline context, add an "options{...}" or similar clause trigger for IM notifications without an explicit step
Title: Message Title
Jim Klimov created an issue
Jenkins / JENKINS-58934
For pipeline context, add an "options{...}" or similar clause trigger for IM notifications without an explicit step
Issue Type:
Improvement
Assignee:
kutzi
Components:
instant-messaging-plugin, ircbot-plugin
Created:
2019-08-14 15:21
Priority:
Minor
Reporter:
Jim Klimov
In order to be feature-equivalent to freestyle jobs IRC Post-build step (which in fact also hooks into pre-build setup), allow to specify once in a pipeline that we want notifications about both start and complete events of this job.
Add Comment
[JIRA] (JENKINS-58933) For pipeline context, add an "options{...}" preset for ircNotify (or generalize for imNotify?)
Title: Message Title
Jim Klimov created an issue
Jenkins / JENKINS-58933
For pipeline context, add an "options{...}" preset for ircNotify (or generalize for imNotify?)
Issue Type:
Improvement
Assignee:
kutzi
Components:
instant-messaging-plugin, ircbot-plugin
Created:
2019-08-14 15:19
Priority:
Minor
Reporter:
Jim Klimov
In order to be feature-equivalent to freestyle jobs, allow to preset this job's notification strategy
Add Comment
This message was sent by Atlassian Jira
[JIRA] (JENKINS-4623) Use build parameter/variable for IM notification recipient
Title: Message Title Jim Klimov edited a comment on JENKINS-4623 Re: Use build parameter/variable for IM notification recipient Partially duplicated by JENKINS-18947 (in the part that both issues ask to notify the user who started a build).With a look at this from 2019, note also that recently there were Jenkins core changes to promote running jobs as different Jenkins accounts, not just as "System". In relation to this story, make sure to NOT notify jobs started automatically, perhaps whether as System or not (the BuildCause's should probably allow to differentiate that), probably including non-human re-runs of such, although should probably it should notify a person who started a parent job that triggered this one with IM notifications enabled. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.134696.125497952.2679.1565787720206%40Atlassian.JIRA.
[JIRA] (JENKINS-4623) Use build parameter/variable for IM notification recipient
Title: Message Title Jim Klimov commented on JENKINS-4623 Re: Use build parameter/variable for IM notification recipient Partially duplicated JENKINS-18947 (in the part that both issues ask to notify the user who started a build). With a look at this from 2019, note also that recently there were Jenkins core changes to promote running jobs as different Jenkins accounts, not just as "System". In relation to this story, make sure to NOT notify jobs started automatically, perhaps whether as System or not (the BuildCause's should probably allow to differentiate that), probably including non-human re-runs of such, although should probably it should notify a person who started a parent job that triggered this one with IM notifications enabled. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.134696.125497952.2677.1565787600234%40Atlassian.JIRA.
[JIRA] (JENKINS-5031) instant-messaging plugin notifications with custom messages
Title: Message Title Jim Klimov commented on JENKINS-5031 Re: instant-messaging plugin notifications with custom messages See also https://issues.jenkins-ci.org/browse/JENKINS-34903?focusedCommentId=373370=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-373370 about concerns on the greater configurability 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.135115.1260200449000.2663.1565787120928%40Atlassian.JIRA.
[JIRA] (JENKINS-11815) Jenkins IRC bot should send help message in private chat
Title: Message Title Jim Klimov commented on JENKINS-11815 Re: Jenkins IRC bot should send help message in private chat I believe this issue is multi-fold and currently: requesting "help" in a private chat with the jenkins IRC user works and does not spam shared room channels (so the declared goal of this issue is achievable for "good actors") requesting "help" in a shared room channel indeed does not cause a private-chat reply, so the "spamming" problem is still there very long lines posted by the jenkins IM client, e.g. a "queue" request with many agents listed as unable to pick up a job due to label constraints, to a private chat can still get it disconnected from all chats (will come back in a few seconds) 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.142058.1321823874000.2660.1565786880400%40Atlassian.JIRA.
[JIRA] (JENKINS-33922) Pipeline support for IRC Notifier
Title: Message Title Jim Klimov resolved as Fixed Jenkins / JENKINS-33922 Pipeline support for IRC Notifier Change By: Jim Klimov Status: Open Resolved Assignee: kutzi Jim Klimov Resolution: Fixed Released As: instant-messaging-plugin-1.38 ircbot-plugin-2.31 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.169411.1459418187000.2646.1565786160973%40Atlassian.JIRA.
[JIRA] (JENKINS-33922) Pipeline support for IRC Notifier
Title: Message Title Jim Klimov commented on JENKINS-33922 Re: Pipeline support for IRC Notifier Thanks to work done by Alexander Komarov for JENKINS-36826 and my subsequent tinkering, this month's releases of instant-messaging-plugin and ircbot-plugin together deliver the `ircNotify` step capability, documented at http://wiki.jenkins-ci.org/display/HUDSON/Instant+Messaging+Plugin and https://wiki.jenkins.io/display/JENKINS/IRC+Plugin respectively. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.169411.1459418187000.2634.1565786100470%40Atlassian.JIRA.
[JIRA] (JENKINS-58928) IRC messages prefixed with priority level by default
Title: Message Title Jim Klimov created an issue Jenkins / JENKINS-58928 IRC messages prefixed with priority level by default Issue Type: Improvement Assignee: Jim Klimov Components: instant-messaging-plugin, ircbot-plugin Created: 2019-08-14 12:10 Priority: Minor Reporter: Jim Klimov Notifications from our Jenkins bot on an IRC channel and in a private chat are prefixed by "(notice)" string. See if it can be removed (perhaps optionally, kept in place by default - maybe someone else relied on it and possibly its other values to filter, highlight, etc. in their IM clients. Not sure at the moment if this applies only to IRC or to other IM protocols as well. Add Comment
[JIRA] (JENKINS-58927) IRC interaction with the bot in a private chat still requires a nickname prefix
Title: Message Title Jim Klimov created an issue Jenkins / JENKINS-58927 IRC interaction with the bot in a private chat still requires a nickname prefix Issue Type: Improvement Assignee: Jim Klimov Components: instant-messaging-plugin, ircbot-plugin Created: 2019-08-14 11:57 Priority: Minor Reporter: Jim Klimov It is reasonable to spell out e.g. "jenkins: jobs" in a channel, but just tedious in a private chat already established with the "jenkins" user in a dedicated IRC client window. Add Comment
[JIRA] (JENKINS-58926) Refactor bot command CLI and results processing (regex filter, line counts) into a single implementation to be shared by different commands
Title: Message Title Jim Klimov created an issue Jenkins / JENKINS-58926 Refactor bot command CLI and results processing (regex filter, line counts) into a single implementation to be shared by different commands Issue Type: Improvement Assignee: Jim Klimov Components: instant-messaging-plugin, ircbot-plugin Created: 2019-08-14 11:55 Priority: Minor Reporter: Jim Klimov By now there are two copies of CLI loop for argument processing and a regex filter of output lines (and of counting them), in "currentlyBuilding" and "queue" bot commands. With more commands on the plate that could be improved with these features, it makes sense to rearrange the codebase so this filtering and counting can be implemented in one place, with only the command-specific logic preparing a multiline buffer of text - that is then postprocessed and sent to a IM channel(s) by the common code. Add Comment
[JIRA] (JENKINS-58925) Revise interaction with user-based permissions to access (list) jobs, builds, queue items...
Title: Message Title Jim Klimov created an issue Jenkins / JENKINS-58925 Revise interaction with user-based permissions to access (list) jobs, builds, queue items... Issue Type: Improvement Assignee: kutzi Components: instant-messaging-plugin, ircbot-plugin Created: 2019-08-14 11:43 Priority: Minor Reporter: Jim Klimov I am not sure whether there is much awareness in the IM plugins about users being not allowed to see some jobs (either for multi-tenancy security, or grouped into teams just to limit the visibility and not be overwhelmed). In order to decide whether some development in this area is worth planning, makes sense to check the code and test behaviors first, on setups with different authorization strategies (e.g. added via extra plugins). Add Comment
[JIRA] (JENKINS-30124) IRC Plugin bot does not see the Folder (CloudBees Folders Plugin) jobs
Title: Message Title Jim Klimov commented on JENKINS-30124 Re: IRC Plugin bot does not see the Folder (CloudBees Folders Plugin) jobs Also, with pipelines (MultiBranch jobs, with configs generated for many branches and PRs across many repos in several organizations our local Jenkins master tracks), a full "jobs" listing for us would be impractical at several thousand lines long (and throttled IIRC to 0.5sec per line posting to an IRC server to avoid flood controls killing the session) so it was not a priority for me to address in our deployment. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.164706.1440502741000.2623.1565782800198%40Atlassian.JIRA.
[JIRA] (JENKINS-30124) IRC Plugin bot does not see the Folder (CloudBees Folders Plugin) jobs
Title: Message Title Jim Klimov updated an issue Jenkins / JENKINS-30124 IRC Plugin bot does not see the Folder (CloudBees Folders Plugin) jobs Change By: Jim Klimov Component/s: instant-messaging-plugin 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.164706.1440502741000.2618.1565782620597%40Atlassian.JIRA.
[JIRA] (JENKINS-30124) IRC Plugin bot does not see the Folder (CloudBees Folders Plugin) jobs
Title: Message Title Jim Klimov commented on JENKINS-30124 Re: IRC Plugin bot does not see the Folder (CloudBees Folders Plugin) jobs This month new versions of ircbot and instant-messaging-plugin were released, which in particular added awareness about pipeline jobs to the "queue" and "currentlyBuilding" commands, and essence the Java-side change for the plugin code was that the inheritance tree of classes was different so new `import` clauses to add awareness and `instanceof` calls to match a job type were the key to list e.g. pipeline jobs and not only the legacy freestyle ones. I did not use the folder plugin yet so can't say if its classes are part of the newly added tree (can you please check it out?), or if a similar and relatively simple change has to be made in a subsequent release. Also, by now only those two commands were changed, so the issue of adding such support to "jobs" (or other mass-management commands, for that matter) still stands indeed. And a counter of output hits too, and a regex filter, like in these two commands Maybe some refactoring is due to share such code... 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.164706.1440502741000.2615.1565782620392%40Atlassian.JIRA.
[JIRA] (JENKINS-34903) IRC plugin: custom post-build message
Title: Message Title Jim Klimov commented on JENKINS-34903 Re: IRC plugin: custom post-build message In this month's release of the two plugins, there are a couple of features that can help: adding an "extra message" that should work in the legacy and pipeline invocations, which is a string you can provide and will be attached to the standard build starting/completed notifications. Your job could generate it somehow (easier in a scripted pipeline). Not sure if it supports groovy variable expansion like many other plugins do, but I'd assume that is relatively easy to research and implement if needed. This might be flexible enough for passing the extra data. more for the pipeline context, calling `ircNotify customMessage:"Some text"` should just post that message verbatim (which again you can create in the pipeline) at that point in execution 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.170569.1463533039000.2608.1565781780164%40Atlassian.JIRA.
[JIRA] (JENKINS-34902) IRC notification to contain builds name
Title: Message Title Jim Klimov commented on JENKINS-34902 Re: IRC notification to contain builds name See also https://issues.jenkins-ci.org/browse/JENKINS-34903?focusedCommentId=373370=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-373370 about concerns on the greater configurability 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.170568.1463532209000.2603.1565781420383%40Atlassian.JIRA.
[JIRA] (JENKINS-34903) IRC plugin: custom post-build message
Title: Message Title Jim Klimov updated an issue Jenkins / JENKINS-34903 IRC plugin: custom post-build message Change By: Jim Klimov Component/s: instant-messaging-plugin 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.170569.1463533039000.2597.1565781360306%40Atlassian.JIRA.
[JIRA] (JENKINS-34902) IRC notification to contain builds name
Title: Message Title Jim Klimov updated an issue Jenkins / JENKINS-34902 IRC notification to contain builds name Change By: Jim Klimov Component/s: instant-messaging-plugin 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.170568.1463532209000.2600.1565781360404%40Atlassian.JIRA.
[JIRA] (JENKINS-34903) IRC plugin: custom post-build message
Title: Message Title Jim Klimov commented on JENKINS-34903 Re: IRC plugin: custom post-build message I don't think there is currently a way to disable that line, but it could be an option (literally, adding a configuration knob). PRs welcome According to `git grep` in the current instant-messaging-plugin master sources, there are two "Yippee" lines: `src/main/resources/hudson/plugins/im/build_notify/Messages.properties`: `SummaryOnlyBuildToChatNotifier.BuildIsFixed=Yippee, build fixed!\n` – this is a text resource leading to its usage in src/main/java/hudson/plugins/im/build_notify/SummaryOnlyBuildToChatNotifier.java a verbatim line in src/main/java/hudson/plugins/im/build_notify/BuildToChatNotifier.java apparently for a message to developer who contributed to fixing a job's state since the last (failed) run In any case, there are several sides to the original problem (custom format strings effectively) and to Yippee's : there can be a text resource change that is relatively easy to convey at run-time through configurable instant-messaging-plugin options (global or in the job, and maybe have to be exposed in protocol plugins like ircbot), and a logical change (passing needed Java values instead of the placeholders configured in the format string, enabling or disabling Yippee's optionally) that has to be coded, compiled and distributed. 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. To view this discussion on the web visit
[JIRA] (JENKINS-55757) When a build command is rejected, I want to make sure the IRC Nickname is matched to correct Jenkins user ID
Title: Message Title Jim Klimov updated JENKINS-55757 Fix merged, included in a new plugin release Jenkins / JENKINS-55757 When a build command is rejected, I want to make sure the IRC Nickname is matched to correct Jenkins user ID Change By: Jim Klimov Status: In Review Resolved Resolution: Fixed 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.197136.1548321625000.8286.1565060820098%40Atlassian.JIRA.
[JIRA] (JENKINS-55760) IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command
Title: Message Title Jim Klimov updated JENKINS-55760 Fix merged, included in a new plugin release Jenkins / JENKINS-55760 IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command Change By: Jim Klimov Status: In Review Resolved Resolution: Fixed 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.197139.1548338432000.8285.1565060760105%40Atlassian.JIRA.
[JIRA] (JENKINS-36826) Support Jenkins Pipeline for Jabber notifications
Title: Message Title Jim Klimov commented on JENKINS-36826 Re: Support Jenkins Pipeline for Jabber notifications I performed a release 1.37 of the instant-messaging-plugin so hopefully in a few hours its artifacts will be published and be dependable upon. Also, you could endeavour to make a plugin to notify/bot/... via Mattermost, right? 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.172870.1469028488000.8253.1565060700772%40Atlassian.JIRA.
[JIRA] (JENKINS-55755) When looking at current builds in IM (IRC) I want to optionally filter the results, see build numbers and URLs
Title: Message Title Jim Klimov updated JENKINS-55755 Fix merged, included in a new plugin release Jenkins / JENKINS-55755 When looking at current builds in IM (IRC) I want to optionally filter the results, see build numbers and URLs Change By: Jim Klimov Status: In Review Resolved Resolution: Fixed 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.197134.1548318473000.8250.1565060580190%40Atlassian.JIRA.
[JIRA] (JENKINS-55538) Instant messaging queue and currentlyBuilding commands should report a count of items
Title: Message Title Jim Klimov updated JENKINS-55538 Fix merged, included in a new plugin release Jenkins / JENKINS-55538 Instant messaging queue and currentlyBuilding commands should report a count of items Change By: Jim Klimov Status: In Review Resolved Resolution: Fixed 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.196671.1547202179000.8251.1565060580210%40Atlassian.JIRA.
[JIRA] (JENKINS-36826) Support Jenkins Pipeline for Jabber notifications
Title: Message Title Jim Klimov commented on JENKINS-36826 Re: Support Jenkins Pipeline for Jabber notifications Thanks. I was trying to make a release yesterday, but it stumbled on older dependencies first and on newly caught findbugs then, so stalled a bit ;( 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.172870.1469028488000.7285.1564855380805%40Atlassian.JIRA.
[JIRA] (JENKINS-36826) Support Jenkins Pipeline for Jabber notifications
Title: Message Title Jim Klimov commented on JENKINS-36826 Re: Support Jenkins Pipeline for Jabber notifications > That PR has conflicts that you need to resolve first. Unfortunately I am not the author nor committer there. I think in github the repo maintainer may by default edit the source branch of a PR, in the other developer's repository. Given that the conflict is just something in "versions.gradle", can you please see if it is something you may and can fix easily? 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.172870.1469028488000.6247.1564746661013%40Atlassian.JIRA.
[JIRA] (JENKINS-36826) Support Jenkins Pipeline for Jabber notifications
Title: Message Title Jim Klimov assigned an issue to Jim Klimov Jenkins / JENKINS-36826 Support Jenkins Pipeline for Jabber notifications Change By: Jim Klimov Assignee: kutzi Jim Klimov 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.172870.1469028488000.5798.1564689062135%40Atlassian.JIRA.
[JIRA] (JENKINS-36826) Support Jenkins Pipeline for Jabber notifications
Title: Message Title Jim Klimov commented on JENKINS-36826 Re: Support Jenkins Pipeline for Jabber notifications I can now merge the IM and IRC PRs, but did not ask for Jabber rights (so Florian Schmaus should follow up with the merge of https://github.com/jenkinsci/jabber-plugin/pull/18). I ported that logic for ircbot so there would be an ircNotify pipeline step as well, and can at least confirm that this coupling works 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.172870.1469028488000.5762.1564689061544%40Atlassian.JIRA.
[JIRA] (JENKINS-55755) When looking at current builds in IM (IRC) I want to optionally filter the results, see build numbers and URLs
Title: Message Title Jim Klimov updated an issue Jenkins / JENKINS-55755 When looking at current builds in IM (IRC) I want to optionally filter the results, see build numbers and URLs Change By: Jim Klimov Summary: When looking at current builds in IM (IRC) I want to optionally filter the results , see build numbers and URLs 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.197134.1548318473000.9194.1562975040062%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-58095) Add support for configurable "Restrict jobs execution at node" and "Environment variables" equivalent of generic nodes
Title: Message Title Jim Klimov updated an issue Jenkins / JENKINS-58095 Add support for configurable "Restrict jobs execution at node" and "Environment variables" equivalent of generic nodes Change By: Jim Klimov I am trying to make our internal build farm more dynamic than a set of predefined SSH agents, and swarm client is quite a successful replacement for us.We do however miss some of the generic agents' configurability that we need as different workers are used for different cases.One such item is ability to pass Environment variables (and/alternately to Prepare jobs environment, from EnvInject plugin) as part of the swarm client's configuration, perhaps from file handling similar to what is now done for labels. We need it to set up proxies, paths, etc. as applicable to this or that agent deployment. At least, for this half of of the problem we can export the fixed variables from the wrapper script (service method) which starts the swarm client for us, as a workaround. We can not change the definitions without restarting the client, however. The other problem is harder to work around: restriction of jobs executions, at least the option to filter by regex of the job name(s). We have use-cases where node labels are good, and some cases where they come short (e.g. we don't want or can't change a node label definition in an experimental project branch, but want that branch practically built on dedicated workers and not intermix with master development - filtering by full-jobname regex supported this use-case well). Add Comment
[JIRA] (JENKINS-58095) Add support for configurable "Restrict jobs execution at node" and "Environment variables" equivalent of generic nodes
Title: Message Title Jim Klimov created an issue Jenkins / JENKINS-58095 Add support for configurable "Restrict jobs execution at node" and "Environment variables" equivalent of generic nodes Issue Type: New Feature Assignee: Unassigned Components: swarm-plugin Created: 2019-06-19 14:17 Priority: Major Reporter: Jim Klimov I am trying to make our internal build farm more dynamic than a set of predefined SSH agents, and swarm client is quite a successful replacement for us. We do however miss some of the generic agents' configurability that we need as different workers are used for different cases. One such item is ability to pass Environment variables (and/alternately to Prepare jobs environment, from EnvInject plugin) as part of the swarm client's configuration, perhaps from file handling similar to what is now done for labels. We need it to set up proxies, paths, etc. as applicable to this or that agent deployment. At least, for this half of of the problem we can export the fixed variables from the wrapper script (service method) which starts the swarm client for us, as a workaround. The other problem is harder to work around: restriction of jobs executions, at least the option to filter by regex of the job name(s). We have use-cases where node labels are good, and some cases where they come short (e.g. we don't want or can't change a node label definition in an experimental project branch, but want that branch practically built on dedicated workers and not intermix with master development - filtering by full-jobname regex supported this use-case well).
[JIRA] (JENKINS-57649) Lockable resource plugin should not lock a resources when it is offline
Title: Message Title
Jim Klimov edited a comment on JENKINS-57649
Re: Lockable resource plugin should not lock a resources when it is offline
While there is a good purpose in this request, I believe it is destined to be an offtopic/WontFix here. The plugin manages the generic concept of resources, does not even care if they are physically represented or not (you can use it to e.g. throttle a maximum amount of jobs holding a limited amount of tokens at a time).That said, you *can* use the Groovy script option of implementing *your* use-case dependent logic and eveelintually eventually return a `true` or `false` about whether a proposed resource is eligible for your job. The plugin calls such script in a loop for each resource ( your script should test that it matches the label _expression_ you asked for? want then ) and makes a list of items with a "true" verdict, to offer one (or first?) of those to be locked by a job.I am not sure if it levels the load on physical resources (giving first vs random eligible).As part of this logic you can do anything; for some of our tests in the house, we have indeed a script that probes SSH availability of a remote VM we'd be setting up with our product as part of such logic, so broken VMs are not offered to jobs. A trimmed-down example would be:{code}public static boolean serverListening(String host, int port){Socket s = null;try{s = new Socket(host, port);return true;}catch (Exception e){return false;}finally{if(s != null)try {s.close();}catch(Exception e){}}}//println "Inspecting the resource to lock for requested CONTROLLER='" + CONTROLLER + "' (looking at resourceName='" + resourceName + "' resourceDescription='" + resourceDescription + "' resourceLabels='" + resourceLabels + "')"// + "' in build number " + build.getNumber() + if ( serverListening(resourceName, 22) ) {println "ACCEPTED '" + resourceName + "'"return true;}println "Resource '" + resourceName + "' is not suitable for this job"return false; // Tested resource is not appropriate for this build{code}With this, we do however miss another ability: to see quickly which resources were last diagnosed dead. Arguably, this is out of LockableResources' scope as well however (rather belongs in zabbix or similar monitoring tool, or maybe a custom job to inspect the list of resources and "lock" broken ones by a specific holder, and unlock fixed ones... maybe along the lines of this https://stackoverflow.com/a/52744986/4715872 fine example).But it would be helpful to have such a status anyway and have it all displayed in the same list of Available/Reserved/Locked/+Broken+ Jenkins resources :)
Add Comment
[JIRA] (JENKINS-57649) Lockable resource plugin should not lock a resources when it is offline
Title: Message Title
Jim Klimov commented on JENKINS-57649
Re: Lockable resource plugin should not lock a resources when it is offline
While there is a good purpose in this request, I believe it is destined to be an offtopic/WontFix here. The plugin manages the generic concept of resources, does not even care if they are physically represented or not (you can use it to e.g. throttle a maximum amount of jobs holding a limited amount of tokens at a time). That said, you can use the Groovy script option of implementing your use-case dependent logic and eveelintually return a `true` or `false` about whether a proposed resource is eligible for your job. The plugin calls such script in a loop for each resource (that matches the label _expression_ you asked for?) and makes a list of items with a "true" verdict, to offer one (or first?) of those to be locked by a job. I am not sure if it levels the load on physical resources (giving first vs random eligible). As part of this logic you can do anything; for some of our tests in the house, we have indeed a script that probes SSH availability of a remote VM we'd be setting up with our product as part of such logic, so broken VMs are not offered to jobs. A trimmed-down example would be:
public static boolean serverListening(String host, int port)
{
Socket s = null;
try
{
s = new Socket(host, port);
return true;
}
catch (Exception e)
{
return false;
}
finally
{
if(s != null)
try {s.close();}
catch(Exception e){}
}
}
//println "Inspecting the resource to lock for requested CONTROLLER='" + CONTROLLER + "' (looking at resourceName='" + resourceName + "' resourceDescription='" + resourceDescription + "' resourceLabels='" + resourceLabels + "')"
// + "' in build number " + build.getNumber() +
if ( serverListening(resourceName, 22) ) {
println "ACCEPTED '" + resourceName + "'"
return true;
}
println "Resource '" + resourceName + "' is not suitable for this job"
return false; // Tested resource is not appropriate for this build
With this, we do however miss another ability: to see quickly which resources were last diagnosed dead. Arguably, this is out of LockableResources' scope as well however (rather belongs in zabbix or similar monitoring tool, or maybe a custom job to inspect the list of resources and "lock" broken ones by a specific holder, and unlock fixed ones... maybe along the lines of this https://stackoverflow.com/a/52744986/4715872 fine example). But it would be helpful to have such a status anyway and have it all displayed in the same list of Available/Reserved/Locked/Broken Jenkins resources
[JIRA] (JENKINS-55993) Arrange GitHub email notifications support as an alternative transport for webhooks
Title: Message Title Jim Klimov commented on JENKINS-55993 Re: Arrange GitHub email notifications support as an alternative transport for webhooks FYI : as I recently learned, there finally are feasible workarounds for webhooks against firewalls, as detailed in https://jenkins.io/blog/2019/01/07/webhook-firewalls/ 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-46606) Stash-pullrequest-builder-plugin describes the job with verbatim HTML markup
Title: Message Title Jim Klimov closed an issue as Cannot Reproduce Jenkins / JENKINS-46606 Stash-pullrequest-builder-plugin describes the job with verbatim HTML markup Change By: Jim Klimov Status: Open Closed Resolution: Cannot Reproduce 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-46606) Stash-pullrequest-builder-plugin describes the job with verbatim HTML markup
Title: Message Title Jim Klimov commented on JENKINS-46606 Re: Stash-pullrequest-builder-plugin describes the job with verbatim HTML markup Indeed, lately (for many months) I do not remember seeing this issue in practice, so either it got fixed or some plugin impacting it got fixed or installed (like you suggest). I'll close this as I currently can't reproduce for e.g. a screenshot of the problem. Links from the list of builds, and links from top of each build's own page, are working links and not raw markup. 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-5401) Swarm client should support environment variables and tool locations from command line
Title: Message Title Jim Klimov commented on JENKINS-5401 Re: Swarm client should support environment variables and tool locations from command line FWIW, in the end I quickly worked around the issue above on the squid side, allowing port 39595 (as if "SSL_ports"). But it is still an unclean solution, with the swarm client going through the proxy at all (just because we want the building processes to use the proxy)... Same or worse may apply to e.g. customized PATH or some similar settings. 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-5401) Swarm client should support environment variables and tool locations from command line
Title: Message Title Jim Klimov commented on JENKINS-5401 Re: Swarm client should support environment variables and tool locations from command line Actually... no As an example, I wanted to set envvars for HTTP proxy to be used by the build processes, same as I had on static nodes. If I export https_proxy et al in the wrapper script that starts the swarm client, this client also tries to connect to Jenkins through the proxy, rather than directly: Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: Feb 22, 2019 12:09:39 AM hudson.remoting.jnlp.Main$CuiListener status Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: INFO: Connecting to jenkins2.localdomain:39595 (retrying:11) Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: java.io.IOException: Failed to connect to jenkins2.localdomain:39595 through proxy thunderbolt.localdomain/10.20.30.40:8081 Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: at org.jenkinsci.remoting.engine.JnlpAgentEndpoint.open(JnlpAgentEndpoint.java:242) Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: at hudson.remoting.Engine.connect(Engine.java:698) Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: at hudson.remoting.Engine.innerRun(Engine.java:552) Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: at hudson.remoting.Engine.run(Engine.java:474) Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: Caused by: java.io.IOException: Got a bad response from proxy: HTTP/1.1 403 Forbidden Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: at org.jenkinsci.remoting.engine.JnlpAgentEndpoint.open(JnlpAgentEndpoint.java:223) Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: ... 3 more Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: Feb 22, 2019 12:09:39 AM hudson.remoting.jnlp.Main$CuiListener error Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: SEVERE: Failed to connect to jenkins2.localdomain:39595 through proxy thunderbolt.localdomain/10.20.30.40:8081 Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: java.io.IOException: Failed to connect to jenkins2.localdomain:39595 through proxy thunderbolt.localdomain/10.20.30.40:8081 Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: at org.jenkinsci.remoting.engine.JnlpAgentEndpoint.open(JnlpAgentEndpoint.java:242) Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: at hudson.remoting.Engine.connect(Engine.java:698) Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: at hudson.remoting.Engine.innerRun(Engine.java:552) Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: at hudson.remoting.Engine.run(Engine.java:474) Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: Caused by: java.io.IOException: Got a bad response from proxy: HTTP/1.1 403 Forbidden Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: at org.jenkinsci.remoting.engine.JnlpAgentEndpoint.open(JnlpAgentEndpoint.java:223) Feb 22 00:09:39 ci-image jenkins-swarm-client.sh[32634]: ... 3 more
[JIRA] (JENKINS-55153) Depends on EasySSLProtocolSocketFactory from git-client 2.0
Title: Message Title Jim Klimov commented on JENKINS-55153 Re: Depends on EasySSLProtocolSocketFactory from git-client 2.0 FYI : Jakub's take at fixing this is at https://github.com/jenkinsci/stash-pullrequest-builder-plugin/pull/34 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-55949) Arrange RSS (or something like it) as a transport for GitHub webhooks
Title: Message Title Jim Klimov edited a comment on JENKINS-55949 Re: Arrange RSS (or something like it) as a transport for GitHub webhooks I've contacted GitHub support, whether they can extend existing webhook and email notifications with such a transport that "private" CI systems can connect to, and the person who got the message said it makes sense and the idea would be forwarded to developers.Bonus take-away from the research: there are "email notifications" which have now been standardized as an alternative to webhooks. So if a private Jenkins instance had a plugin to read those from a corporate mail server and react like for web hooks, it is yet another approach better than occasional full-sweep SCM Polling - this particular idea is tracked in JENKINS-55993 . 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-55993) Arrange GitHub email notifications support as an alternative transport for webhooks
Title: Message Title Jim Klimov updated an issue Jenkins / JENKINS-55993 Arrange GitHub email notifications support as an alternative transport for webhooks Change By: Jim Klimov While researching for JENKINS-55949, looking for ways to quickly react to repository changes while webhooks initiated from the Internet into a private Jenkins instance are not an option, I found that Github deprecated the older Services in favor of webhooks, but there is a new way of email notifications for individuals and organizations, which include much data about repository activity (the list does not explicitly mention creation of pull requests though, but there are messages for PR comments and addition of PR commits which may be the same thing effectively... even if not, at least fast reaction to new commits on branches are already a good thing):* https://developer.github.com/v3/guides/replacing-github-services/* https://help.github.com/articles/about-email-notifications/* https://help.github.com/articles/about-email-notifications-for-pushes-to-your-repository/* https://help.github.com/articles/choosing-the-delivery-method-for-your-notifications/People say the new technology works for them :)* https://github.com/BOINC/boinc/issues/2502#issuecomment-459967331So the idea with this RFE is that since there are Github e-mail notifications about repository events, they might be used with a script (or eventually plugin) that would connect to a specified mailbox (corporate, gmail, whatever) and maybe IMAP folder if the server can sort the mails, find notification mails there, and trigger webhook activity (generate a JSON payload from the email contents and POST it into the existing github webhook handler on Jenkins master with curl; or do the equivalent Java call directly if done as a plugin). Such script should also move the processed emails into Trash folder, so the mail server eventually purges them, while they are available for review and debug. For best responsiveness, IMAP IDLE or Push-IMAP might be used as the mail client transport, so the script would be notified of new e-mails as soon as they appear in the mailbox, minimizing the lag. Otherwise, regular polling of the mailbox would work as an a bit worse but possible solution. PS : Given that this currently seems like a new development that is not part of an existing plugin, there were some problems choosing what JIRA component to classify this into :\
[JIRA] (JENKINS-55993) Arrange GitHub email notifications support as an alternative transport for webhooks
Title: Message Title Jim Klimov created an issue Jenkins / JENKINS-55993 Arrange GitHub email notifications support as an alternative transport for webhooks Issue Type: New Feature Assignee: Kirill Merkushev Components: github-plugin Created: 2019-02-06 10:01 Priority: Minor Reporter: Jim Klimov While researching for JENKINS-55949, looking for ways to quickly react to repository changes while webhooks initiated from the Internet into a private Jenkins instance are not an option, I found that Github deprecated the older Services in favor of webhooks, but there is a new way of email notifications for individuals and organizations, which include much data about repository activity (the list does not explicitly mention creation of pull requests though, but there are messages for PR comments and addition of PR commits which may be the same thing effectively... even if not, at least fast reaction to new commits on branches are already a good thing): https://developer.github.com/v3/guides/replacing-github-services/ https://help.github.com/articles/about-email-notifications/ https://help.github.com/articles/about-email-notifications-for-pushes-to-your-repository/ https://help.github.com/articles/choosing-the-delivery-method-for-your-notifications/ People say the new technology works for them https://github.com/BOINC/boinc/issues/2502#issuecomment-459967331 So the idea with this RFE is that since there are Github e-mail notifications about repository
[JIRA] (JENKINS-41072) Poll the GitHub Events API as an alternative to webhook
Title: Message Title Jim Klimov updated an issue Jenkins / JENKINS-41072 Poll the GitHub Events API as an alternative to webhook Change By: Jim Klimov https://developer.github.com/v3/activity/events/https://developer.github.com/v3/activity/events/types/ vs.https://developer.github.com/webhooks/ 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-41072) Poll the GitHub Events API as an alternative to webhook
Title: Message Title Jim Klimov edited a comment on JENKINS-41072 Re: Poll the GitHub Events API as an alternative to webhook Linking to JENKINS-55949 as they seem to address a similar use-case. I am They are not yet convinced whether they can be considered duplicates, especially since the 55949 also touches on making a more generic solution than just one with github GitHub , and it asks for persistent connection with server-side notifications coming in ASAP, while the Events API has to be polled regularly (though cheaply with regard to quota usage, if used with used with the ETag header and "304 Not Modified" response support). 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-41072) Poll the GitHub Events API as an alternative to webhook
Title: Message Title Jim Klimov edited a comment on JENKINS-41072 Re: Poll the GitHub Events API as an alternative to webhook Linking to JENKINS-55949 as they seem to address a similar use-case. I am not yet convinced whether they can be considered duplicates, especially since the 55949 also touches on making a more generic solution than just one with github , and it asks for persistent connection with server-side notifications coming in ASAP, while the Events API has to be polled regularly (though cheaply with regard to quota usage, if used with used with the ETag header and "304 Not Modified" response support) . 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-55949) Arrange RSS (or something like it) as a transport for GitHub webhooks
Title: Message Title Jim Klimov commented on JENKINS-55949 Re: Arrange RSS (or something like it) as a transport for GitHub webhooks Seems the Github Events API can also be an answer here (although it works with polling rather than a persistent connection), linked to JENKINS-41072 as a related though not duplicate task. 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-41072) Poll the GitHub Events API as an alternative to webhook
Title: Message Title Jim Klimov commented on JENKINS-41072 Re: Poll the GitHub Events API as an alternative to webhook Linking to JENKINS-55949 as they seem to address a similar use-case. I am not yet convinced whether they can be considered duplicates, especially since the 55949 also touches on making a more generic solution than just one with github. 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-41072) Poll the GitHub Events API as an alternative to webhook
Title: Message Title Jim Klimov updated an issue Jenkins / JENKINS-41072 Poll the GitHub Events API as an alternative to webhook Change By: Jim Klimov https://developer.github.com/v3/activity/events/https://developer.github.com/v3/activity/events/types/ 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-55949) Arrange RSS (or something like it) as a transport for GitHub webhooks
Title: Message Title Jim Klimov commented on JENKINS-55949 Re: Arrange RSS (or something like it) as a transport for GitHub webhooks I've contacted GitHub support, whether they can extend existing webhook and email notifications with such a transport that "private" CI systems can connect to, and the person who got the message said it makes sense and the idea would be forwarded to developers. Bonus take-away from the research: there are "email notifications" which have now been standardized as an alternative to webhooks. So if a private Jenkins instance had a plugin to read those from a corporate mail server and react like for web hooks, it is yet another approach better than occasional full-sweep SCM Polling. 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-55512) Safe shutdown/restart should not block completion of complex jobs (that spawn child jobs)
Title: Message Title Jim Klimov commented on JENKINS-55512 Re: Safe shutdown/restart should not block completion of complex jobs (that spawn child jobs) Upon discussion with Daniel Beck the initial approach I took was not fully proper, at least not for upstreaming the change, as it would unilaterally change behavior for all child jobs, and this might not be applicable for some pipelines that can be (or not be) restartable, and certainly not intended for triggering of downstream jobs (rather than sub-jobs in focus of this issue) that have the same UpstreamCause – such jobs are independent and can wait in the blocked queue until the Jenkins master is safely restarted. This would also not be easily extensible to add behaviors (e.g. the idea about sysadmin forcing some job even though the server is shutting down). The better suggestion was to make use of Actions, which are an attachable piece of metadata, e.g. to inherit some new nonBlockingJobAction (name is arbitrary), consider its presence when making Queue.java decisions, and attach it to jobs scheduled in the plugins like the Freestyle, MultiPhase build and Pipeline (Workflow) build steps in case the current job would wait for completion of that new child job (async children can also wait until restart of the master, right?). For additional features, such as an administrative enforcement to run some job even if the server is quieting down, an extension point should be defined in the jenkins-core and then new plugins can be made to take advantage of that based on their purpose, logic and configurability. Effectively, the code in Queue.java would ask all currently loaded implementations of the extension point whether this Queue.Item (and/or Queue.Task) CAN be executed despite the pending shutdown, aka "is not blocked by the pending shutdown", with probably some tri-state outcome (permitted, blocked, no_opinion), with the current implementation being the fallback for a definitive result unless there is some certain verdict earlier. https://jenkins.io/doc/developer/extensibility/ https://wiki.jenkins-ci.org/display/JENKINS/AnnotationExtension https://wiki.jenkins-ci.org/display/JENKINS/Defining+a+new+extension+point PS: Hope I got and relayed it right Add Comment
[JIRA] (JENKINS-55512) Safe shutdown/restart should not block completion of complex jobs (that spawn child jobs)
Title: Message Title Jim Klimov updated JENKINS-55512 Jenkins / JENKINS-55512 Safe shutdown/restart should not block completion of complex jobs (that spawn child jobs) Change By: Jim Klimov Status: In Review Progress 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-55949) Arrange RSS (or something like it) as a transport for GitHub webhooks
Title: Message Title Jim Klimov created an issue Jenkins / JENKINS-55949 Arrange RSS (or something like it) as a transport for GitHub webhooks Issue Type: Bug Assignee: Unassigned Components: github-branch-source-plugin Created: 2019-02-04 12:37 Priority: Minor Reporter: Jim Klimov In our company, the Jenkins master is in a private network, and while the corporate security permits it to initiate connections to the internet to download updates, artifacts, etc. it may not receive any connections. We evaluated some tunneling services, so the Github hook URL would be set to that service endpoint and pop out inside the perimeter as a POST to our jenkins, but even that was not permitted. So the next reasonable option would be to have a Jenkins master keep a persistent connection to some web service on the internet, perhaps an RSS source, and receive lines equivalent to webhook payloads over that transport. So here the question is two-fold: extend the webhook support to not only receive POSTs, but be able to instead persistently connect somewhere and receive hooks there; provide a service that would produce the RSS feed like that. Two most reasonable places that come to mind would be either arranging with GitHub that they provide such a service, probably as part of the REST API so it can be tied to logins, organizations and repos in question, or having Cloudbees host a retranslator that would receive hooks from Github and feed them over this service, with Jenkins masters all over the world connecting to the retranslator with some unique IDs (that they set up in the webhook on Github side) also to consider, this might be a more generic problem than just for github, since there are many other supported SCM types and SCM service providers, so
[JIRA] (JENKINS-55423) Support optional custom Jenkins server URL value when registering a webhook
Title: Message Title Jim Klimov updated JENKINS-55423 Now waiting for a release with this to appear. Jenkins / JENKINS-55423 Support optional custom Jenkins server URL value when registering a webhook Change By: Jim Klimov Status: In Review Resolved Resolution: Fixed 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-55423) Support optional custom Jenkins server URL value when registering a webhook
Title: Message Title Jim Klimov commented on JENKINS-55423 Re: Support optional custom Jenkins server URL value when registering a webhook PR merged, great thanks Tom Wieczorek for the new webhook dialect support that my addition builds upon (JENKINS-47891), and to Joseph Petersen for reviewing my PR and making the initial code drop conform to the Java and Jenkins Plugin requirements. 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-55423) Support optional custom Jenkins server URL value when registering a webhook
Title: Message Title Jim Klimov updated JENKINS-55423 Jenkins / JENKINS-55423 Support optional custom Jenkins server URL value when registering a webhook Change By: Jim Klimov Status: In Progress Review 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-55423) Support optional custom Jenkins server URL value when registering a webhook
Title: Message Title Jim Klimov commented on JENKINS-55423 Re: Support optional custom Jenkins server URL value when registering a webhook https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/165 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-55423) Support optional custom Jenkins server URL value when registering a webhook
Title: Message Title Jim Klimov started work on JENKINS-55423 Change By: Jim Klimov Status: Open In Progress 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-55423) Support optional custom Jenkins server URL value when registering a webhook
Title: Message Title Jim Klimov assigned an issue to Jim Klimov Jenkins / JENKINS-55423 Support optional custom Jenkins server URL value when registering a webhook Change By: Jim Klimov Assignee: Jim Klimov 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-55760) IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command
Title: Message Title Jim Klimov commented on JENKINS-55760 Re: IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command Note to self: seems the AbortCommand.java could benefit from similar security considerations, but does not check any such permissions at all, or I'm missing something... 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-55760) IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command
Title: Message Title Jim Klimov edited a comment on JENKINS-55760 Re: IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command Note to self: seems the AbortCommand.java could benefit from similar security considerations, but does not check any such permissions at all (only declares the required permission) , or I'm missing something... 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-55760) IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command
Title: Message Title Jim Klimov commented on JENKINS-55760 Re: IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command https://github.com/jenkinsci/instant-messaging-plugin/pull/21 currently should address one part of this issue, allowing at least the "build" command for an account whose Jenkins name is same as IRC ID or nickname. Matching the nickname to an optionally configured mapping (as exists for IRCbot plugin) proved tricky to implement in an arbitrary solution, so help would be welcome. 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-55760) IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command
Title: Message Title Jim Klimov started work on JENKINS-55760 Change By: Jim Klimov Status: Open In Progress 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-55760) IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command
Title: Message Title Jim Klimov assigned an issue to Jim Klimov Jenkins / JENKINS-55760 IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command Change By: Jim Klimov Assignee: Drew DeVault Jim Klimov 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-55760) IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command
Title: Message Title Jim Klimov updated JENKINS-55760 Jenkins / JENKINS-55760 IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command Change By: Jim Klimov Status: In Progress Review 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-55760) IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command
Title: Message Title Jim Klimov updated an issue Jenkins / JENKINS-55760 IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command Change By: Jim Klimov Summary: IRC nick is configurable but does not map to Jenkins ID of sender in the "build" command 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-55760) IRC nick is configurable but does not map to Jenkins ID of sender
Title: Message Title Jim Klimov updated an issue Jenkins / JENKINS-55760 IRC nick is configurable but does not map to Jenkins ID of sender Change By: Jim Klimov Component/s: instant-messaging-plugin 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-55760) IRC nick is configurable but does not map to Jenkins ID of sender
Title: Message Title Jim Klimov commented on JENKINS-55760 Re: IRC nick is configurable but does not map to Jenkins ID of sender I've added a Jenkins user account literally named same as my IRC nick, and gave it all privileges listed in our "Matrix-based security" table, but still get "X: you're not allowed to build job Y!" 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-55760) IRC nick is configurable but does not map to Jenkins ID of sender
Title: Message Title
Jim Klimov created an issue
Jenkins / JENKINS-55760
IRC nick is configurable but does not map to Jenkins ID of sender
Issue Type:
Bug
Assignee:
Drew DeVault
Components:
ircbot-plugin
Created:
2019-01-24 14:00
Priority:
Major
Reporter:
Jim Klimov
I think this is related to JENKINS-15765 and JENKINS-35179 "IRC Bot does not take commands" : mine does not either, as of release ircbot-2.30 and instant-messaging-1.35 Digging in code, I see that both IRCPrivateChat.java and IRCChannel.java define `getNickName(String senderId)` and `getIMId(String senderId)` routines to implement the interface from https://github.com/jenkinsci/instant-messaging-plugin/blob/master/src/main/java/hudson/plugins/im/IMChat.java#L18 (which says that `senderId` is "the fully qualified IM id of the sender (e.g. for Jabber the user, the server domain and optional resource part)", and one "Translates the sender into a nickname which can be used to informally address the sender." while another "Translates the sender into a unique IM id.") and are used by https://github.com/jenkinsci/instant-messaging-plugin/blob/master/src/main/java/hudson/plugins/im/bot/Bot.java#L162 `getSender()`. All of these implementations for IRCbot just return the passed `senderId` value, and do not make use of the configurable "IRC Nick" to map the Jenkins account name (which may be privileged to run commands like `build`) to the Nickname of this user on the IRC server, which are two independent accounts. Actually, looking at the descriptions in the source, it is not evident to me that either `nick` or `id` in the `Sender` intend to mean the Jenkins user account name; but if in practice one does - it is not known to the messaging backend. The configurable value in Jenkins user account settings ("Your IRC Nick") is only referenced in ircbot/IrcPublisher.java routine `getConfiguredIMId()` (and managed in IrcUserProperty.java), and in
[JIRA] (JENKINS-55755) When looking at current builds in IM (IRC) I want to optionally filter the results
Title: Message Title Jim Klimov updated JENKINS-55755 Jenkins / JENKINS-55755 When looking at current builds in IM (IRC) I want to optionally filter the results Change By: Jim Klimov Status: In Progress Review 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-55755) When looking at current builds in IM (IRC) I want to optionally filter the results
Title: Message Title Jim Klimov assigned an issue to Jim Klimov Jenkins / JENKINS-55755 When looking at current builds in IM (IRC) I want to optionally filter the results Change By: Jim Klimov Assignee: kutzi Jim Klimov 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-55757) When a build command is rejected, I want to make sure the IRC Nickname is matched to correct Jenkins user ID
Title: Message Title Jim Klimov assigned an issue to Jim Klimov Jenkins / JENKINS-55757 When a build command is rejected, I want to make sure the IRC Nickname is matched to correct Jenkins user ID Change By: Jim Klimov Assignee: kutzi Jim Klimov 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-55755) When looking at current builds in IM (IRC) I want to optionally filter the results
Title: Message Title Jim Klimov commented on JENKINS-55755 Re: When looking at current builds in IM (IRC) I want to optionally filter the results https://github.com/jenkinsci/instant-messaging-plugin/pull/20 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-55755) When looking at current builds in IM (IRC) I want to optionally filter the results
Title: Message Title Jim Klimov started work on JENKINS-55755 Change By: Jim Klimov Status: Open In Progress 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-55757) When a build command is rejected, I want to make sure the IRC Nickname is matched to correct Jenkins user ID
Title: Message Title Jim Klimov updated JENKINS-55757 Jenkins / JENKINS-55757 When a build command is rejected, I want to make sure the IRC Nickname is matched to correct Jenkins user ID Change By: Jim Klimov Status: In Progress Review 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-55757) When a build command is rejected, I want to make sure the IRC Nickname is matched to correct Jenkins user ID
Title: Message Title Jim Klimov started work on JENKINS-55757 Change By: Jim Klimov Status: Open In Progress 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-55757) When a build command is rejected, I want to make sure the IRC Nickname is matched to correct Jenkins user ID
Title: Message Title Jim Klimov commented on JENKINS-55757 Re: When a build command is rejected, I want to make sure the IRC Nickname is matched to correct Jenkins user ID https://github.com/jenkinsci/instant-messaging-plugin/pull/19 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-55757) When a build command is rejected, I want to make sure the IRC Nickname is matched to correct Jenkins user ID
Title: Message Title Jim Klimov created an issue Jenkins / JENKINS-55757 When a build command is rejected, I want to make sure the IRC Nickname is matched to correct Jenkins user ID Issue Type: Improvement Assignee: kutzi Components: instant-messaging-plugin Created: 2019-01-24 09:20 Priority: Minor Reporter: Jim Klimov Simply post back both parts of the "sender" object when reporting the error. Context: Automatic reconnections to IRC tend to use a semirandom available name (e.g. my network roamed, I was "jim" but became "jim1" because this is a new connection and the server did not yet time-out the connection assigned to "jim"). Add Comment
[JIRA] (JENKINS-55755) When looking at current builds in IM (IRC) I want to optionally filter the results
Title: Message Title Jim Klimov created an issue Jenkins / JENKINS-55755 When looking at current builds in IM (IRC) I want to optionally filter the results Issue Type: Improvement Assignee: kutzi Components: instant-messaging-plugin Created: 2019-01-24 08:27 Priority: Minor Reporter: Jim Klimov Somewhat related to JENKINS-55538, when I look at what is currently building, I sometimes want to filter the output (e.g. only see what matches a pattern for nodes or job names). One particular use-case is that we sometimes restart some workers to deploy them from scratch, and before that we want to make sure they are not used by any build that would get aborted. One simple solution I thought of was adding an optional support to filter the prepared message line (to be posted into IM) with a user-provided regex. In line with solution to JENKINS-55538, such pattern hits can also be accounted and reported in the first line of response. Add Comment
[JIRA] (JENKINS-55538) Instant messaging queue and currentlyBuilding commands should report a count of items
Title: Message Title Jim Klimov updated JENKINS-55538 Jenkins / JENKINS-55538 Instant messaging queue and currentlyBuilding commands should report a count of items Change By: Jim Klimov Status: In Progress Review 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-55540) IRC client crashes sending long messages
Title: Message Title Jim Klimov created an issue Jenkins / JENKINS-55540 IRC client crashes sending long messages Issue Type: Improvement Assignee: kutzi Components: instant-messaging-plugin, ircbot-plugin Created: 2019-01-11 12:14 Environment: Jenkins 1.56, ircbot-plugin 2.30, instant-messaging-plugin 1.35, ngircd-22-2.1 IRC server on Linux Priority: Minor Reporter: Jim Klimov While testing the fix for JENKINS-55538 I had some queued tasks with very long descriptions (list of all nodes not having the requested label pattern). The ngircd server drops connections where messages exceed the limit of much less than the expected by protocol 510 chars (message apparently includes the "user text", possibly expanded with utf-8?, as well as target channel/account name and other metadata). As a result, Jenkins loses the IRC connection and takes several attempts to reconnect (possibly pushing the message again and failing again). I am not sure what can be done well about this, but one direction to look at could be a (user-configurable?) line length limit after which the message would be split (preferably on a word boundary near that limit). The ircbot-plugin already has a similar splitter to make messages with embedded newline characters into multiple single-line messages.
[JIRA] (JENKINS-55538) Instant messaging queue and currentlyBuilding commands should report a count of items
Title: Message Title Jim Klimov commented on JENKINS-55538 Re: Instant messaging queue and currentlyBuilding commands should report a count of items Proposed https://github.com/jenkinsci/instant-messaging-plugin/pull/18 to address this. 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-55538) Instant messaging queue and currentlyBuilding commands should report a count of items
Title: Message Title Jim Klimov started work on JENKINS-55538 Change By: Jim Klimov Status: Open In Progress 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.
