[JIRA] (JENKINS-58660) Errors running OWASP Dependency-Check plugin cause non-obvious failures of the build
Title: Message Title Oliver Lockwood created an issue Jenkins / JENKINS-58660 Errors running OWASP Dependency-Check plugin cause non-obvious failures of the build Issue Type: Bug Assignee: Unassigned Components: dependency-check-jenkins-plugin Created: 2019-07-25 14:33 Environment: Jenkins 2.181 Dependency-check plugin 5.2.0 Priority: Minor Reporter: Oliver Lockwood If any errors occur in the Dependency-Check plugin (i.e. the CLI tool exits with a non-zero return code) then the Jenkins build result is set to failure, as per this code https://github.com/jenkinsci/dependency-check-plugin/blob/master/src/main/java/org/jenkinsci/plugins/DependencyCheck/DependencyCheckToolBuilder.java#L157 final boolean success = (exitCode == 0); build.setResult(success ? Result.SUCCESS : Result.FAILURE); I have two concerns with this. When this happens, it is far from obvious that the reason for the build failure is the Dependency-Check plugin. The build may well continue and do many more stages, so parsing build output to determine the root cause is much more onerous than it needs to be. I believe it ought to be possible to configure (through plugin invocation parameters) the effect on the build of any errors running the plugin. For example, it may be more appropriate to make the build UNSTABLE, or even not
[JIRA] (JENKINS-51035) Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Title: Message Title
Oliver Lockwood updated an issue
Jenkins / JENKINS-51035
Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Change By:
Oliver Lockwood
This is a regression observed between Jenkins LTS 2.89.4 and LTS 2.107.2.The version of the Job DSL plugin (1.69) is unchanged.To reproduce:*1.* Run the following Job DSL to create a folder and some sample views within that folder.{noformat}folder('/dir') { displayName('dir') } buildMonitorView('/dir/Test BMV') { jobs { regex('.*') } } listView('/dir/Test LV') { jobs { regex(".*") } }{noformat}*2.* Run the following Job DSL script on its own.{noformat}folder('/dir') { displayName('dir')}{noformat} Before the upgrade to Jenkins 2.107.2, this worked fine. Following the upgrade, step 2 destroys the views that were created in step 1.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To
[JIRA] (JENKINS-51035) Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Title: Message Title
Oliver Lockwood updated an issue
Jenkins / JENKINS-51035
Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Change By:
Oliver Lockwood
This is a regression observed between Jenkins LTS 2.89.4 and LTS 2.107.2.The version of the Job DSL plugin (1.69) is unchanged.To reproduce: # *1.* Run the following Job DSL to create a folder and some sample views within that folder. {noformat}folder('/dir') { displayName('dir') } buildMonitorView('/dir/Test BMV') { jobs { regex('.*') } } listView('/dir/Test LV') { jobs { regex(".*") } }{noformat} # *2.* Run the following Job DSL script on its own. {noformat}folder('/dir') { displayName('dir')}{noformat} Before the upgrade to Jenkins 2.107.2, this worked fine. Following the upgrade, step 2 destroys the views that were created in step 1.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message because you are subscribed to the Google Groups "Jenkins
[JIRA] (JENKINS-51035) Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Title: Message Title
Oliver Lockwood updated an issue
Jenkins / JENKINS-51035
Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Change By:
Oliver Lockwood
This is a regression observed between Jenkins LTS 2.89.4 and LTS 2.107.2.The version of the Job DSL plugin (1.69) is unchanged.To reproduce: # Run the following Job DSL to create a folder and some sample views within that folder.{{ }}{noformat} folder('/dir') \ { }} {{ displayName('dir') }} {{ } }} {{ buildMonitorView('/dir/Test BMV') \ { }} {{ jobs \ { regex('.*') } }} {{ } }} {{ listView('/dir/Test LV') \ { }} {{ jobs \ { regex(".*") } } {noformat }{{}} } # Run the following Job DSL script on its own.{{ }}{noformat} folder('/dir') \ { }} {{ displayName('dir') } {noformat }{{}} } Before the upgrade to Jenkins 2.107.2, this worked fine. Following the upgrade, step 2 destroys the views that were created in step 1.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
[JIRA] (JENKINS-51035) Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Title: Message Title
Oliver Lockwood updated an issue
Jenkins / JENKINS-51035
Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Change By:
Oliver Lockwood
This is a regression observed between Jenkins LTS 2.89.4 and LTS 2.107.2.The version of the Job DSL plugin (1.69) is unchanged.To reproduce: # Run the following Job DSL to create a folder and some sample views within that folder. {{}} {noformat}folder('/dir') { displayName('dir') } buildMonitorView('/dir/Test BMV') { jobs { regex('.*') } } listView('/dir/Test LV') { jobs { regex(".*") } }{noformat} {{}} # Run the following Job DSL script on its own. {{}} {noformat}folder('/dir') { displayName('dir')}{noformat} {{}} Before the upgrade to Jenkins 2.107.2, this worked fine. Following the upgrade, step 2 destroys the views that were created in step 1.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message because you are subscribed to the Google Groups
[JIRA] (JENKINS-51035) Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Title: Message Title
Oliver Lockwood commented on JENKINS-51035
Re: Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Apologies, I meant to raise this as a bug originally. I have now fixed that field. Note that we have found it is possible to work around this issue by testing if the directory already exists or not, and only creating if it doesn't, e.g. import jenkins.model.Jenkins if (!Jenkins.instance.getItem('dir')) ... but this is clearly unsatisfactory in the longer term.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51035) Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Title: Message Title
Oliver Lockwood updated an issue
Jenkins / JENKINS-51035
Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Change By:
Oliver Lockwood
Issue Type:
Improvement Bug
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51035) Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Title: Message Title
Oliver Lockwood created an issue
Jenkins / JENKINS-51035
Regression: Job DSL `folder('existing-folder')` creation destroys any views in that folder
Issue Type:
Improvement
Assignee:
Daniel Spilker
Components:
job-dsl-plugin
Created:
2018-04-27 06:50
Priority:
Major
Reporter:
Oliver Lockwood
This is a regression observed between Jenkins LTS 2.89.4 and LTS 2.107.2. The version of the Job DSL plugin (1.69) is unchanged. To reproduce:
Run the following Job DSL to create a folder and some sample views within that folder. folder('/dir') { displayName('dir') } buildMonitorView('/dir/Test BMV') { {{ jobs { regex('.*') }}} } listView('/dir/Test LV') { {{ jobs { regex(".*") }}} }
Run the following Job DSL script on its own. folder('/dir') { displayName('dir') }
Before the upgrade to Jenkins 2.107.2, this worked fine. Following the upgrade, step 2 destroys the views that were created in step 1.
Add Comment
[JIRA] (JENKINS-44860) Disable masking of usernames
Title: Message Title
Oliver Lockwood edited a comment on JENKINS-44860
Re: Disable masking of usernames
We came across this issue last week as well and, having discovered this issue, are contemplating contributing a fix.Just to be clear, we'd like to: * use the username/password credentials type * use the following pipeline script to provide username and password as environment variables to the pipeline script closure and e.g. any shell commands within it: ** {noformat}withCredentials([usernamePassword(credentialsId: 'MY_CRED_ID', usernameVariable: 'USER_ENV_VAR', passwordVariable: 'PASSWORD_ENV_VAR')]) { ... }{noformat} * have any instances of whatever the password is be masked in console output * NOT have any instances of whatever the username is masked in console output.This would then correlate correctly with the view on the {{jenkinsUrl/credentials}} page, which shows {{user-name/** (description)}} in the {{Name}} column for credentials of this type.[~jglick] we already found the {{UsernamePasswordMultiBinding}} class; but it looks to us (perhaps naively?) that the return value of the `bind()` method is used in {{BindingStep.Execution.start()}} *both* for actually providing the environment variables (through the use of {{EnvironmentExpander}}) *and* for obfuscating the secrets into {{}} (through the use of {{Filter}}). So it's not clear to me how the patch you're suggesting would allow us to still provide the username from a Credential without it being obfuscated. Have I misunderstood your comment? Many thanks.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received
[JIRA] (JENKINS-44860) Disable masking of usernames
Title: Message Title
Oliver Lockwood edited a comment on JENKINS-44860
Re: Disable masking of usernames
We came across this issue last week as well and, having discovered this issue, are contemplating contributing a fix.Just to be clear, we'd like to: * use the username/password credentials type * use the following pipeline script to provide username and password as environment variables to the pipeline script closure and e.g. any shell commands within it: ** {noformat}withCredentials([usernamePassword(credentialsId: 'MY_CRED_ID', usernameVariable: 'USER_ENV_VAR', passwordVariable: 'PASSWORD_ENV_VAR')]) { ... }{noformat} * have any instances of whatever the password is be masked in console output * NOT have any instances of whatever the username is masked in console output.This would then correlate correctly with the view on the {{jenkinsUrl/credentials}} page, which shows {{user-name/** (description)}} in the {{Name}} column for credentials of this type.[~jglick] we already found the {{UsernamePasswordMultiBinding}} class; but it looks to us (perhaps naively?) that the return value of the `bind()` method is used in {{BindingStep.Execution.start()}} *both* for actually providing the environment variables (through the use of {{EnvironmentExpander}}) *and* for obfuscating the secrets into {{}} (through the use of {{Filter}}). So it's not clear to me how the patch you're suggesting would allow us to still provide the username from a Credential without it being obfuscated. Have I misunderstood your comment? Many thanks.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You
[JIRA] (JENKINS-44860) Disable masking of usernames
Title: Message Title
Oliver Lockwood edited a comment on JENKINS-44860
Re: Disable masking of usernames
We came across this issue last week as well and, having discovered this issue, are contemplating contributing a fix.Just to be clear, we'd like to: * use the username/password credentials type * use the following pipeline script to provide username and password as environment variables to the pipeline script closure and e.g. any shell commands within it: **{noformat}withCredentials([usernamePassword(credentialsId: 'MY_CRED_ID', usernameVariable: 'USER_ENV_VAR', passwordVariable: 'PASSWORD_ENV_VAR')]) { ... }{noformat} * have any instances of whatever the password is be masked in console output * NOT have any instances of whatever the username is masked in console output.This would then correlate correctly with the view on the {{jenkinsUrl/credentials}} page, which shows {{user-name/** (description)}} in the {{Name}} column for credentials of this type.[~jglick] we already found the {{UsernamePasswordMultiBinding}} class; but it looks to us (perhaps naively?) that the return value of the `bind()` method is used in {{BindingStep.Execution.start()}} *both* for actually providing the environment variables (through the use of {{EnvironmentExpander}}) *and* for obfuscating the secrets into {{}} (through the use of {{Filter}}). So it's not clear to me how the patch you're suggesting would allow us to still provide the username from a Credential without it being obfuscated. Have I misunderstood your comment? Many thanks.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message
[JIRA] (JENKINS-44860) Disable masking of usernames
Title: Message Title
Oliver Lockwood edited a comment on JENKINS-44860
Re: Disable masking of usernames
We came across this issue last week as well and, having discovered this issue, are contemplating contributing a fix.Just to be clear, we'd like to: * use the username/password credentials type * use the following pipeline script to provide username and password as environment variables to the pipeline script closure and e.g. any shell commands within it: ** { { noformat} withCredentials([usernamePassword(credentialsId: 'MY_CRED_ID', usernameVariable: 'USER_ENV_VAR', passwordVariable: 'PASSWORD_ENV_VAR')]) \ { ... } {noformat } } * have any instances of whatever the password is be masked in console output * NOT have any instances of whatever the username is masked in console output.This would then correlate correctly with the view on the {{jenkinsUrl/credentials}} page, which shows {{user-name/** (description)}} in the {{Name}} column for credentials of this type.[~jglick] we already found the {{UsernamePasswordMultiBinding}} class; but it looks to us (perhaps naively?) that the return value of the `bind()` method is used in {{BindingStep.Execution.start()}} *both* for actually providing the environment variables (through the use of {{EnvironmentExpander}}) *and* for obfuscating the secrets into {{}} (through the use of {{Filter}}). So it's not clear to me how the patch you're suggesting would allow us to still provide the username from a Credential without it being obfuscated. Have I misunderstood your comment? Many thanks.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this
[JIRA] (JENKINS-44860) Disable masking of usernames
Title: Message Title
Oliver Lockwood edited a comment on JENKINS-44860
Re: Disable masking of usernames
We came across this issue last week as well and, having discovered this issue, are contemplating contributing a fix.Just to be clear, we'd like to: * use the username/password credentials type * use the following pipeline script to provide username and password as environment variables to the pipeline script closure and e.g. any shell commands within it: {{withCredentials([usernamePassword(credentialsId: 'MY_CRED_ID', usernameVariable: 'USER_ENV_VAR', passwordVariable: 'PASSWORD_ENV_VAR')]) \{ ... }}} to provide username and password as environment variables to the pipeline script closure and e.g. any shell commands within it * have any instances of whatever the password is be masked in console output * NOT have any instances of whatever the username is masked in console output.This would then correlate correctly with the view on the {{jenkinsUrl/credentials}} page, which shows {{user-name/** (description)}} in the {{Name}} column for credentials of this type.[~jglick] we already found the {{UsernamePasswordMultiBinding}} class; but it looks to us (perhaps naively?) that the return value of the `bind()` method is used in {{BindingStep.Execution.start()}} *both* for actually providing the environment variables (through the use of {{EnvironmentExpander}}) *and* for obfuscating the secrets into {{}} (through the use of {{Filter}}). So it's not clear to me how the patch you're suggesting would allow us to still provide the username from a Credential without it being obfuscated. Have I misunderstood your comment? Many thanks.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
[JIRA] (JENKINS-44860) Disable masking of usernames
Title: Message Title
Oliver Lockwood commented on JENKINS-44860
Re: Disable masking of usernames
We came across this issue last week as well and, having discovered this issue, are contemplating contributing a fix. Just to be clear, we'd like to:
use the username/password credentials type
use the pipeline script {{withCredentials([usernamePassword(credentialsId: 'MY_CRED_ID', usernameVariable: 'USER_ENV_VAR', passwordVariable: 'PASSWORD_ENV_VAR')]) { ... }}} to provide username and password as environment variables to the pipeline script closure and e.g. any shell commands within it
have any instances of whatever the password is be masked in console output
NOT have any instances of whatever the username is masked in console output.
This would then correlate correctly with the view on the jenkinsUrl/credentials page, which shows user-name/** (description) in the Name column for credentials of this type. Jesse Glick we already found the UsernamePasswordMultiBinding class; but it looks to us (perhaps naively?) that the return value of the `bind()` method is used in BindingStep.Execution.start() both for actually providing the environment variables (through the use of EnvironmentExpander) and for obfuscating the secrets into (through the use of Filter). So it's not clear to me how the patch you're suggesting would allow us to still provide the username from a Credential without it being obfuscated. Have I misunderstood your comment? Many thanks.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
[JIRA] (JENKINS-50189) Regression: Pipeline 'sh' step broken by Kubernetes plugin 1.3.2
Title: Message Title Oliver Lockwood commented on JENKINS-50189 Re: Regression: Pipeline 'sh' step broken by Kubernetes plugin 1.3.2 Note that this appears to not be reproducible with the latest version of the plugin (1.5.1). I'll keep an eye on this for the next few weeks and report back. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50189) Regression: Pipeline 'sh' step broken by Kubernetes plugin 1.3.2
Title: Message Title Oliver Lockwood commented on JENKINS-50189 Re: Regression: Pipeline 'sh' step broken by Kubernetes plugin 1.3.2 Giuseppe Iannello no, my script was exactly as I had it above, without specifying `returnStdout`. I haven't tested with plugin versions 1.3.3 or 1.4, however, so the nature of the bug may have changed. Carlos Sanchez have you made any headway diagnosing this issue? Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50189) Regression: Pipeline 'sh' step broken by Kubernetes plugin 1.3.2
Title: Message Title Oliver Lockwood updated an issue Jenkins / JENKINS-50189 Regression: Pipeline 'sh' step broken by Kubernetes plugin 1.3.2 Change By: Oliver Lockwood Attachment: pod-templates.xml Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50189) Regression: Pipeline 'sh' step broken by Kubernetes plugin 1.3.2
Title: Message Title Oliver Lockwood commented on JENKINS-50189 Re: Regression: Pipeline 'sh' step broken by Kubernetes plugin 1.3.2 `pod-templates.xml` now attached, containing the relevant section from `config.xml` Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50189) Regression: Pipeline 'sh' step broken by Kubernetes plugin 1.3.2
Title: Message Title Oliver Lockwood commented on JENKINS-50189 Re: Regression: Pipeline 'sh' step broken by Kubernetes plugin 1.3.2 We have left the "Command to run" empty as the helptext says: Override the image entrypoint with a different one and we see no need to override. I can copy-paste the full XML definition (from each different version of the Kubernetes plugin) if that would help? Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50189) Regression: Pipeline 'sh' step broken by Kubernetes plugin 1.3.2
Title: Message Title Oliver Lockwood created an issue Jenkins / JENKINS-50189 Regression: Pipeline 'sh' step broken by Kubernetes plugin 1.3.2 Issue Type: Bug Assignee: Carlos Sanchez Components: kubernetes-plugin Created: 2018-03-15 10:23 Environment: Jenkins version: 2.89.4 Information below copied from `/systeminfo` page. System Properties Name ↓ Value awt.toolkit sun.awt.X11.XToolkit executable-war /usr/share/jenkins/jenkins.war file.encoding UTF-8 file.encoding.pkg sun.io file.separator / hudson.model.DirectoryBrowserSupport.CSP default-src 'self'; script-src 'unsafe-inline' 'self'; java.awt.graphicsenv sun.awt.X11GraphicsEnvironment java.awt.headless true java.awt.printerjob sun.print.PSPrinterJob java.class.path /usr/share/jenkins/jenkins.war java.class.version 52.0 java.endorsed.dirs /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/endorsed java.ext.dirs /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext:/usr/java/packages/lib/ext java.home /usr/lib/jvm/java-8-openjdk-amd64/jre java.io.tmpdir /tmp java.library.path /usr/java/packages/lib/amd64:/usr/lib/x86_64-linux-gnu/jni:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/usr/lib/jni:/lib:/usr/lib java.runtime.name OpenJDK Runtime Environment java.runtime.version 1.8.0_151-8u151-b12-1~deb9u1-b12 java.specification.name Java Platform API Specification java.specification.vendor Oracle Corporation java.specification.version 1.8 java.vendor Oracle Corporation java.vendor.url http://java.oracle.com/ java.vendor.url.bug http://bugreport.sun.com/bugreport/ java.version 1.8.0_151 java.vm.info mixed mode java.vm.name OpenJDK 64-Bit Server VM java.vm.specification.name Java Virtual Machine Specification java.vm.specification.vendor Oracle Corporation java.vm.specification.version 1.8 java.vm.vendor Oracle Corporation java.vm.version 25.151-b12 javax.accessibility.assistive_technologies org.GNOME.Accessibility.AtkWrapper jna.loaded true jna.platform.library.path /usr/lib/x86_64-linux-gnu:/lib/x86_64-linux-gnu:/lib64:/usr/lib:/lib:/usr/local/lib jnidispatch.path /tmp/jna--1712433994/jna1421996778036052333.tmp line.separator mail.smtp.sendpartial true mail.smtps.sendpartial true org.apache.xml.security.ignoreLineBreaks true os.arch amd64 os.name Linux os.version 4.4.0-116-generic path.separator : sun.arch.data.model 64 sun.boot.class.path
[JIRA] (JENKINS-44195) Add timestamps to the log
Title: Message Title Oliver Lockwood commented on JENKINS-44195 Re: Add timestamps to the log These two are related / duplicates, surely? Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
