[JIRA] (JENKINS-42502) blueocean dependencies do not seem to be optional - causing the whole UI to break
Title: Message Title Antoine Musso commented on JENKINS-42502 Re: blueocean dependencies do not seem to be optional - causing the whole UI to break I have a use case. Blue Ocean depends on a lot of plugins which would get security updates from time to time. Whenever one of those plugins is hit by a security update, we have to update our Jenkins installations even though we have no use for the plugins. Though I get the intent that if one installs the Jira plugin, the Blue Ocean integration should be installed as well. In our case we do not use Jira at all and would thus happily dispose of both Jira and the related integration plugins. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.179429.1488815363000.2227.1567009920201%40Atlassian.JIRA.
[JIRA] (JENKINS-17116) gracefull job termination
Title: Message Title Antoine Musso commented on JENKINS-17116 Re: gracefull job termination The merge https://github.com/jenkinsci/jenkins/commit/d8eac92ee9a1c19bf145763589f1c152607bf3ed is in tag jenkins-2.141 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-29762) Make inclusion of build and environment variables configurable
Title: Message Title Antoine Musso commented on JENKINS-29762 Re: Make inclusion of build and environment variables configurable Whenever the mask password plugin is not installed that causes: javax.servlet.ServletException: java.lang.NoClassDefFoundError: com/michelin/cio/hudson/plugins/maskpasswords/MaskPasswordsOutputStream I have filled it as JENKINS-39937 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-39937) logstash-plugin 1.2.0 causes NPE java.lang.NoClassDefFoundError: com/michelin/cio/hudson/plugins/maskpasswords/MaskPasswordsOutputStream
Title: Message Title Antoine Musso created an issue Jenkins / JENKINS-39937 logstash-plugin 1.2.0 causes NPE java.lang.NoClassDefFoundError: com/michelin/cio/hudson/plugins/maskpasswords/MaskPasswordsOutputStream Issue Type: Bug Assignee: Unassigned Components: logstash-plugin Created: 2016/Nov/22 11:39 AM Environment: logstash-plugin 1.2.0 Jenkins 1.651.x NO mask password plugin Priority: Minor Reporter: Antoine Musso When creating a dummy job that with the build wrapper "Send console log to Logstash", saving the job configuration fails with a stracktrace because MaskPassword is not available. I believed that is due to version 1.2.0 having: Respect Mask Password plugin configuration (JENKINS-29762) The publisher version is not affected. javax.servlet.ServletException: java.lang.NoClassDefFoundError: com/michelin/cio/hudson/plugins/maskpasswords/MaskPasswordsOutputStream at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:796) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:233) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) at
[JIRA] (JENKINS-33021) trilead ssh MAC and key exchange algorithms severely outdated
Title: Message Title Antoine Musso updated an issue Jenkins / JENKINS-33021 trilead ssh MAC and key exchange algorithms severely outdated Change By: Antoine Musso Component/s: credentials-plugin Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-33021) trilead ssh MAC and key exchange algorithms severely outdated
Title: Message Title Antoine Musso commented on JENKINS-33021 Re: trilead ssh MAC and key exchange algorithms severely outdated I have added a trace / some details from the duplicate task I have filled JENKINS-36873. As I understand it that Java installation is stall/no more updated by upstream and Jenkins core provides its own fork. Looks like the proper way to fix it would be to remove Trilead entirely and switch to another SSH implementation. Maybe Bouncy Castle? The workaround is to configure the slaves with some outdated algorithms supported by Trilead Our bug for my own reference https://phabricator.wikimedia.org/T103351 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-33021) trilead ssh MAC and key exchange algorithms severely outdated
Title: Message Title
Antoine Musso updated an issue
Jenkins / JENKINS-33021
trilead ssh MAC and key exchange algorithms severely outdated
Change By:
Antoine Musso
The supported macs and kex methods in trilead are severely outdated, resulting in connection issues with properly secured ssh daemons on target machines. For instance:{noformat}sshd[9800]: fatal: no matching mac found: client hmac-sha1-96,hmac-sha1,hmac-md5-96,hmac-md5 server hmac-sha2-256,hmac-sha2-512,umac...@openssh.com,hmac-ripemd160 [preauth]{noformat}In [JENKINS-14709|http://jenkins-ci.org/issue/14709] a suggestion is made to replace trilead with orion, but Orion is not being maintained either. Orion refers to Ganymed, but even that hasn't been looked at for almost 2 years: [Ganymed commits|https://code.google.com/archive/p/ganymed-ssh-2/source/default/commits]. It does seem to support hmac-sha2 macs though. From JENKINS-36873 (dupe)The ssh credentials plugin is unable to connect to slaves that have newer algorithmsThe keys from Jenkins (client) and slave (server below) have:{noformat}fatal: no matching mac found:client: hmac-sha1-96,hmac-sha1,hmac-md5-96,hmac-md5server: hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-...@openssh.com [preauth]{noformat}Jenkins yields a trace:{noformat}[06/22/15 14:49:05] [SSH] Opening SSH connection to 10.68.16.150:22.Key exchange was not finished, connection is closed.ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins.java.lang.IllegalStateException: Connection is not established! at com.trilead.ssh2.Connection.getRemainingAuthMethods(Connection.java:1030) at com.cloudbees.jenkins.plugins.sshcredentials.impl.TrileadSSHPublicKeyAuthenticator.getRemainingAuthMethods(TrileadSSHPublicKeyAuthenticator.java:88) at com.cloudbees.jenkins.plugins.sshcredentials.impl.TrileadSSHPublicKeyAuthenticator.canAuthenticate(TrileadSSHPublicKeyAuthenticator.java:80) at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.newInstance(SSHAuthenticator.java:207) at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.newInstance(SSHAuthenticator.java:169) at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:1173) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:701) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:696) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)[06/22/15 14:49:06] Launch failed - cleaning up connection[06/22/15 14:49:06] [SSH] Connection closed.{noformat}On our slaves we would like to have hmac-sha2-512 / hmac-sha2-256 but that is not supported by Trilead SSH.
[JIRA] (JENKINS-36873) ssh credentials does not support newer MAC/KEX algos due to outdated trilead-ssh2
Title: Message Title Antoine Musso closed an issue as Duplicate Sorry for the spam. It is an exact duplicate of JENKINS-33021 Jenkins / JENKINS-36873 ssh credentials does not support newer MAC/KEX algos due to outdated trilead-ssh2 Change By: Antoine Musso Status: Open Closed Resolution: Duplicate Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
[JIRA] (JENKINS-33021) trilead ssh MAC and key exchange algorithms severely outdated
Title: Message Title
Antoine Musso updated an issue
Jenkins / JENKINS-33021
trilead ssh MAC and key exchange algorithms severely outdated
Change By:
Antoine Musso
The supported macs and kex methods in trilead are severely outdated, resulting in connection issues with properly secured ssh daemons on target machines. For instance:{ { noformat} sshd[9800]: fatal: no matching mac found: client hmac-sha1-96,hmac-sha1,hmac-md5-96,hmac-md5 server hmac-sha2-256,hmac-sha2-512,umac...@openssh.com,hmac-ripemd160 [preauth] {noformat } } In [JENKINS-14709|http://jenkins-ci.org/issue/14709] a suggestion is made to replace trilead with orion, but Orion is not being maintained either. Orion refers to Ganymed, but even that hasn't been looked at for almost 2 years: [Ganymed commits|https://code.google.com/archive/p/ganymed-ssh-2/source/default/commits]. It does seem to support hmac-sha2 macs though.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are
[JIRA] (JENKINS-36873) ssh credentials does not support newer MAC/KEX algos due to outdated trilead-ssh2
Title: Message Title Antoine Musso updated an issue Jenkins / JENKINS-36873 ssh credentials does not support newer MAC/KEX algos due to outdated trilead-ssh2 Change By: Antoine Musso Summary: ssh credentials does not support newer MAC/KEX altos algos due to outdated trilead-ssh2 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36873) ssh credentials does not support newer MAC/KEX altos due to outdated trilead-ssh2
Title: Message Title Antoine Musso updated an issue Jenkins / JENKINS-36873 ssh credentials does not support newer MAC/KEX altos due to outdated trilead-ssh2 Change By: Antoine Musso Summary: ssh credentials does not support newer MAC/KEX also altos due to outdated trilead-ssh2 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36873) ssh credentials does not support newer MAC/KEX also due to outdated trilead-ssh2
Title: Message Title
Antoine Musso updated an issue
Jenkins / JENKINS-36873
ssh credentials does not support newer MAC/KEX also due to outdated trilead-ssh2
Change By:
Antoine Musso
The ssh credentials plugin is unable to connect to slaves that have newer algorithmsThe keys from Jenkins (client) and slave (server below) have:{ { noformat} } fatal: no matching mac found:client: hmac-sha1-96,hmac-sha1,hmac-md5-96,hmac-md5server: hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-...@openssh.com [preauth]{ { noformat} } Jenkins yields a trace:{ { noformat} } [06/22/15 14:49:05] [SSH] Opening SSH connection to 10.68.16.150:22.Key exchange was not finished, connection is closed.ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins.java.lang.IllegalStateException: Connection is not established! at com.trilead.ssh2.Connection.getRemainingAuthMethods(Connection.java:1030) at com.cloudbees.jenkins.plugins.sshcredentials.impl.TrileadSSHPublicKeyAuthenticator.getRemainingAuthMethods(TrileadSSHPublicKeyAuthenticator.java:88) at com.cloudbees.jenkins.plugins.sshcredentials.impl.TrileadSSHPublicKeyAuthenticator.canAuthenticate(TrileadSSHPublicKeyAuthenticator.java:80) at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.newInstance(SSHAuthenticator.java:207) at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.newInstance(SSHAuthenticator.java:169) at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:1173) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:701) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:696) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)[06/22/15 14:49:06] Launch failed - cleaning up connection[06/22/15 14:49:06] [SSH] Connection closed.{ { noformat} } On our slaves we would like to have hmac-sha2-512 / hmac-sha2-256 but that is not supported by Trilead SSH. As I understand it that Java installation is stall/no more updated by upstream and Jenkins core provides its own fork.Looks like the proper way to fix it would be to remove Trilead entirely and switch to another SSH implementation. Maybe Bouncy Castle.The workaround is to configure the slaves with some outdated algorithms supported by Trilead :(Our bug https://phabricator.wikimedia.org/T103351
[JIRA] (JENKINS-36873) ssh credentials does not support newer MAC/KEX also due to outdated trilead-ssh2
Title: Message Title
Antoine Musso updated an issue
Jenkins / JENKINS-36873
ssh credentials does not support newer MAC/KEX also due to outdated trilead-ssh2
Change By:
Antoine Musso
The ssh credentials plugin is unable to connect to slaves that have newer algorithmsThe keys from Jenkins (client) and slave (server below) have:{{ noformat}} fatal: no matching mac found:client: hmac-sha1-96,hmac-sha1,hmac-md5-96,hmac-md5server: hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-...@openssh.com [preauth] {{noformat }}Jenkins yields a trace:{{ noformat}} [06/22/15 14:49:05] [SSH] Opening SSH connection to 10.68.16.150:22.Key exchange was not finished, connection is closed.ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins.java.lang.IllegalStateException: Connection is not established! at com.trilead.ssh2.Connection.getRemainingAuthMethods(Connection.java:1030) at com.cloudbees.jenkins.plugins.sshcredentials.impl.TrileadSSHPublicKeyAuthenticator.getRemainingAuthMethods(TrileadSSHPublicKeyAuthenticator.java:88) at com.cloudbees.jenkins.plugins.sshcredentials.impl.TrileadSSHPublicKeyAuthenticator.canAuthenticate(TrileadSSHPublicKeyAuthenticator.java:80) at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.newInstance(SSHAuthenticator.java:207) at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.newInstance(SSHAuthenticator.java:169) at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:1173) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:701) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:696) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)[06/22/15 14:49:06] Launch failed - cleaning up connection[06/22/15 14:49:06] [SSH] Connection closed. {{noformat }}On our slaves we would like to have hmac-sha2-512 / hmac-sha2-256 but that is not supported by Trilead SSH. As I understand it that Java installation is stall/no more updated by upstream and Jenkins core provides its own fork.Looks like the proper way to fix it would be to remove Trilead entirely and switch to another SSH implementation. Maybe Bouncy Castle.The workaround is to configure the slaves with some outdated algorithms supported by Trilead :(Our bug https://phabricator.wikimedia.org/T103351
[JIRA] (JENKINS-36873) ssh credentials does not support newer MAC/KEX also due to outdated trilead-ssh2
Title: Message Title
Antoine Musso created an issue
Jenkins / JENKINS-36873
ssh credentials does not support newer MAC/KEX also due to outdated trilead-ssh2
Issue Type:
Bug
Assignee:
stephenconnolly
Components:
core, credentials-plugin
Created:
2016/Jul/22 10:56 AM
Environment:
Jenkins 1.651
Priority:
Major
Reporter:
Antoine Musso
The ssh credentials plugin is unable to connect to slaves that have newer algorithms The keys from Jenkins (client) and slave (server below) have: {{ fatal: no matching mac found: client: hmac-sha1-96,hmac-sha1,hmac-md5-96,hmac-md5 server: hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-...@openssh.com [preauth] }} Jenkins yields a trace: {{ [06/22/15 14:49:05] [SSH] Opening SSH connection to 10.68.16.150:22. Key exchange was not finished, connection is closed. ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins. java.lang.IllegalStateException: Connection is not established! at com.trilead.ssh2.Connection.getRemainingAuthMethods(Connection.java:1030) at com.cloudbees.jenkins.plugins.sshcredentials.impl.TrileadSSHPublicKeyAuthenticator.getRemainingAuthMethods(TrileadSSHPublicKeyAuthenticator.java:88) at com.cloudbees.jenkins.plugins.sshcredentials.impl.TrileadSSHPublicKeyAuthenticator.canAuthenticate(TrileadSSHPublicKeyAuthenticator.java:80) at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.newInstance(SSHAuthenticator.java:207) at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.newInstance(SSHAuthenticator.java:169) at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:1173) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:701) at
[JIRA] [gerrit-trigger-plugin] (JENKINS-31843) Gerrit build parameters lost in downstream job if rebuild when using build is parameterized
Title: Message Title Antoine Musso commented on JENKINS-31843 Re: Gerrit build parameters lost in downstream job if rebuild when using build is parameterized That might well fix all of: https://issues.jenkins-ci.org/browse/JENKINS-31730 https://issues.jenkins-ci.org/browse/JENKINS-29671 https://issues.jenkins-ci.org/browse/JENKINS-27340 Apparently caused by 1.22 and https://github.com/jenkinsci/rebuild-plugin/pull/19 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-31730) OFFLINE_NODE_WHEN_COMPLETE not recognized on manual rebuild leaving node online
Title: Message Title Antoine Musso commented on JENKINS-31730 Re: OFFLINE_NODE_WHEN_COMPLETE not recognized on manual rebuild leaving node online The Gearman plugin does not recognize the build parameters OFFLINE_NODE_WHEN_COMPLETE unless it is passed as a parameter to the gearman function (i.e. it does not work with rebuild). A workaround is to use the Single Use Slave Plugin https://wiki.jenkins-ci.org/display/JENKINS/Single+Use+Slave+Plugin , the plugin is given a list of labels to monitor, when a build is complete it will put the node offline regardless of OFFLINE_NODE_WHEN_COMPLETE Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ircbot-plugin] (JENKINS-28175) config change deadlock Jenkins when pircx.shutdown() is invoked
Title: Message Title Antoine Musso commented on JENKINS-28175 Re: config change deadlock Jenkins when pircx.shutdown() is invoked From the discussion on https://github.com/jenkinsci/ircbot-plugin/commit/d18cc7b617155100f8afadb73b324f378c5661da (which bumps Pircbotx to 2.0.1) the deadlock might be solved by Pircbotx 2.1. Would be nice to have a commit that bump the dependency. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-34885) Gearman plugin should whitelist build parameters it injects
Title: Message Title Antoine Musso commented on JENKINS-34885 Re: Gearman plugin should whitelist build parameters it injects Listed on the wiki page: https://wiki.jenkins-ci.org/display/JENKINS/Plugins+affected+by+fix+for+SECURITY-170 Also added as known issue on the plugin page at https://wiki.jenkins-ci.org/display/JENKINS/Gearman+Plugin Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-34885) Gearman plugin should whitelist build parameters it injects
Title: Message Title
Antoine Musso updated an issue
Jenkins / JENKINS-34885
Gearman plugin should whitelist build parameters it injects
Change By:
Antoine Musso
Jenkins 1.651.2 now strips build parameters that are not explicitly defined by a job https://jenkins.io/blog/2016/05/11/security-update/ . The Gearman plugin should thus white list them dynamically so they do not got stripped.I have at least confirmed the special {{OFFLINE_NODE_WHEN_COMPLETE}} parameter is not impacted and the Gearman plugin properly set the slave offline even when Jenkins strips it out later on. Extensive details are available at https://phabricator.wikimedia.org/T133737#2290669A use case is Zuul triggering jobs passing its context as ZUUL_* build parameters which can then be reused as environment variables. Without them, it is pretty much useless unless one comes through the trouble of white listing all ZUUL parameters + whatever user parameters that might be injected.I have poked the OpenStack infrastructure list about it http://lists.openstack.org/pipermail/openstack-infra/2016-May/004284.html to which James E. Blair recommended on http://lists.openstack.org/pipermail/openstack-infra/2016-May/004285.html to:> In the mean time, assuming that your system is entirely driven by Zuul+gearman and you do not have jobs that are triggered by other plugins where this behavior might not be desirable, I think the command line option you mentioned should be safe.The workaround is to pass to for Jenkins 1.651.2 and later + is to pass the Java system parameter {{ -Dhudson.model.ParametersAction.keepUndefinedParameters=true }} . Which is not secure.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [gearman-plugin] (JENKINS-34885) Gearman plugin should whitelist build parameters it injects
Title: Message Title
Antoine Musso updated an issue
Jenkins / JENKINS-34885
Gearman plugin should whitelist build parameters it injects
Change By:
Antoine Musso
Jenkins 1.651.2 now strips build parameters that are not explicitly defined by a job https://jenkins.io/blog/2016/05/11/security-update/ . The Gearman plugin should thus white list them dynamically so they do not got stripped.I have at least confirmed the special {{ OFFLINE_NODE_WHEN_COMPLETE }} parameter is not impacted and the Gearman plugin properly set the slave offline even when Jenkins strips it out later on. Extensive details are available at https://phabricator.wikimedia.org/T133737#2290669A use case is Zuul triggering jobs passing its context as ZUUL_* build parameters which can then be reused as environment variables. Without them, it is pretty much useless unless one comes through the trouble of white listing all ZUUL parameters + whatever user parameters that might be injected.I have poked the OpenStack infrastructure list about it http://lists.openstack.org/pipermail/openstack-infra/2016-May/004284.html to which James E. Blair recommended on http://lists.openstack.org/pipermail/openstack-infra/2016-May/004285.html to:> In the mean time, assuming that your system is entirely driven by Zuul+gearman and you do not have jobs that are triggered by other plugins where this behavior might not be desirable, I think the command line option you mentioned should be safe.The workaround is to pass to Jenkins 1.651.2 and later the Java system parameter -Dhudson.model.ParametersAction.keepUndefinedParameters=true . Which is not secure.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [gearman-plugin] (JENKINS-34885) Gearman plugin should whitelist build parameters it injects
Title: Message Title Antoine Musso created an issue Jenkins / JENKINS-34885 Gearman plugin should whitelist build parameters it injects Issue Type: Bug Assignee: Unassigned Components: gearman-plugin Created: 2016/May/17 2:19 PM Environment: Jenkins 1.651.2 Labels: security-170 Priority: Major Reporter: Antoine Musso Jenkins 1.651.2 now strips build parameters that are not explicitly defined by a job https://jenkins.io/blog/2016/05/11/security-update/ . The Gearman plugin should thus white list them dynamically so they do not got stripped. I have at least confirmed the special OFFLINE_NODE_WHEN_COMPLETE parameter is not impacted and the Gearman plugin properly set the slave offline even when Jenkins strips it out later on. Extensive details are available at https://phabricator.wikimedia.org/T133737#2290669 A use case is Zuul triggering jobs passing its context as ZUUL_* build parameters which can then be reused as
[JIRA] [timestamper-plugin] (JENKINS-28226) Add a "display in UTC" option
Title: Message Title Antoine Musso commented on JENKINS-28226 Re: Add a "display in UTC" option As a potential workaround, the system itself could be set to UTC, then people can use the browser timezone to adjust. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [matrix-project-plugin] (JENKINS-31765) jenkins-job-builder matrix job combination-filter causes 500 response
Title: Message Title
Antoine Musso commented on JENKINS-31765
Re: jenkins-job-builder matrix job combination-filter causes 500 response
The empty combination filter causes JJB to emit None (bad.xml below):
{{ $ colordiff -u good.xml bad.xml — good.xml 2016-03-03 10:21:24.0 +0100 +++ bad.xml 2016-03-03 10:21:42.0 +0100 @@ -7,7 +7,7 @@ false
+ None}}
Seems like a bug in JJB
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-32963) FATAL: no longer a configured node for XXXX
Title: Message Title Antoine Musso resolved as Not A Defect Make sure OFFLINE_NODE_WHEN_COMPLETE or Nodepool will get rid of the node while it might be building a second build. Jenkins / JENKINS-32963 FATAL: no longer a configured node for Change By: Antoine Musso Status: Open Resolved Resolution: Not A Defect Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-32963) FATAL: no longer a configured node for XXXX
Title: Message Title Antoine Musso commented on JENKINS-32963 Re: FATAL: no longer a configured node for Most probably one job is not properly setting OFFLINE_NODE_WHEN_COMPLETE and when another job starts it ends up dieing because of Nodepool garbage collecting the Node. Looking at the Zuul debug logs: 2016-02-15 17:37:21,293 DEBUG zuul.Gearman: Custom parameter function used for job integration-config-tox-py27-jessie That does not set OFFLINE_NODE_WHEN_COMPLETE. So a build got scheduled on it and had a trouble when Nodepool deleted the Node. I have filled this task merely for reference for other people. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-32963) FATAL: no longer a configured node for XXXX
Title: Message Title Antoine Musso created an issue Jenkins / JENKINS-32963 FATAL: no longer a configured node for Issue Type: Bug Assignee: Unassigned Attachments: npmjob.xml Components: gearman-plugin Created: 15/Feb/16 9:54 PM Environment: Jenkins 1.625.3 Gearman plugin 0.1.3 + https://review.openstack.org/#/c/271543/ "Update to Jenkins LTS 1.625.3 and fix function registration" Priority: Major Reporter: Antoine Musso I have: Zuul Gearman plugin 0.1.3 (with https://review.openstack.org/#/c/271543/ ) Jenkins 1.625.3
[JIRA] [mansion-cloud-plugin] (JENKINS-26665) Complete lack of correct synchronization or concern for thread safety in mansion cloud plugin
Title: Message Title Antoine Musso commented on JENKINS-26665 Re: Complete lack of correct synchronization or concern for thread safety in mansion cloud plugin I looked at the git log for the durable task plugin. Seems Stephen refer to: JENKINS-26380 Pull request: https://github.com/jenkinsci/durable-task-plugin/pull/2 Commit: https://github.com/jenkinsci/durable-task-plugin/commit/cce88cad22f78997d6a7b839fb3f2f75b4ce94c9 And there is a follow up: Pull request: https://github.com/jenkinsci/durable-task-plugin/pull/3 Commit: https://github.com/jenkinsci/durable-task-plugin/commit/12c593402410034fe6e9f066d5fb4c1503891d54 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-26380) Deadlock between Queue and Jenkins model
Title: Message Title Antoine Musso commented on JENKINS-26380 Re: Deadlock between Queue and Jenkins model Jessie Glick fix is: Pull request: https://github.com/jenkinsci/durable-task-plugin/pull/3 Commit: https://github.com/jenkinsci/durable-task-plugin/commit/12c593402410034fe6e9f066d5fb4c1503891d54 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-28936) Gearman plugin should not decide on which node a build should be executed
Title: Message Title Antoine Musso commented on JENKINS-28936 Re: Gearman plugin should not decide on which node a build should be executed I am facing with issue as well with the Throttle Concurrent Builds Plugin. My use case can be summarized down to: permanent slaves having 2 executors. Slave 1 and Slave 2 A long job consuming lot of disk space. The job is allowed to run concurrently, but since it almost starve a slave, I am using the Throttle Concurrent Builds Plugin to only allow one instance of the job per node. I have no idea how the Zuul Gearman server schedule the jobs, it seems to be using round robin over all available workers with Gearman Plugin reassigning the worker to a Jenkins executor slot on the fly. Anyway I often end up with: Slave 1 running the job Slave 2 idling The Jenkins queue showing the job waiting for next available executor on Slave 1. Looking at https://github.com/jenkinsci/throttle-concurrent-builds-plugin it implements the same extension point / method: QueueTaskDispatcher.canTake() which state: Vetos are additive. When multiple QueueTaskDispatchers are in the system, the task won't run on the given node if any one of them returns a non-null value. (This relationship is also the same with built-in check logic.) So it is blocked properly. But as noted by Christian, there is only one node to choose from anyway. Seems GearmanProxy.canTake() iterates all the node workers threads and simply rely on NodeAvailabilityMonitor.canTake() which seems to have its own locking not respecting QueueTaskDispatcher.canTake() which is altered by other plugins. Could GearmanProxy.canTake() ask the QueueTaskDispatcher instead? Add Comment
[JIRA] [gearman-plugin] (JENKINS-25867) Gearman won't schedule new jobs even though there are slots available on master
Title: Message Title Antoine Musso commented on JENKINS-25867 Re: Gearman won't schedule new jobs even though there are slots available on master The deadlock still happens from time to time with Jenkins 1.625.3 LTS and Gearman plugin 1.3.3 with https://review.openstack.org/#/c/252768/ Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-25867) Gearman won't schedule new jobs even though there are slots available on master
Title: Message Title Antoine Musso updated an issue Jenkins / JENKINS-25867 Gearman won't schedule new jobs even though there are slots available on master Change By: Antoine Musso Environment: Jenkins 1.580.1 LTS and Gearman plugin 0.1.1 Jenkins 1.625.3 LTS and Gearman plugin 1.3.3 with https://review.openstack.org/#/c/252768/ Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-25867) Gearman won't schedule new jobs even though there are slots available on master
Title: Message Title
Antoine Musso edited a comment on JENKINS-25867
Re: Gearman won't schedule new jobs even though there are slots available on master
It happened again with the the gearman-plugin v0.1.2 :-(({ { noformat} Jul 28, 2015 10:30:35 AM FINE hudson.plugins.gearman.NodeAvailabilityMonitor canTakeAvailabilityMonitor canTake request for nullJul 28, 2015 10:30:35 AM FINE hudson.plugins.gearman.NodeAvailabilityMonitor canTakeAvailabilityMonitor canTake request for nullJul 28, 2015 10:30:35 AM FINE hudson.plugins.gearman.NodeAvailabilityMonitor canTakeAvailabilityMonitor canTake request for null {noformat } } With jobs tied to that instance being stuck waiting for an available executor on deployment-bastion.Marking the node offline and online doesn't remove the lock :-/The executor threads have:{ { noformat} "Gearman worker deployment-bastion.eqiad_exec-1" prio=5 WAITING java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:503) hudson.remoting.AsyncFutureImpl.get(AsyncFutureImpl.java:73) hudson.plugins.gearman.StartJobWorker.safeExecuteFunction(StartJobWorker.java:196) hudson.plugins.gearman.StartJobWorker.executeFunction(StartJobWorker.java:114) org.gearman.worker.AbstractGearmanFunction.call(AbstractGearmanFunction.java:125) org.gearman.worker.AbstractGearmanFunction.call(AbstractGearmanFunction.java:22) hudson.plugins.gearman.MyGearmanWorkerImpl.submitFunction(MyGearmanWorkerImpl.java:593) hudson.plugins.gearman.MyGearmanWorkerImpl.work(MyGearmanWorkerImpl.java:328) hudson.plugins.gearman.AbstractWorkerThread.run(AbstractWorkerThread.java:166) java.lang.Thread.run(Thread.java:745)"Gearman worker deployment-bastion.eqiad_exec-2" prio=5 TIMED_WAITING java.lang.Object.wait(Native Method) hudson.plugins.gearman.NodeAvailabilityMonitor.lock(NodeAvailabilityMonitor.java:83) hudson.plugins.gearman.MyGearmanWorkerImpl.sendGrabJob(MyGearmanWorkerImpl.java:380) hudson.plugins.gearman.MyGearmanWorkerImpl.processSessionEvent(MyGearmanWorkerImpl.java:421) hudson.plugins.gearman.MyGearmanWorkerImpl.work(MyGearmanWorkerImpl.java:320) hudson.plugins.gearman.AbstractWorkerThread.run(AbstractWorkerThread.java:166) java.lang.Thread.run(Thread.java:745)"Gearman worker deployment-bastion.eqiad_exec-3" prio=5 TIMED_WAITING java.lang.Object.wait(Native Method) hudson.plugins.gearman.NodeAvailabilityMonitor.lock(NodeAvailabilityMonitor.java:83) hudson.plugins.gearman.MyGearmanWorkerImpl.sendGrabJob(MyGearmanWorkerImpl.java:380) hudson.plugins.gearman.MyGearmanWorkerImpl.processSessionEvent(MyGearmanWorkerImpl.java:421) hudson.plugins.gearman.MyGearmanWorkerImpl.work(MyGearmanWorkerImpl.java:320) hudson.plugins.gearman.AbstractWorkerThread.run(AbstractWorkerThread.java:166) java.lang.Thread.run(Thread.java:745)"Gearman worker deployment-bastion.eqiad_exec-4" prio=5 TIMED_WAITING java.lang.Object.wait(Native Method) hudson.plugins.gearman.NodeAvailabilityMonitor.lock(NodeAvailabilityMonitor.java:83) hudson.plugins.gearman.MyGearmanWorkerImpl.sendGrabJob(MyGearmanWorkerImpl.java:380) hudson.plugins.gearman.MyGearmanWorkerImpl.processSessionEvent(MyGearmanWorkerImpl.java:421) hudson.plugins.gearman.MyGearmanWorkerImpl.work(MyGearmanWorkerImpl.java:320) hudson.plugins.gearman.AbstractWorkerThread.run(AbstractWorkerThread.java:166) java.lang.Thread.run(Thread.java:745)"Gearman worker deployment-bastion.eqiad_exec-5" prio=5 TIMED_WAITING java.lang.Object.wait(Native Method) hudson.plugins.gearman.NodeAvailabilityMonitor.lock(NodeAvailabilityMonitor.java:83) hudson.plugins.gearman.MyGearmanWorkerImpl.sendGrabJob(MyGearmanWorkerImpl.java:380) hudson.plugins.gearman.MyGearmanWorkerImpl.processSessionEvent(MyGearmanWorkerImpl.java:421) hudson.plugins.gearman.MyGearmanWorkerImpl.work(MyGearmanWorkerImpl.java:320) hudson.plugins.gearman.AbstractWorkerThread.run(AbstractWorkerThread.java:166) java.lang.Thread.run(Thread.java:745) {noformat } }
[JIRA] [gearman-plugin] (JENKINS-31730) OFFLINE_NODE_WHEN_COMPLETE not recognized on manual rebuild leaving node online
Title: Message Title Antoine Musso created an issue Jenkins / JENKINS-31730 OFFLINE_NODE_WHEN_COMPLETE not recognized on manual rebuild leaving node online Issue Type: Bug Assignee: ragesh_nair Components: gearman-plugin, rebuild-plugin Created: 24/Nov/15 8:35 PM Environment: Jenkins 1.625.2 gearman-plugin 1.3 rebuild-plugin 1.25 Priority: Minor Reporter: Antoine Musso When a job is triggered with additional parameters injected by the german-plugin, the rebuild-plugin does not populate them on rebuild. The Wikimedia setup has Zuul/Nodepool/Gearman-plugin. A parameter OFFLINE_NODE_WHEN_COMPLETE is set when the build is triggered via the gearman-plugin. It does not exist in the list of the jobs parameter but the build does show it up being set properly. When hitting [rebuild], previous parameters that are defined in the job configuration are populated from the previous build but the parameter OFFLINE_NODE_WHEN_COMPLETE that got injected is not.
[JIRA] [gearman-plugin] (JENKINS-31730) OFFLINE_NODE_WHEN_COMPLETE not recognized on manual rebuild leaving node online
Title: Message Title Antoine Musso commented on JENKINS-31730 Re: OFFLINE_NODE_WHEN_COMPLETE not recognized on manual rebuild leaving node online Might be the same as: JENKINS-29671 JENKINS-27340 Seems to be a regression from 1.22 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-31730) OFFLINE_NODE_WHEN_COMPLETE not recognized on manual rebuild leaving node online
Title: Message Title Antoine Musso edited a comment on JENKINS-31730 Re: OFFLINE_NODE_WHEN_COMPLETE not recognized on manual rebuild leaving node online Might be the same as:* JENKINS-29671* JENKINS-27340Seems to be a regression from 1.22 . Possibly introduced by the fix for JENKINS-20288 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [rebuild-plugin] (JENKINS-20288) The rebuild plugin doesn't support custom parameter types
Title: Message Title Antoine Musso commented on JENKINS-20288 Re: The rebuild plugin doesn't support custom parameter types Seems the patch causes rebuild plugin from 1.22 to no more inject parameters that might have been injected in addition to the parameters defined in the job. There is at least three issues mentioning that: JENKINS-29671 JENKINS-27340 JENKINS-31730 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-31496) Security Problem: commons-collections 3.2.1 (should bump to 3.2.2)
Title: Message Title Antoine Musso updated an issue Jenkins / JENKINS-31496 Security Problem: commons-collections 3.2.1 (should bump to 3.2.2) Change By: Antoine Musso Summary: Securitye Security Problem: commons-collections 3.2.1 (should bump to 3.2.2) Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-31598) Bump commons-collections lib from 3.2.1 to 3.2.2
Title: Message Title Antoine Musso created an issue Jenkins / JENKINS-31598 Bump commons-collections lib from 3.2.1 to 3.2.2 Issue Type: Bug Assignee: Unassigned Components: core Created: 17/Nov/15 1:05 PM Priority: Minor Reporter: Antoine Musso JENKINS-31496 mentioned a security issue related to the library commons-collections: Security problem http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ Fixed http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?view=log Which has lead to [SECURITY-218] and Jenkins is no more vulnerable since 1.638 and 1.625.2. It would be nice to bump the embedded library nonetheless. The 3.2.1 version being reported as facing a security risks by audit tools.
[JIRA] [core] (JENKINS-31496) Security Problem: commons-collections 3.2.1 (should bump to 3.2.2)
Title: Message Title Antoine Musso commented on JENKINS-31496 Re: Security Problem: commons-collections 3.2.1 (should bump to 3.2.2) Sorry for the lame edit earlier I haven't noticed this issue was marked as resolved. I have filled https://issues.jenkins-ci.org/browse/JENKINS-31598 to ask for commons-collections to be bumped from 3.2.1 to 3.2.2. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [collapsing-console-sections-plugin] (JENKINS-30690) Lack of section definitions causes NPE and an empty console
Title: Message Title
Antoine Musso created an issue
Jenkins / JENKINS-30690
Lack of section definitions causes NPE and an empty console
Issue Type:
Bug
Assignee:
Dean Yu
Components:
collapsing-console-sections-plugin
Created:
29/Sep/15 9:27 AM
Environment:
Jenkins 1.609.3 collapsing plugin 1.41
Priority:
Minor
Reporter:
Antoine Musso
As soon as the plugin is installed, all consoles end up being empty with the following server side NPE: {{ Sep 29, 2015 9:19:55 AM hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: it.writeLogTo(offset,output) in /ci/job/tox-py27/3444/console. Reason: java.lang.NullPointerException java.lang.NullPointerException at org.jvnet.hudson.plugins.collapsingconsolesections.CollapsingSectionsConfiguration.getSectionDefinitions(CollapsingSectionsConfiguration.java:56) at org.jvnet.hudson.plugins.collapsingconsolesections.CollapsingSectionNote$DescriptorImpl.getSectionDefinitions(CollapsingSectionNote.java:103) at org.jvnet.hudson.plugins.collapsingconsolesections.CollapsingSectionAnnotatorFactory.newInstance(CollapsingSectionAnnotatorFactory.java:40) at hudson.console.ConsoleAnnotator._for(ConsoleAnnotator.java:143) at hudson.console.ConsoleAnnotator.initial(ConsoleAnnotator.java:133) at hudson.console.AnnotatedLargeText.createAnnotator(AnnotatedLargeText.java:137) at
[JIRA] [gearman-plugin] (JENKINS-25867) Gearman won't schedule new jobs even though there are slots available on master
Title: Message Title
Antoine Musso reopened an issue
It happened again with the the gearman-plugin v0.1.2 (
{{Jul 28, 2015 10:30:35 AM FINE hudson.plugins.gearman.NodeAvailabilityMonitor canTake AvailabilityMonitor canTake request for null Jul 28, 2015 10:30:35 AM FINE hudson.plugins.gearman.NodeAvailabilityMonitor canTake AvailabilityMonitor canTake request for null Jul 28, 2015 10:30:35 AM FINE hudson.plugins.gearman.NodeAvailabilityMonitor canTake AvailabilityMonitor canTake request for null }}
With jobs tied to that instance being stuck waiting for an available executor on deployment-bastion.
Marking the node offline and online doesn't remove the lock :-/
The executor threads have: {{ Gearman worker deployment-bastion.eqiad_exec-1 prio=5 WAITING java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:503) hudson.remoting.AsyncFutureImpl.get(AsyncFutureImpl.java:73) hudson.plugins.gearman.StartJobWorker.safeExecuteFunction(StartJobWorker.java:196) hudson.plugins.gearman.StartJobWorker.executeFunction(StartJobWorker.java:114) org.gearman.worker.AbstractGearmanFunction.call(AbstractGearmanFunction.java:125) org.gearman.worker.AbstractGearmanFunction.call(AbstractGearmanFunction.java:22) hudson.plugins.gearman.MyGearmanWorkerImpl.submitFunction(MyGearmanWorkerImpl.java:593) hudson.plugins.gearman.MyGearmanWorkerImpl.work(MyGearmanWorkerImpl.java:328) hudson.plugins.gearman.AbstractWorkerThread.run(AbstractWorkerThread.java:166) java.lang.Thread.run(Thread.java:745)
Gearman worker deployment-bastion.eqiad_exec-2 prio=5 TIMED_WAITING java.lang.Object.wait(Native Method) hudson.plugins.gearman.NodeAvailabilityMonitor.lock(NodeAvailabilityMonitor.java:83) hudson.plugins.gearman.MyGearmanWorkerImpl.sendGrabJob(MyGearmanWorkerImpl.java:380) hudson.plugins.gearman.MyGearmanWorkerImpl.processSessionEvent(MyGearmanWorkerImpl.java:421) hudson.plugins.gearman.MyGearmanWorkerImpl.work(MyGearmanWorkerImpl.java:320) hudson.plugins.gearman.AbstractWorkerThread.run(AbstractWorkerThread.java:166) java.lang.Thread.run(Thread.java:745)
Gearman worker deployment-bastion.eqiad_exec-3 prio=5 TIMED_WAITING java.lang.Object.wait(Native Method) hudson.plugins.gearman.NodeAvailabilityMonitor.lock(NodeAvailabilityMonitor.java:83) hudson.plugins.gearman.MyGearmanWorkerImpl.sendGrabJob(MyGearmanWorkerImpl.java:380) hudson.plugins.gearman.MyGearmanWorkerImpl.processSessionEvent(MyGearmanWorkerImpl.java:421) hudson.plugins.gearman.MyGearmanWorkerImpl.work(MyGearmanWorkerImpl.java:320) hudson.plugins.gearman.AbstractWorkerThread.run(AbstractWorkerThread.java:166) java.lang.Thread.run(Thread.java:745)
Gearman worker deployment-bastion.eqiad_exec-4 prio=5 TIMED_WAITING java.lang.Object.wait(Native Method) hudson.plugins.gearman.NodeAvailabilityMonitor.lock(NodeAvailabilityMonitor.java:83) hudson.plugins.gearman.MyGearmanWorkerImpl.sendGrabJob(MyGearmanWorkerImpl.java:380) hudson.plugins.gearman.MyGearmanWorkerImpl.processSessionEvent(MyGearmanWorkerImpl.java:421) hudson.plugins.gearman.MyGearmanWorkerImpl.work(MyGearmanWorkerImpl.java:320) hudson.plugins.gearman.AbstractWorkerThread.run(AbstractWorkerThread.java:166) java.lang.Thread.run(Thread.java:745)
Gearman worker deployment-bastion.eqiad_exec-5 prio=5 TIMED_WAITING java.lang.Object.wait(Native Method) hudson.plugins.gearman.NodeAvailabilityMonitor.lock(NodeAvailabilityMonitor.java:83) hudson.plugins.gearman.MyGearmanWorkerImpl.sendGrabJob(MyGearmanWorkerImpl.java:380) hudson.plugins.gearman.MyGearmanWorkerImpl.processSessionEvent(MyGearmanWorkerImpl.java:421) hudson.plugins.gearman.MyGearmanWorkerImpl.work(MyGearmanWorkerImpl.java:320) hudson.plugins.gearman.AbstractWorkerThread.run(AbstractWorkerThread.java:166) java.lang.Thread.run(Thread.java:745) }}
[JIRA] [gearman-plugin] (JENKINS-25867) Gearman won't schedule new jobs even though there are slots available on master
Title: Message Title Antoine Musso commented on JENKINS-25867 Re: Gearman won't schedule new jobs even though there are slots available on master The node is named deployment-bastion-eqiad, with a label deployment-bastion-eqiad. Jobs are tied to deployment-bastion-eqiad. The workaround I found was to remove the label from the node. Once done, the jobs shows in the queue with 'no node having label deployment-bastion-eqiad'. I then applied the label again on the host and the job managed to run. So maybe it is an issue in Jenkins itself :-} Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-28891) Bringing slaves online after running a build does not re-register gearman jobs
Title: Message Title Antoine Musso commented on JENKINS-28891 Re: Bringing slaves online after running a build does not re-register gearman jobs Seems https://review.openstack.org/#/c/192429/ fixed the deadlock for me. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-25867) Gearman won't schedule new jobs even though there are slots available on master
Title: Message Title
Antoine Musso edited a comment on JENKINS-25867
Re: Gearman won't schedule new jobs even though there are slots available on master
Theoriginalstoryboard:https://storyboard.openstack.org/#!/story/230Ourdownstreambug:https://phabricator.wikimedia.org/T72597Ourenvis:Jenkins1.596,gearman-plugin0.1.1-8-gf2024bd(fromsource).TheonlyblockswehaveareonaspecificslavethathappenstorunmatrixjobswhicharetriggeredbytheJenkinsinternalscheduler.WedonotuseOFFLINE_NODE_WHEN_COMPLETEyet.Mostimportantly,Icannotfindawaytoreproducetheissuereliably.Inoticedtheexecutorthreadsareheldinalockthough(detailsandthreadsdumpathttps://phabricator.wikimedia.org/T72597#748059).AndthecomputerissometimeaNULLvalue:TheJenkinsloggerforhudson.plugins.gearman.loggershowsaspamof:Nov26,201410:24:21PMFINEhudson.plugins.gearman.NodeAvailabilityMonitorcanTakeAvailabilityMonitorcanTakerequestforSOMEVALUEWhereSOMEVALUEisnulloroneoneoftheexecutorthread. Anexample: {noformat}Jul01,201510:11:59AMFINEhudson.plugins.gearman.NodeAvailabilityMonitorcanTakeAvailabilityMonitorcanTakerequestfornull{noformat} Iwillgiveitatryathttps://review.openstack.org/#/c/192429/,butsinceIhavenowaytoreproducetheissueIwouldnotbeabletoconfirmwhethertheissueissolved:-\
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-25867) Gearman won't schedule new jobs even though there are slots available on master
Title: Message Title Antoine Musso commented on JENKINS-25867 Re: Gearman won't schedule new jobs even though there are slots available on master The original storyboard: https://storyboard.openstack.org/#!/story/230 Our downstream bug: https://phabricator.wikimedia.org/T72597 Our env is: Jenkins 1.596 , gearman-plugin 0.1.1-8-gf2024bd (from source). The only blocks we have are on a specific slave that happens to run matrix jobs which are triggered by the Jenkins internal scheduler. We do not use OFFLINE_NODE_WHEN_COMPLETE yet. Most importantly, I can not find a way to reproduce the issue reliably. I noticed the executor threads are held in a lock though (details and threads dump at https://phabricator.wikimedia.org/T72597#748059 ). And the computer is sometime a NULL value: The Jenkins logger for hudson.plugins.gearman.logger shows a spam of:Nov 26, 2014 10:24:21 PM FINE hudson.plugins.gearman.NodeAvailabilityMonitor canTake AvailabilityMonitor canTake request for SOME VALUE Where SOME VALUE is null or one one of the executor thread. I will give it a try at https://review.openstack.org/#/c/192429/ , but since I have no way to reproduce the issue I would not be able to confirm whether the issue is solved :-\ Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gearman-plugin] (JENKINS-25867) Gearman won't schedule new jobs even though there are slots available on master
Title: Message Title
Antoine Musso edited a comment on JENKINS-25867
Re: Gearman won't schedule new jobs even though there are slots available on master
Theoriginalstoryboard:https://storyboard.openstack.org/#!/story/230Ourdownstreambug:https://phabricator.wikimedia.org/T72597Ourenvis:Jenkins1.596,gearman-plugin0.1.1-8-gf2024bd(fromsource).TheonlyblockswehaveareonaspecificslavethathappenstorunmatrixjobswhicharetriggeredbytheJenkinsinternalscheduler.WedonotuseOFFLINE_NODE_WHEN_COMPLETEyet.Mostimportantly,Icannotfindawaytoreproducetheissuereliably.Inoticedtheexecutorthreadsareheldinalockthough(detailsandthreadsdumpathttps://phabricator.wikimedia.org/T72597#748059).AndthecomputerissometimeaNULLvalue:TheJenkinsloggerforhudson.plugins.gearman.loggershowsaspamof:Nov26,201410:24:21PMFINEhudson.plugins.gearman.NodeAvailabilityMonitorcanTakeAvailabilityMonitorcanTakerequestforSOMEVALUEWhereSOMEVALUEisnulloroneoneoftheexecutorthread.Anexample:{noformat}Jul01,201510:11:59AMFINEhudson.plugins.gearman.NodeAvailabilityMonitorcanTakeAvailabilityMonitorcanTakerequestfornull{noformat}I willgiveitatryat havedeployedthegerman-pluginwith https://review.openstack.org/#/c/192429/,butsinceIhavenowaytoreproducetheissueIwouldnotbeabletoconfirmwhethertheissueissolved:-\
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [credentials-plugin] (JENKINS-28993) Cant create SSH slave without credentials-id
Title: Message Title
Antoine Musso created an issue
Jenkins / JENKINS-28993
Cant create SSH slave without credentials-id
Issue Type:
Bug
Assignee:
stephenconnolly
Components:
credentials-plugin, ssh-credentials-plugin, ssh-slaves-plugin
Created:
19/Jun/15 7:41 PM
Environment:
Jenkins 1.596.2 SSH credentials 1.11 SSH Slaves 1.9 Credentials 1.22
Labels:
credentials rest api
Priority:
Critical
Reporter:
Antoine Musso
I am using the REST API to create a SSH slave using a username/privatekey (and not a credentials-id, doesn't match my use case).
The request looks like:
{{ https://integration.wikimedia.org/ci/computer/doCreateItem? json= { labelString: ci-jessie-wikimedia, launcher: { host: 10.68.17.84, port: 22, privatekey: /var/lib/nodepool/.ssh/nodepoolmanager_id_rsa, stapler-class: hudson.plugins.sshslaves.SSHLauncher, username: nodepoolmanager }
, mode: EXCLUSIVE, name: ci-jessie-wikimedia-33, nodeDescription: Dynamic
[JIRA] [core] (JENKINS-27441) hudson.model.Run.getLog throws IndexOutOfBoundsException when called with 0
Title: Message Title Antoine Musso commented on JENKINS-27441 Re: hudson.model.Run.getLog throws IndexOutOfBoundsException when called with 0 Maybe this fix should be added to the LTS version 1.609.X ? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ssh-credentials-plugin] (JENKINS-25412) Update JSch to 0.1.49
Title: Message Title Antoine Musso commented on JENKINS-25412 Re: Update JSch to 0.1.49 Wikimedia faced the same issue when the ssh algorithm got tweaked. Downstream bug is https://phabricator.wikimedia.org/T100517 . Copy paste: The SSH agent plugin depends on https://github.com/jenkinsci/ssh-credentials-plugin which we are running at version 1.11. The pom.xml lists com.jcraft jsch version 0.1.42. The lib changelog is http://www.jcraft.com/jsch/ChangeLog and: algo jsch version aes256-ctr 0.1.40 diffie-hellman-group-exchange-sha25 0.1.49 Both made to be defaults with 0.1.51. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [ssh-credentials-plugin] (JENKINS-25412) Update JSch to 0.1.49
Title: Message Title Antoine Musso edited a comment on JENKINS-25412 Re: Update JSch to 0.1.49 Wikimediafacedthesameissuewhenthesshalgorithmgottweaked.Downstream bugis bugsare: https://phabricator.wikimedia.org/ T100517 T100509(incidentreport)https://phabricator . Copypaste wikimedia.org/T100517(trackingthisJenkinsbug)Thesymptomwas : fatal:nomatchingmacfound:clienthmac-sha1-96,hmac-sha1,hmac-md5-96,hmac-md5serverhmac-sha2-512,hmac-sha2-256[preauth]error:Couldnotloadhostkey:/etc/ssh/ssh_host_ed25519_key The relatedpuppetchangeto/etc/ssh/sshd_configthatfixeditforus:-KexAlgorithmscurve25519-sha...@libssh.org,diffie-hellman-group-exchange-sha256-MACshmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-...@openssh.comThe SSHagentplugindependsonhttps://github.com/jenkinsci/ssh-credentials-pluginwhichwearerunningatversion1.11.Thepom.xmllistscom.jcraftjschversion0.1.42.Thelibchangelogishttp://www.jcraft.com/jsch/ChangeLogand:||algo||jschversion|||aes256-ctr|0.1.40||diffie-hellman-group-exchange-sha25|0.1.49|Bothmadetobedefaultswith0.1.51. Sobumpingto0.1.49wouldprovidediffie-hellman-group-exchange-sha25andsolvetheissueforus. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [notification-plugin] (JENKINS-27323) Out of index error with logLines defaulting to 0
Title: Message Title Antoine Musso commented on JENKINS-27323 Re: Out of index error with logLines defaulting to 0 We used the notification plugin to report build start/completions to the Zuul gating system ( http://docs.openstack.org/infra/zuul/ ). Turns out Zuul now uses the Gearman plugin to achieve that behavior and I have updated Jenkins Job Builder to no more rely on that plugin ( https://review.openstack.org/#/c/167254/ ). The bug still stand but it is no more impacting me. Was probably fixed by https://issues.jenkins-ci.org/browse/JENKINS-27441 apparently to be released with jenkins-1.613 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ircbot-plugin] (JENKINS-28175) config change deadlock Jenkins when pircx.shutdown() is invoked
Title: Message Title Antoine Musso commented on JENKINS-28175 Re: config change deadlock Jenkins when pircx.shutdown() is invoked kutzi wrote: Antoine, any chance you can try the unreleased IRC plugin? Unlikely, the issue caused much havoc on the system and I can reproduce it on my dev instance. Moreover I have no idea how to reproduce it on the prod instance :-/ That being said, I found out that when stopping Jenkins it ends up waiting for org.pircbotx.Channel.getMode(). That might be the same root cause. You can find a full stacktrace at https://phabricator.wikimedia.org/T98976 , I can fill it as another bug if it is unrelated. kutzi wrote: https://dl.dropboxusercontent.com/u/25863594/ircbot.hpi I guess I can just build it from https://github.com/jenkinsci/ircbot-plugin/commit/d18cc7b617155100f8afadb73b324f378c5661da and maybe grab as well the latest instant-messaging-plugin https://github.com/jenkinsci/ircbot-plugin/commit/a78e066fc57001168a8ffc1893a3de2c91a1d518 :-} Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ssh-credentials-plugin] (JENKINS-25412) Update JSch to 0.1.49
Title: Message Title Antoine Musso commented on JENKINS-25412 Re: Update JSch to 0.1.49 I am proposing the bump with the lame patch https://github.com/jenkinsci/ssh-credentials-plugin/pull/14 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ssh-credentials-plugin] (JENKINS-25412) Update JSch to 0.1.49
Title: Message Title Antoine Musso updated an issue Jenkins / JENKINS-25412 Update JSch to 0.1.49 Change By: Antoine Musso Issue Type: Improvement Patch Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-27441) hudson.model.Run.getLog throws IndexOutOfBoundsException when called with 0
Title: Message Title Antoine Musso commented on JENKINS-27441 Re: hudson.model.Run.getLog throws IndexOutOfBoundsException when called with 0 Excellent! Thanks Daniel for pointing me to the label (very nice). Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ircbot-plugin] (JENKINS-28175) config change deadlock Jenkins when pircx.shutdown() is invoked
Antoine Musso created JENKINS-28175 config change deadlock Jenkins when pircx.shutdown() is invoked Issue Type: Bug Assignee: kutzi Components: ircbot-plugin Created: 30/Apr/15 2:10 PM Description: We have recently upgraded the IRC plugin from 2.25 to 2.26. On configuration change, the ircbot plugin invokes PircBotX.shutdown(). For some reason it never finish and the conf change is stalled. A side effect is that jobs sending notifications ends up being blocked waiting for an instance of the irc connection provider. The only fix is to restart Jenkins entirely. Our bug has a few more explanations https://phabricator.wikimedia.org/T96183 and a full thread dump attached https://phabricator.wikimedia.org/P584 Here are the blocked threads: Two jobs are blocked: "Executor #2 for integration-slave-trusty-1016 : executing browsertests-CentralNotice-en.wikipedia.beta.wmflabs.org-windows_7-internet_explorer-10-sauce #234" prio=5 BLOCKED "Executor #1 for integration-slave-trusty-1012 : executing browsertests-PdfHandler-test2.wikipedia.org-linux-firefox-sauce #494" prio=5 BLOCKED hudson.plugins.ircbot.v2.IRCConnectionProvider.getInstance(IRCConnectionProvider.java:14) hudson.plugins.ircbot.IrcPublisher.getIMConnection(IrcPublisher.java:102) hudson.plugins.im.IMPublisher.sendNotification(IMPublisher.java:374) hudson.plugins.im.IMPublisher.notifyChatsOnBuildEnd(IMPublisher.java:585) hudson.plugins.im.IMPublisher.notifyOnBuildEnd(IMPublisher.java:304) hudson.plugins.im.IMPublisher.perform(IMPublisher.java:291) ... A configuration submit change is blocked as well: "Handling POST /ci/configSubmit from X.X.X.X : RequestHandlerThread[#1683]" daemon prio=5 WAITING sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994) java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303) java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236) org.pircbotx.Channel.getMode(Channel.java:127) org.pircbotx.Channel.getModeArgument(Channel.java:182) org.pircbotx.Channel.getChannelKey(Channel.java:239) org.pircbotx.PircBotX.shutdown(PircBotX.java:2872) hudson.plugins.ircbot.v2.IRCConnection.close(IRCConnection.java:102) hudson.plugins.im.IMConnectionProvider.releaseConnection(IMConnectionProvider.java:92) hudson.plugins.ircbot.v2.IRCConnectionProvider.setDesc(IRCConnectionProvider.java:19) hudson.plugins.ircbot.IrcPublisher$DescriptorImpl.configure(IrcPublisher.java:336) jenkins.model.Jenkins.configureDescriptor(Jenkins.java:2915) jenkins.model.Jenkins.doConfigSubmit(Jenkins.java:2878) ... Some other related threads: "JenkinsIsBusyListener-thread" daemon prio=5 BLOCKED hudson.plugins.im.IMConnectionProvider.currentConnection(IMConnectionProvider.java:83) hudson.plugins.im.JenkinsIsBusyListener.setStatus(JenkinsIsBusyListener.java:118) hudson.plugins.im.JenkinsIsBusyListener.updateIMStatus(JenkinsIsBusyListener.java:109) hudson.plugins.im.JenkinsIsBusyListener.access$000(JenkinsIsBusyListener.java:20) hudson.plugins.im.JenkinsIsBusyListener$3.run(JenkinsIsBusyListener.java:98) java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) java.util.concurrent.FutureTask.run(FutureTask.java:262) java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) java.lang.Thread.run(Thread.java:745) "IM-Reconnector-Thread" daemon prio=5 BLOCKED
[JIRA] [notification-plugin] (JENKINS-27323) Out of index error with logLines defaulting to 0
Antoine Musso commented on JENKINS-27323 Out of index error with logLines defaulting to 0 We have the same issue after upgrading from 1.7 to 1.9 our downstream bug is https://phabricator.wikimedia.org/T93321 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-25175) ItemListener event not fired when user updates projects configuration using REST API
Antoine Musso commented on JENKINS-25175 ItemListener event not fired when user updates projects configuration using REST API Not sure this is a bug. Still, workaround is present, so reducing priority: Implement SaveableListener.onChange. It seems to be a bug to me, the web interface and the REST API behave completely differently. The issue at hand is that changes made via the web interface triggers ItemListener events based on fields that have been changed. On the other hand, the REST API is just a way to upload a new config file, so it uses the SaveableListener which is rather dumb and fire an event which has the whole new XML file. Ie SaveableListener is a gross generalization while ItemListener is thiner. Would it make sense to have the REST API to fire the ItemListener events as well? It might not be doable though since the only data available is the whole config file and I think the events need finer informations (such as a Label object, not a whole config file). Another way would be to have the SaveableListener events build in core to inject the new conf to the code that handles configuration changes for the web interface, thus reusing all the existing logic that ends up triggering ItemListener events. To say it otherwise: I would expect uploading a config file to behave exactly the same as doing a change via the web interface form. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [instant-messaging] (JENKINS-5031) instant-messaging plugin notifications with custom messages
Antoine Musso
commented on JENKINS-5031
instant-messaging plugin notifications with custom messages
For what it is worth, the messages are defined in: src/main/resources/hudson/plugins/im/build_notify/Messages.properties
SummaryOnlyBuildToChatNotifier.Summary=Project {0} build {1}: {2} in {3}: {4}
SummaryOnlyBuildToChatNotifier.BuildIsFixed=Yippee, build fixed!\n
SummaryOnlyBuildToChatNotifier.StartMessage=Starting build {0} for job {1}
I would love an option to at least disable the BuildIsFixed message. The two other messages should be changeable in the interface, probably globally and on a per job basis. The Summary message shows the job URL which already contains the job name and build number, not much point in repeating them.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [artifactdeployer] (JENKINS-24140) ArtifactDeployer migration breaks lazy-load on Jenkins initialization
Antoine Musso commented on JENKINS-24140 ArtifactDeployer migration breaks lazy-load on Jenkins initialization Gregory, on the first upgrade, I have let the migration complete which took several hours. On the next restart, it started over again which prompted me to downgrade the plugin. It seems the migration is triggered very early in Jenkins startup process. Maybe it can be triggered asynchronously after Jenkins has booted (and at least the web gui is made available).If a job hasn't been migrated yet, the build could trigger the migration. Aka lazy migration :-] This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [artifactdeployer] (JENKINS-24140) ArtifactDeployer lazy load the whole history on Jenkins initialization
Antoine Musso created JENKINS-24140 ArtifactDeployer lazy load the whole history on Jenkins initialization Issue Type: Bug Assignee: Gregory Boissinot Components: artifactdeployer Created: 06/Aug/14 6:32 PM Description: After upgrading to Jenkins 1.565.1 my setup apparently loaded just fine. I then upgraded the ArtifactDeployer to version 0.31 and restarted. The web interface was stuck for quite a long time because artifact deployer register a migration process that ends up loading all projects history. Thread dump: "Jenkins initialization thread" prio=5 RUNNABLE java.io.FileInputStream.readBytes(Native Method) java.io.FileInputStream.read(FileInputStream.java:239) java.io.BufferedInputStream.fill(BufferedInputStream.java:235) java.io.BufferedInputStream.read(BufferedInputStream.java:254) java.io.FilterInputStream.read(FilterInputStream.java:83) java.io.PushbackInputStream.read(PushbackInputStream.java:139) com.thoughtworks.xstream.core.util.XmlHeaderAwareReader.getHeader(XmlHeaderAwareReader.java:79) com.thoughtworks.xstream.core.util.XmlHeaderAwareReader.init(XmlHeaderAwareReader.java:61) com.thoughtworks.xstream.io.xml.AbstractXppDriver.createReader(AbstractXppDriver.java:65) hudson.XmlFile.unmarshal(XmlFile.java:163) hudson.model.Run.reload(Run.java:321) hudson.model.Run.init(Run.java:309) hudson.model.AbstractBuild.init(AbstractBuild.java:173) hudson.model.Build.init(Build.java:102) hudson.model.FreeStyleBuild.init(FreeStyleBuild.java:38) sun.reflect.GeneratedConstructorAccessor67.newInstance(Unknown Source) sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) java.lang.reflect.Constructor.newInstance(Constructor.java:534) jenkins.model.lazy.LazyBuildMixIn.loadBuild(LazyBuildMixIn.java:153) jenkins.model.lazy.LazyBuildMixIn$1.create(LazyBuildMixIn.java:134) hudson.model.RunMap.retrieve(RunMap.java:218) hudson.model.RunMap.retrieve(RunMap.java:56) jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:687) jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:670) jenkins.model.lazy.AbstractLazyLoadRunMap.all(AbstractLazyLoadRunMap.java:622) jenkins.model.lazy.AbstractLazyLoadRunMap.entrySet(AbstractLazyLoadRunMap.java:277) java.util.AbstractMap$2$1.init(AbstractMap.java:378) java.util.AbstractMap$2.iterator(AbstractMap.java:377) hudson.util.RunList.iterator(RunList.java:97) org.jenkinsci.plugins.artifactdeployer.migration.DeployedArtifactsMigrationItemListener.onLoaded(DeployedArtifactsMigrationItemListener.java:29) jenkins.model.Jenkins.init(Jenkins.java:863) hudson.model.Hudson.init(Hudson.java:82) hudson.model.Hudson.init(Hudson.java:78) hudson.WebAppMain$3.run(WebAppMain.java:222) Once finished, I eventually had access to the web interface. On the next restart, the Jenkins initialization was stuck again with the same thread dump. Seems the migration occurs over and over on every initialization. Things to check: should handle the migration after the initialization to avoid blocking the web interface should not lazy load all projects and builds I guess the migration should occur only once. Environment: Jenkins 1.565.1 ArtifactDeployer 0.31 Project: Jenkins Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] [artifactdeployer] (JENKINS-24140) ArtifactDeployer migration breaks lazy-load on Jenkins initialization
Antoine Musso updated JENKINS-24140 ArtifactDeployer migration breaks lazy-load on Jenkins initialization Change By: Antoine Musso (06/Aug/14 6:41 PM) Summary: ArtifactDeployer migrationbreaks lazy - load thewholehistory onJenkinsinitialization This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [artifactdeployer] (JENKINS-24140) ArtifactDeployer migration breaks lazy-load on Jenkins initialization
Antoine Musso commented on JENKINS-24140 ArtifactDeployer migration breaks lazy-load on Jenkins initialization Might be caused by commit https://github.com/jenkinsci/artifactdeployer-plugin/commit/fc467016194911f57a8daa82023694d7c3698b66 "Fix JENKINS-16130 and JENKINS-14681" This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [artifactdeployer] (JENKINS-24140) ArtifactDeployer migration breaks lazy-load on Jenkins initialization
Antoine Musso commented on JENKINS-24140 ArtifactDeployer migration breaks lazy-load on Jenkins initialization Our bug for reference https://bugzilla.wikimedia.org/show_bug.cgi?id=69197 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [artifactdeployer] (JENKINS-24140) ArtifactDeployer migration breaks lazy-load on Jenkins initialization
Antoine Musso commented on JENKINS-24140 ArtifactDeployer migration breaks lazy-load on Jenkins initialization I have downgraded the plugin to the previous version I had (0.29) and Jenkins starts just fine. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [email-ext] (JENKINS-23126) email-ext should be able to send emails in both HTML and text
Antoine Musso created JENKINS-23126 email-ext should be able to send emails in both HTML and text Issue Type: Bug Assignee: Alex Earl Components: email-ext Created: 21/May/14 1:42 PM Description: The email-ext plugin can be configured to send emails with either HTML or plain text. It would be quite nice to have an option to send them as multipart messages containing both HTML and plain text. My use case is sending HTML notification to a mailman mailing list. The mails are received just fine and show up nicely formatted. Mailman archiver does not support HTML though, so it strip it out and only show the plain text content which is empty. Example: http://lists.wikimedia.org/pipermail/qa-alerts/2014-May/05.html shows: An HTML attachment was scrubbed... URL: http://lists.wikimedia.org/pipermail/qa-alerts/attachments/20140521/0dc7bbc7/attachment.html Expected: FAILURE whatever-job-here build #42 http://jenkins.example.com/ci/job/whatever-job-here/42 An HTML attachment was scrubbed... URL: http://lists.wikimedia.org/pipermail/qa-alerts/attachments/20140521/0dc7bbc7/attachment.html That would be a very nice addition to the plugin. Environment: Jenkins 1.532.3 email-ext 2.37.2.2 Project: Jenkins Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [security] (JENKINS-22044) Denial of service by browsing node build history
Antoine Musso created JENKINS-22044 Denial of service by browsing node build history Issue Type: Bug Assignee: Unassigned Attachments: request_starving.txt Components: security Created: 05/Mar/14 10:21 AM Description: I have a setup with a node running a lot of short jobs for which we want to keep the history for a year or so. That is few hundred of thousands build kept. Whenever one browse GET /ci/computer/MyNode/builds, Jenkins lazy load all the jobs that happened on that node and apparently parse most of the builds. That makes a RequestHandlerThread eating 100% CPU for quite a long time. The front end web proxy / web browser eventually timeout and a user would usually refresh the page several time, creating more RequestHandlerThread trying to lazy load the whole build history. End results: the pool of RequestHandlerThread is filled with long running queries. The web interface is no more accessible. All core are at 100% usage making the box unusable. Attached is a stacktrace of a RequestHandlerThread. Possible suggestions: implement a lock mechanism to avoid several threads to do the exact same long running task. If the exact same query is done it should wait for the first one to complete and give the same result limit the number of builds shown on the node/build page have a way to easily set a timeout for RequestHandlerThread so it dies after X minutes. Project: Jenkins Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [copy-to-slave] (JENKINS-21983) CopyToSlave exception when source contain a file starting with a .dot
Antoine Musso commented on JENKINS-21983 CopyToSlave exception when source contain a file starting with a .dot I have inserted /slave/ by mistake while doing the bug report. After some more investigation, it seems the issue is because of some file permissions (the copy is made by the jenkins master to a directory owned by the jenkins slave on that machine). Will look at it again and might well close this bug. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [copy-to-slave] (JENKINS-21983) CopyToSlave exception when source contain a file starting with a .dot
Antoine Musso resolved JENKINS-21983 as Not A Defect CopyToSlave exception when source contain a file starting with a .dot Turned out to be a file permission issue. The jenkins user could not write to the destination and the error message 'No such file or directory' made it very confusing. Everything for me now :-] Change By: Antoine Musso (28/Feb/14 1:49 PM) Status: Open Resolved Resolution: NotADefect This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [jira] (JENKINS-21976) Rename jira cloverphp-plugin to cloverphp
Antoine Musso
created JENKINS-21976
Rename jira cloverphp-plugin to cloverphp
Issue Type:
Bug
Assignee:
Unassigned
Components:
jira
Created:
27/Feb/14 10:29 AM
Description:
The Clover PHP Wiki page 'Open Issue' link points to the wrong component.
On the wiki page https://wiki.jenkins-ci.org/display/JENKINS/Clover+PHP+Plugin we have:
{jenkins-plugin-info:pluginId=cloverphp}
That displays the information for the plugin properly.
The 'Open Issue' link search for bugs filled against 'cloverphp', but in Jira the component is registered as 'cloverphp-plugin'. As a result, no issue are opened.
Can we have the Jira component 'cloverphp-plugin' renamed to 'cloverphp'?
Thanks!
Project:
Jenkins
Priority:
Major
Reporter:
Antoine Musso
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [cloverphp-plugin] (JENKINS-21976) Rename jira cloverphp-plugin to cloverphp
Antoine Musso reopened JENKINS-21976 Rename jira cloverphp-plugin to cloverphp Assuming a mistake since the page still has the plugin id cloverphp and the plugin is still registered as cloverphp-plugin. Change By: Antoine Musso (27/Feb/14 10:54 AM) Resolution: Fixed Status: Resolved Reopened This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [cloverphp-plugin] (JENKINS-21976) Rename jira cloverphp-plugin to cloverphp
Antoine Musso resolved JENKINS-21976 as Fixed Rename jira cloverphp-plugin to cloverphp There was a double pipe in the wiki template which caused the parameter to be ignored. Fixed finally. Thanks! Change By: Antoine Musso (27/Feb/14 11:07 AM) Status: Reopened Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [copy-to-slave] (JENKINS-21983) CopyToSlave exception when source contain a file starting with a .dot
Antoine Musso created JENKINS-21983 CopyToSlave exception when source contain a file starting with a .dot Issue Type: Bug Assignee: Vivekanand SV Components: copy-to-slave Created: 27/Feb/14 5:25 PM Description: I have a slave job with a file: $WORKSPACE/slave/.buildinfo I attempt to copy it to a directory on the master and got the following stacktrace: 00:00:47.432 copy-to-slave Copying 'html/*,/html/*', excluding nothing, from 'file:/mnt/jenkins-workspace/workspace/mw-tools-releng-tox-doc-publish/' on 'hudson.slaves.DumbSlave@6c2e5320' to 'file:/srv/org/wikimedia/doc/mw-tools-releng' on the master. 00:00:47.779 ERROR: Publisher com.michelin.cio.hudson.plugins.copytoslave.CopyToMasterNotifier aborted due to exception 00:00:47.780 hudson.util.IOException2: Failed to extract /mnt/jenkins-workspace/workspace/mw-tools-releng-tox-doc-publish/html/*,/html/* 00:00:47.780 at hudson.FilePath.readFromTar(FilePath.java:2066) 00:00:47.780 at hudson.FilePath.copyRecursiveTo(FilePath.java:1978) 00:00:47.780 at hudson.FilePath.copyRecursiveTo(FilePath.java:1889) 00:00:47.780 at com.michelin.cio.hudson.plugins.copytoslave.CopyToMasterNotifier.perform(CopyToMasterNotifier.java:95) 00:00:47.780 at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45) 00:00:47.781 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:785) 00:00:47.781 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:757) 00:00:47.781 at hudson.model.Build$BuildExecution.post2(Build.java:183) 00:00:47.781 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:706) 00:00:47.781 at hudson.model.Run.execute(Run.java:1690) 00:00:47.781 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) 00:00:47.782 at hudson.model.ResourceController.execute(ResourceController.java:88) 00:00:47.782 at hudson.model.Executor.run(Executor.java:246) 00:00:47.782 Caused by: java.io.FileNotFoundException: /srv/org/wikimedia/doc/mw-tools-releng/html/.buildinfo (No such file or directory) 00:00:47.782 at java.io.FileOutputStream.open(Native Method) 00:00:47.782 at java.io.FileOutputStream.init(FileOutputStream.java:212) 00:00:47.782 at java.io.FileOutputStream.init(FileOutputStream.java:160) 00:00:47.783 at hudson.util.IOUtils.copy(IOUtils.java:35) 00:00:47.783 at hudson.FilePath.readFromTar(FilePath.java:2056) 00:00:47.783 ... 12 more 00:00:47.789 Finished: FAILURE Project: Jenkins Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-21217) projects fully loaded on start causing slow startup
Antoine Musso created JENKINS-21217 projects fully loaded on start causing slow startup Issue Type: Bug Assignee: Unassigned Components: core Created: 03/Jan/14 2:53 PM Description: when starting Jenkins, it loads all jobs which eventually trigger a parse of the whole build history. That definitely takes a long time and cause my setup to take up to 20 minutes to start. Using jstack, I found out stack traces such as: For a freestyle project: "Loading job mwext-VectorBeta-lint" daemon prio=10 tid=0x7f8a24001000 nid=0x33c0 runnable 0x7f8a8854e000 java.lang.Thread.State: RUNNABLE at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:243) at java.io.File.isDirectory(File.java:815) at hudson.model.RunMap$3.accept(RunMap.java:205) at java.io.File.list(File.java:1095) at jenkins.model.lazy.AbstractLazyLoadRunMap.loadIdOnDisk(AbstractLazyLoadRunMap.java:227) at jenkins.model.lazy.AbstractLazyLoadRunMap.initBaseDir(AbstractLazyLoadRunMap.java:203) at jenkins.model.lazy.AbstractLazyLoadRunMap.init(AbstractLazyLoadRunMap.java:195) at hudson.model.RunMap.init(RunMap.java:84) at hudson.model.AbstractProject.createBuildRunMap(AbstractProject.java:337) at hudson.model.AbstractProject.onLoad(AbstractProject.java:299) at hudson.model.Project.onLoad(Project.java:90) at hudson.model.Items.load(Items.java:221) at jenkins.model.Jenkins$18.run(Jenkins.java:2562) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at jenkins.model.Jenkins$7.runTask(Jenkins.java:899) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) Or in a maven project: "Loading job gerrit-core-wmf" daemon prio=10 tid=0x7f8a08001000 nid=0x33c5 runnable 0x7f8a03ffd000 java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:140) at hudson.XmlFile.read(XmlFile.java:141) at hudson.model.Items.load(Items.java:220) at hudson.model.ItemGroupMixIn.loadChildren(ItemGroupMixIn.java:99) at hudson.maven.MavenModuleSet.onLoad(MavenModuleSet.java:768) at hudson.model.Items.load(Items.java:221) at jenkins.model.Jenkins$18.run(Jenkins.java:2562) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at jenkins.model.Jenkins$7.runTask(Jenkins.java:899) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) Using strace, I can confirm Jenkins attempt to load all the build history files I am not sure why it would need to do so though. Environment: Jenkins 1.532.1 Project: Jenkins Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see:
[JIRA] [cloverphp-plugin] (JENKINS-21046) option to generate clover report regardless of build status
Antoine Musso created JENKINS-21046 option to generate clover report regardless of build status Issue Type: Bug Assignee: sogabe Components: cloverphp-plugin Created: 17/Dec/13 2:45 PM Description: I got a fairly large PHPUnit test suite that takes up to 40 minutes to run. Due to some weird bug in PHP or Xdebug, it ends segfaulting when PHP shutdown. Regardless, the clover.xml is properly generated and could be made a report. Alas, the plugin does not generate the clover report because of the build failure (added URL to console log, copied relevant part below): /tmp/hudson2299744543392632448.sh: line 8: 6928 Segmentation fault nice -n 19 php tests/phpunit/phpunit.php --with-phpunitdir /srv/deployment/integration/phpunit/vendor/phpunit/phpunit --exclude-group Dump,Broken,ParserFuzz,Stub --coverage-clover log/clover.xml --coverage-html /srv/org/wikimedia/integration/cover/mediawiki-core/master/php Build step 'Execute shell' marked build as failure Publishing Clover coverage report... No Clover report will be published due to a Build Failure Finished: FAILURE It would be very nice to have an option detecting whether the clover.xml is non empty and fresh and generate the coverage report regardless of the build status. Environment: Plugin version 0.3.3 Jenkins 1.509.4 (LTS) Project: Jenkins Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [ansicolor] (JENKINS-19018) system default colormap
Antoine Musso created JENKINS-19018 system default colormap Issue Type: Bug Assignee: Unassigned Components: ansicolor Created: 31/Jul/13 1:11 PM Description: When enabling the ansi coloring on a job, it seems to pick the xterm one as a default. It would be nice to have a global setting to change the default colormap being chosen for jobs not specifying one. My use case is that the 'vga' colormap looks nicer with a white background and I would really like to have this the default for any job created, specially when people have no clue about the map option :-] Environment: Jenkins 1.509.2 Ansicolor 0.3.1 Project: Jenkins Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-18169) Deadlock when running multiple delete
Antoine Musso commented on JENKINS-18169 Deadlock when running multiple delete I am hit by the same issue with Jenkins 1.509.2. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-18870) debian init script is missing access_log support
Antoine Musso created JENKINS-18870 debian init script is missing access_log support Issue Type: Bug Assignee: Unassigned Components: core Created: 22/Jul/13 2:43 PM Description: The rpm provide JENKINS_ENABLE_ACCESS_LOG which enable Jenkins to write down some access log. It is missing from the debian package. One would have to: 1) add JENKINS_ENABLE_ACCESS_LOG support in debian/debian/jenkins.init 2) update the logrotate script 3) update debian/debian/jenkins.default Project: Jenkins Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-18874) logrotate script kills Jenkins (SIGALRM)
Antoine Musso created JENKINS-18874 logrotate script kills Jenkins (SIGALRM) Issue Type: Bug Assignee: Unassigned Components: core Created: 22/Jul/13 4:11 PM Description: The logrotate script provided in the rpm and opensuse packages send an ALRM script to java after the log have been rotated. The result is that it entirely kills the java process which is not very nice. Way to reproduce: /bin/kill -s ALRM pid of java process there You could react on SIGUSR1 / SIGUSR2 maybe. Environment: 1.590.2 Project: Jenkins Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17837) slow startup caused by loading all build.xml history
Antoine Musso commented on JENKINS-17837 slow startup caused by loading all build.xml history So looking at the Jstack again, I have noticed one of them was refering a plugin: https://wiki.jenkins-ci.org/display/JENKINS/Downstream+buildview+plugin I have disabled that and now my Jenkins boot instantly. I guess this bug need to be reassigned to the downstream-buildview plugin. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-17379) dynamically join IRC channels defined in jobs
Antoine Musso created JENKINS-17379 dynamically join IRC channels defined in jobs Issue Type: New Feature Affects Versions: current Assignee: kutzi Components: ircbot Created: 27/Mar/13 12:19 PM Description: Whenever a job specify an IRC channel that is not defined in the global configuration, the IRC bot is not able to send to that channel. Given a job like: publishers hudson.plugins.ircbot.IrcPublisher targets hudson.plugins.im.GroupChatIMMessageTarget name#wikimedia-test/name notificationOnlyfalse/notificationOnly /hudson.plugins.im.GroupChatIMMessageTarget /targets strategyALL/strategy notifyOnBuildStarttrue/notifyOnBuildStart notifySuspectsfalse/notifySuspects notifyCulpritsfalse/notifyCulprits notifyFixersfalse/notifyFixers notifyUpstreamCommittersfalse/notifyUpstreamCommitters buildToChatNotifier class="hudson.plugins.im.build_notify.DefaultBuildToChatNotifier"/ matrixMultiplierONLY_CONFIGURATIONS/matrixMultiplier channels/ /hudson.plugins.ircbot.IrcPublisher /publishers The resulting FINEST log for 'hudson.plugins.ircbot' gives out: Mar 27, 2013 12:09:14 PM hudson.plugins.ircbot.v2.PircListener onServerResponse WARNING: IRC server responded error 404 Message: mw-jenkinsbot #wikimedia-test :Cannot send to channel Mar 27, 2013 12:09:14 PM hudson.plugins.ircbot.v2.PircListener onServerResponse WARNING: IRC server responded error 404 Message: mw-jenkinsbot #wikimedia-test :Cannot send to channel There are several ways to solve this issue. Either: in job configuration, only list the globally configured channels. Maybe using a list to pick from. dynamically register channels on job save and make the bot join. Could be made an optional feature. Also, with the default login level, the plugin does not warn that it has not been able to send the notification. The console shows: Started by user hashar Building on master in workspace /var/lib/jenkins/jobs/Test - IRC notification/workspace IRC notifier plugin: Sending notification to: #wikimedia-test Finished: SUCCESS Which is a bit misleading. Environment: IRC plugin 2.21 Jenkins LTS 1.480.3 Project: Jenkins Labels: irc Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-17380) passing commands in private should not require the command prefix
Antoine Musso created JENKINS-17380 passing commands in private should not require the command prefix Issue Type: Improvement Affects Versions: current Assignee: kutzi Components: instant-messaging Created: 27/Mar/13 12:36 PM Description: I have the jenkins box named 'mw-jenkinsbot' and configured with the command prefix: 'mw-jenkinsbot:'. That works when talking in a public channel. On the other hand, when doing a /query to the bot directly, the commands are not honored. Example: /query mw-jenkinsbot help .. nothing .. It turns out that private messages require the command prefix. I guess it should be optional in that context: /query mw-jenkinsbot mwjenkinsbot: help mw-jenkinsbot Available commands: ... rest of help ... Environment: instant messaging 1.25 irc 2.21 jenkins LTS 1.480.3 Project: Jenkins Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-13446) Dependency graph points to localhost:8080
Antoine Musso commented on JENKINS-13446 Dependency graph points to localhost:8080 That indeed fixed the issue. Thanks! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-16435) implements an easier way to set verbose mode
Antoine Musso created JENKINS-16435 implements an easier way to set verbose mode Issue Type: Bug Assignee: Nicolas De Loof Components: git Created: 22/Jan/13 7:56 AM Description: When using the git plugin, the console output might be mind-boggling because it does not gives enough details. The plugin has support for more verbosity in the console log by starting Jenkins with the java parameter -Dhudson.plugins.git.GitSCM.verbose="true" The relevant code in GitSCM.java : public static boolean VERBOSE = Boolean.getBoolean(GitSCM.class.getName() + ".verbose"); This has already saved me a lot of time once I have discovered this switch. Would it be possible to add an option to enable this globally and another option to enable verbosity on a per job basis? I guess the default will be non verbose. Project: Jenkins Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13216) Allow Triggers on Custom Labels
Antoine Musso resolved JENKINS-13216 as Fixed Allow Triggers on Custom Labels This was resolved by the release 2.6.0. The plugin now let you configure triggering on a custom field such as "Code Review" or "Verified" being set to a given score (ex: 2). Change By: Antoine Musso (21/Sep/12 1:19 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15268) comment added is triggered on patch merge
Antoine Musso created JENKINS-15268 comment added is triggered on patch merge Issue Type: Bug Assignee: rsandell Components: gerrit-trigger Created: 21/Sep/12 1:43 PM Description: Whenever a change is merged in a repository, a CommentAdded event is triggered as well which will trigger a build if the verdict is honored. Given a repository requiring verified+1 / codereview +2 to merge a change Setup a job triggering on "Comment Added", Verdict: "Code-Review", Value: 2 In Gerrit, a privileged user press the submit button, set +1/+2 and merge the change. End result: two CommentAdded events are triggered. Here is a session log for a job named GerritTriggerTesting and change 24533 patchset 1: Sep 21, 2012 12:57:24 PM com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritTrigger schedule INFO: Project GerritTriggerTesting Build Scheduled: true By event: 24533/1 Sep 21, 2012 12:57:24 PM com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritTrigger schedule INFO: Project GerritTriggerTesting Build Scheduled: true By event: 24533/1 Sep 21, 2012 12:57:27 PM com.sonyericsson.hudson.plugins.gerrit.trigger.gerritnotifier.ToGerritRunListener onStarted INFO: Gerrit build GerritTriggerTesting #238 Started for cause: GerritCause: com.sonyericsson.hudson.plugins.gerrit.gerritevents.dto.events.CommentAdded@63dc5002 silent: true. Sep 21, 2012 12:57:27 PM com.sonyericsson.hudson.plugins.gerrit.trigger.gerritnotifier.ToGerritRunListener onStarted INFO: MemoryStatus: null Sep 21, 2012 12:57:27 PM hudson.model.Run execute INFO: GerritTriggerTesting #238 main build action completed: FAILURE Sep 21, 2012 12:57:27 PM com.sonyericsson.hudson.plugins.gerrit.trigger.gerritnotifier.ToGerritRunListener onCompleted INFO: Completed. Build: GerritTriggerTesting #238 Cause: GerritCause: com.sonyericsson.hudson.plugins.gerrit.gerritevents.dto.events.CommentAdded@63dc5002 silent: true Sep 21, 2012 12:57:27 PM com.sonyericsson.hudson.plugins.gerrit.trigger.gerritnotifier.ToGerritRunListener onStarted INFO: Gerrit build GerritTriggerTesting #238 Started for cause: GerritCause: com.sonyericsson.hudson.plugins.gerrit.gerritevents.dto.events.CommentAdded@63dc5002 silent: true. Sep 21, 2012 12:57:27 PM com.sonyericsson.hudson.plugins.gerrit.trigger.gerritnotifier.ToGerritRunListener onStarted INFO: MemoryStatus: null Sep 21, 2012 12:57:27 PM hudson.model.Run execute INFO: GerritTriggerTesting #238 main build action completed: FAILURE Sep 21, 2012 12:57:27 PM com.sonyericsson.hudson.plugins.gerrit.trigger.gerritnotifier.ToGerritRunListener onCompleted INFO: Completed. Build: GerritTriggerTesting #238 Cause: GerritCause: com.sonyericsson.hudson.plugins.gerrit.gerritevents.dto.events.CommentAdded@63dc5002 silent: true Log abstract: INFO: Project GerritTriggerTesting Build Scheduled: true By event: 24533/1 INFO: Project GerritTriggerTesting Build Scheduled: true By event: 24533/1 INFO: Gerrit build GerritTriggerTesting #238 Started for cause: GerritCause: com.sonyericsson.hudson.plugins.gerrit.gerritevents.dto.events.CommentAdded@63dc5002 silent: true. INFO: Gerrit build GerritTriggerTesting #238 Started for cause: GerritCause: com.sonyericsson.hudson.plugins.gerrit.gerritevents.dto.events.CommentAdded@63dc5002 silent: true. Environment: Gerrit Trigger 2.6.0 Project: Jenkins Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more
[JIRA] (JENKINS-14355) create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD)
Antoine Musso commented on JENKINS-14355 create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD) Might be related to JENKINS-13165 which is about ant excluding .git directories by default. Looking at core/src/main/java/hudson/tasks/Fingerprinter.java record() calls FileSet src = ""> The fix for the dirScanner was: https://github.com/jenkinsci/jenkins/commit/0725d2765da789e02914deb4893a449eeda6a820 Which added an option to disable the default excludes, aka: FileSet fs = Util.createFileSet(dir,includes,excludes); fs.setDefaultexcludes(useDefaultExcludes); The core/src/main/java/hudson/Util.java createFileSet() method does have an exclude which default to null but does not allow one to disable the useDefaultExcludes. So I guess this bug is about porting the dirScanner fix to Util.createFileSet(). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13165) Cloning workspace loses hidden files/directories
Antoine Musso commented on JENKINS-13165 Cloning workspace loses hidden files/directories I have opened JENKINS-14355 about the fingerprint plugin not being able to fingerprint ".git/FETCH_HEAD. I believe it is a similar issue as dirscanner fixed by https://github.com/jenkinsci/jenkins/commit/0725d2765da789e02914deb4893a449eeda6a820#L1R102 but with Util.createFileSet() this time. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14355) create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD)
Antoine Musso updated JENKINS-14355 create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD) Change By: Antoine Musso (12/Jul/12 1:41 PM) Labels: core This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14355) create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD)
Antoine Musso updated JENKINS-14355 create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD) Change By: Antoine Musso (12/Jul/12 1:42 PM) Component/s: core This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14355) create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD)
Antoine Musso commented on JENKINS-14355 create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD) Moved to core, the Fingerprinter plugin just call the Jenkins core API: Fingerprinter fingerprinter = new Fingerprinter(this.targets, false); return fingerprinter.perform(build, launcher, listener); This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14356) JIRA: no 'create-fingerprint-plugin' component
Antoine Musso resolved JENKINS-14356 as Fixed JIRA: no create-fingerprint-plugin component solved by imod via IRC. imod jenkins-admin: Create fingerprint in the issue tracker for hashar jenkins-admin Adding a new subcomponent fingerprint to the bug tracker, owned by hashar imod jenkins-admin: Make marcsanfacon the lead of fingerprint jenkins-admin Changing default assignee of subcomponent fingerprint to marcsanfacon Change By: Antoine Musso (11/Jul/12 7:49 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14355) create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD)
Antoine Musso assigned JENKINS-14355 to Marc Sanfacon create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD) Sending you this finger print plugin bug. Might be a core issue though. Change By: Antoine Musso (11/Jul/12 7:50 PM) Assignee: MarcSanfacon This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14356) JIRA: no 'create-fingerprint-plugin' component
Antoine Musso closed JENKINS-14356 as Fixed JIRA: no create-fingerprint-plugin component Change By: Antoine Musso (11/Jul/12 7:51 PM) Status: Resolved Closed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14355) create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD)
Antoine Musso created JENKINS-14355 create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD) Issue Type: Bug Assignee: Unassigned Components: core Created: 09/Jul/12 10:32 AM Description: Summary: The fingerprint plugin is no more able to take fingerprint of a "hidden" file such as .git/FETCH_HEAD. I am assuming it is an issue in Jenkins core, though the plugin might not have reflected a change to how files are detected in core. How to reproduce: Install the finger print plugin. Create a simple job. In the workspace directory create a directory '.git' (note the leading dot), create a FETCH_HEAD file in it with some random content. Add a build step 'fingerprint' files. In the field "Files to fingerprint" fill in '.git/FETCH_HEAD'. A red error message is shown: '.git/FETCH_HEAD' doesn't match anything: even '.git' doesn't exist The help message give a link to "the workspace", that file browser does show a .git directory containing a FETCH_HEAD file. Reason: I have a "child" job fetching several git repositories. I would like it to just fingerprints any FETCH_HEAD files (**/.git/FETCH_HEAD) to have a quick and fast way to track jobs dependencies. Misc informations: I am pretty sure it used to work in version 1.431 and was broken with 1.458. Still broken with 1.473. Environment: Jenkins 1.472 Project: Jenkins Labels: plugins Priority: Major Reporter: Antoine Musso This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14355) create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD)
Antoine Musso commented on JENKINS-14355 create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD) Note that Jira does not have a 'create-fingerprint-plugin' component to track the fingerprint plugin. Issue is https://issues.jenkins-ci.org/browse/JENKINS-14356 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14355) create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD)
Antoine Musso commented on JENKINS-14355 create-fingerprint-plugin cant find .dotfiles (e.g.: .git/FETCH_HEAD) Our bug report is https://bugzilla.wikimedia.org/show_bug.cgi?id=38260 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13446) Dependency graph points to localhost:8080
Antoine Musso
commented on JENKINS-13446
Dependency graph points to localhost:8080
Still there with Jenkins 1.472 and Dependency Graph 0.2.
Source code is on github at https://github.com/jenkinsci/depgraph-view-plugin
The culprit is
src/main/java/hudson/plugins/depgraph_view/DotStringGenerator.java which does
the following:
private String projectToNodeString(AbstractProject?, ? proj) {
return escapeString(proj.getFullDisplayName()) +
" [href=""]";
}
private String getEscapedProjectUrl(AbstractProject?, ? proj) {
return escapeString(Hudson.getInstance().getRootUrlFromRequest() +
proj.getUrl());
}
getRootUrlFromRequest is most probably getting the URL based on whatever HTTP
GET Jenkins received. In our setup, there is a proxy in front of Jenkins and
hence any requests are made to 127.0.0.1:8080.
The plugin need to instead use whatever "Jenkins URL" is configured.
Our Apache conf makes https://integration.mediawiki.org/ci to be proxied to http://localhost:8080/ci
ProxyPass /ci http://localhost:8080/ci
ProxyPassReverse/ci http://localhost:8080/ci
ProxyRequests Off
Proxy http://localhost:8080/ci*
Order deny,allow
Allow from all
/Proxy
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13446) Dependency graph points to localhost:8080
Antoine Musso updated JENKINS-13446 Dependency graph points to localhost:8080 .dot file on Wikimedia Jenkins installation. Generated with Jenkins 1.472 and depgraph-view 0.2. Change By: Antoine Musso (04/Jul/12 8:11 AM) Attachment: wmf-jenkins.dot This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
