[JIRA] (JENKINS-58138) Confusing saml plugin keystore breakage
Title: Message Title
Tomasz Śniatowski updated an issue
Jenkins / JENKINS-58138
Confusing saml plugin keystore breakage
Change By:
Tomasz Śniatowski
* Have authentication set up using SAML with no custom encryption options* Wait (?) (I suspect waiting a year for validity expiration is what triggers this)* Log in attempts break with a verbose backtrace on the login page{code}Stack traceorg.pac4j.core.exception.TechnicalException: Unsupported resource format: jar:file:/srv/jenkins/home/plugins/saml/WEB-INF/lib/saml.jar!/samlKeystore.jks. Use a relative or absolute path at org.pac4j.core.util.CommonHelper$1.getFilename(CommonHelper.java:373) at org.pac4j.saml.client.SAML2ClientConfiguration.getKeystorePath(SAML2ClientConfiguration.java:313) at org.pac4j.saml.crypto.KeyStoreCredentialProvider.(KeyStoreCredentialProvider.java:92) at org.pac4j.saml.client.SAML2Client.initCredentialProvider(SAML2Client.java:174) at org.pac4j.saml.client.SAML2Client.internalInit(SAML2Client.java:111) at org.pac4j.core.util.InitializableWebObject.init(InitializableWebObject.java:24) at org.jenkinsci.plugins.saml.OpenSAMLWrapper.createSAML2Client(OpenSAMLWrapper.java:145) at org.jenkinsci.plugins.saml.SamlRedirectActionWrapper.process(SamlRedirectActionWrapper.java:45) at org.jenkinsci.plugins.saml.SamlRedirectActionWrapper.process(SamlRedirectActionWrapper.java:30) at org.jenkinsci.plugins.saml.OpenSAMLWrapper.get(OpenSAMLWrapper.java:64) at org.jenkinsci.plugins.saml.SamlSecurityRealm.doCommenceLogin(SamlSecurityRealm.java:258) at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627) at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:396) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:408) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:212) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:145) at org.kohsuke.stapler.MetaClass$11.doDispatch(MetaClass.java:537) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:739){code}The call stack above is misleading. It appears to be caused by the "demo keystore" path (PAC4J_DEMO_KEYSTORE) being invalid in principle. The real issue is however that the plugin tries to use the demo key store in the first place, which is hinted at in a brief log line with no backtrace:{code}WARNING: Using bundled keystore : /srv/jenkins/home/saml-jenkins-keystore.jks (Permission denied)Jun 19, 2019 8:19:44 AM org.jenkinsci.plugins.saml.OpenSAMLWrapper createSAML2ClientWARNING: Using bundled keystore : resource:samlKeystore.jks{code}The configuration used no custom encryption settings, so whatever default key store the plugin wanted was used. Trying to disable and enable the saml authentication did not help, trying to use a custom key store in encryption settings an dreverting back to the default did not work.Looking at the code I realized it has code to create the key store from scratch if it doesn't exist and sure
[JIRA] (JENKINS-58138) Confusing saml plugin keystore breakage
Title: Message Title Tomasz Śniatowski created an issue Jenkins / JENKINS-58138 Confusing saml plugin keystore breakage Issue Type: Bug Assignee: Ivan Fernandez Calvo Components: saml-plugin Created: 2019-06-21 09:54 Priority: Minor Reporter: Tomasz Śniatowski Have authentication set up using SAML with no custom encryption options Wait (I suspect waiting a year for validity expiration is what triggers this) Log in attempts break with a verbose backtrace on the login page Stack trace org.pac4j.core.exception.TechnicalException: Unsupported resource format: jar:file:/srv/jenkins/home/plugins/saml/WEB-INF/lib/saml.jar!/samlKeystore.jks. Use a relative or absolute path at org.pac4j.core.util.CommonHelper$1.getFilename(CommonHelper.java:373) at org.pac4j.saml.client.SAML2ClientConfiguration.getKeystorePath(SAML2ClientConfiguration.java:313) at org.pac4j.saml.crypto.KeyStoreCredentialProvider.(KeyStoreCredentialProvider.java:92) at org.pac4j.saml.client.SAML2Client.initCredentialProvider(SAML2Client.java:174) at org.pac4j.saml.client.SAML2Client.internalInit(SAML2Client.java:111) at org.pac4j.core.util.InitializableWebObject.init(InitializableWebObject.java:24) at org.jenkinsci.plugins.saml.OpenSAMLWrapper.createSAML2Client(OpenSAMLWrapper.java:145) at org.jenkinsci.plugins.saml.SamlRedirectActionWrapper.process(SamlRedirectActionWrapper.java:45) at org.jenkinsci.plugins.saml.SamlRedirectActionWrapper.process(SamlRedirectActionWrapper.java:30) at org.jenkinsci.plugins.saml.OpenSAMLWrapper.get(OpenSAMLWrapper.java:64) at
[JIRA] (JENKINS-54116) Jenkins Jira Plugin - Unable to add version
Title: Message Title Tomasz Śniatowski commented on JENKINS-54116 Re: Jenkins Jira Plugin - Unable to add version Setting these to non-zero values seems to have helped in my case, but such manual action shouldn't be necessary. 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-54116) Jenkins Jira Plugin - Unable to add version
Title: Message Title Tomasz Śniatowski commented on JENKINS-54116 Re: Jenkins Jira Plugin - Unable to add version I started getting the same error on all builds on the changelog annotation step after upgrading to 3.0.3, I also found Read timeout and Thread Executor Size both set to zero in the config. It seems the defaults and/or migration is not done properly. 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-34256) Preparing Jenkins For Shutdown Hangs Running Pipelines
Title: Message Title Tomasz Śniatowski commented on JENKINS-34256 Re: Preparing Jenkins For Shutdown Hangs Running Pipelines So with pipelines, what is the recommended way of completely stopping a busy Jenkins instance for maintenance? The maintenance is in part due to a broken pipeline resume a'la JENKINS-50199, so I specifically don't want any additional half-done pipelines waiting to be resumed. I also would prefer to avoid having to abort jobs. In JENKINS-38316 there's an explicit mention that "prepare for shutdown" is not that: The whole idea of "Prepare for shutdown" is to [...] allow you to finish currently running freestyle (Maven, matrix, …) builds. So if you /safeRestart Jenkins will restart as soon as any of those are completed, and running Pipeline builds will be left alone. What should I do then? Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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-48258) git client plugin occasionally fails with "text file busy" error
Title: Message Title
Tomasz Śniatowski commented on JENKINS-48258
Re: git client plugin occasionally fails with "text file busy" error
We haven't seen the error since we implemented the local workaround, so that's over a month now. It looks like it has definitely helped. Unfortunately it's a shell wrapper and not really a usable patch:
$ which git
/usr/local/bin/git
$ cat /usr/local/bin/git
#!/bin/sh
# Wrapper to avoid "fatal: cannot exec '/tmp/aa': Text file busy" errors when
# git is called with GIT_SSH pointing to something that's still open for writing
# (see https://issues.jenkins-ci.org/browse/JENKINS-48258)
GIT_SSH_COPY=
if [ -n "$GIT_SSH" ]; then
GIT_SSH_COPY="$(mktemp "${GIT_SSH}.X")"
cp -a "$GIT_SSH" "$GIT_SSH_COPY"
GIT_SSH="$GIT_SSH_COPY"
fi
/usr/bin/git "$@"
RET=$?
if [ -n "$GIT_SSH_COPY" ]; then
rm -f "$GIT_SSH_COPY"
fi
exit $RET
I'm not quite sure how to solve this purely in Java in the git plugin code, as my tests indicate merely creating the file on the Java side introduces a race condition that can make this issue come back. A quick hacky workaround could make this go from a 0.1% issue to a 0.001% but still something that will occasionally break. Likely a more substantial change of approach on Linux is needed, to avoid the "write file then make GIT_SSH point to it" pattern altogether.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
[JIRA] (JENKINS-38339) UI for downstream jobs launched with 'build' step
Title: Message Title Tomasz Śniatowski commented on JENKINS-38339 Re: UI for downstream jobs launched with 'build' step We're trying to avoid UI issues when there are sub-steps in a parallel pipeline stage (JENKINS-38442) by triggering sub-builds instead – but as the UI has no links to these sub-builds the experience is not great either way. Any chance triggered build info could be a link? Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41885) Build log is scrolled down unconditionally on update
Title: Message Title Tomasz Śniatowski commented on JENKINS-41885 Re: Build log is scrolled down unconditionally on update Nice, thanks for the update! 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-41885) Build log is scrolled down unconditionally on update
Title: Message Title Tomasz Śniatowski commented on JENKINS-41885 Re: Build log is scrolled down unconditionally on update this makes in-progress builds frustrating to look at in blueocean, I think it could use a bump in priority. 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-33168) Junit plugin took 7 hours to complete recording test failures
Title: Message Title Tomasz Śniatowski commented on JENKINS-33168 Re: Junit plugin took 7 hours to complete recording test failures FWIW we worked around the issue by limiting the amount of history kept for the affected jobs (which is unfortunate as it limits the usefulness of the entire setup) 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-33168) Junit plugin took 7 hours to complete recording test failures
Title: Message Title Tomasz Śniatowski commented on JENKINS-33168 Re: Junit plugin took 7 hours to complete recording test failures The problem does not reliably reproduce when we take a "bad" output xml and try to process it with the junit plugin on an idle test instance of Jenkins. 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-33168) Junit plugin took 7 hours to complete recording test failures
Title: Message Title Tomasz Śniatowski commented on JENKINS-33168 Re: Junit plugin took 7 hours to complete recording test failures We're also seeing this problem on Jenkins ver. 2.7.2, junit plugin 1.18, Ubuntu 14.04 and it's causing a significant disruption because the slow parsing cannot be aborted. We're seeing threads in states like "Executor #0 for aa-01 : executing foo #141" Id=3787231 Group=main RUNNABLE at com.thoughtworks.xstream.converters.reflection.FieldDictionary.buildMap(FieldDictionary.java:122) - locked com.thoughtworks.xstream.converters.reflection.FieldDictionary@4e6649e2 at com.thoughtworks.xstream.converters.reflection.FieldDictionary.fieldOrNull(FieldDictionary.java:113) at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.getFieldOrNull(PureJavaReflectionProvider.java:194) at hudson.util.RobustReflectionConverter.fieldDefinedInClass(RobustReflectionConverter.java:347) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:284) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:229) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50) at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71) at hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85) at com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:80) at hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConverter.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66) at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:352) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:290) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:229) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50) at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71) at hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85) at com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:80) at hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConverter.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72) at
[JIRA] [monitoring-plugin] (JENKINS-31619) java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N
Title: Message Title Tomasz Śniatowski commented on JENKINS-31619 Re: java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N There are errors installing if the aforementioned directory is not writable so I doubt this change is effective. To reiterate: the problem appears when a non-default JENKINS_HOME is used, and the default $HOME/.jenkins/cache/jars does not exist / is not writable. 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] [monitoring-plugin] (JENKINS-31619) java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N
Title: Message Title Tomasz Śniatowski reopened an issue Jenkins / JENKINS-31619 java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N Change By: Tomasz Śniatowski Resolution: Cannot Reproduce Status: Resolved Reopened Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [monitoring-plugin] (JENKINS-31619) java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N (with a non-default JENKINS_HOME)
Title: Message Title Tomasz Śniatowski updated an issue Jenkins / JENKINS-31619 java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N (with a non-default JENKINS_HOME) Change By: Tomasz Śniatowski Summary: java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N ( with a non-default JENKINS_HOME ) 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] [monitoring-plugin] (JENKINS-31619) java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N with a non-default JENKINS_HOME
Title: Message Title Tomasz Śniatowski updated an issue Jenkins / JENKINS-31619 java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N with a non-default JENKINS_HOME Change By: Tomasz Śniatowski Summary: java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N with a non-default JENKINS_HOME 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] [monitoring-plugin] (JENKINS-31619) java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N
Title: Message Title Tomasz Śniatowski commented on JENKINS-31619 Re: java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N Aditya Joshi: Can you try creating empty writable directories so that $HOME/.jenkins/cache/jars exists during plugin installation? If that helps, I believe this bug shoud be reopened and renamed to "installing the monitoring plugin does not respect custom JENKINS_HOME when it comes to jar cache". 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-24842) Add progress to artifact archiver
Title: Message Title Tomasz Śniatowski commented on JENKINS-24842 Re: Add progress to artifact archiver Some sort of progress info would be very useful for diagnosing issues with network or storage speed that archiving large artifacts tends to expose. Any chance this gets picked up? 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-30092) node that is marked tempoarily offline is lost across restart
Title: Message Title Tomasz Śniatowski commented on JENKINS-30092 Re: node that is marked tempoarily offline is lost across restart I am also seeing this, offline status does not persist across reboots on Jenkins (tried 1.625.2, 1.631). This is a noticeable inconvenience when trying to do maintenance that involves making nodes offline. The workaround posted by Bertrand Latinville appears to help (thanks!) but it would be a lot nicer if this "just worked". 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] [monitoring-plugin] (JENKINS-31619) java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N
Title: Message Title Tomasz Śniatowski commented on JENKINS-31619 Re: java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N The issue persisted across reboots and plugin reinstalls. However during the reinstall I noticed it seems to be related to JENKINS_HOME/cache/jars. I have a non-default JENKINS_HOME and $HOME/.jenkins exists with 000 permissions. The install process tried to write jars to $HOME/.jenkins/cache/jars for some reason. After I allowed it, it created a bunch of jar files there and the missing class errors disappeared from the logs. I was unable to reproduce the issue on my test instance that runs a newer version (1.631) 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-29902) Unexpected executor death - java.lang.IllegalStateException: already existed
Title: Message Title Tomasz Śniatowski commented on JENKINS-29902 Re: Unexpected executor death - java.lang.IllegalStateException: already existed I managed to reproduce this on a test instance running Jenkins ver. Jenkins ver. 1.631: Create a freestyle project that takes a while to complete (execute shell: sleep 60) Schedule a build While it is building, schedule another so one is building (1) and one is queued (2) While the first job is still building, trigger 'reload configuration from disk' Wait for (1) to complete: OK Wait for (2) to complete: seems off: build completes, but is not visible in build list of the job Trigger another build: executor dies with an "2 already existed" error Reproduced 2/2 times for me and seems to match the logs I have from the "real" instance of the bug I hit. 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.
[JIRA] [core] (JENKINS-29902) Unexpected executor death - java.lang.IllegalStateException: already existed
Title: Message Title Tomasz Śniatowski commented on JENKINS-29902 Re: Unexpected executor death - java.lang.IllegalStateException: already existed I just saw this issue on Jenkins ver. 1.625.1 in several unrelated jobs. In my case it doesn't happen often, just the 5 or so threads that died yesterday. Only thing interesting was that I used "Reload Configuration from Disk" after mass-editing some job configurations and the first error happened soon after looking at the logs. 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] [monitoring-plugin] (JENKINS-31619) java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N
Title: Message Title Tomasz Śniatowski created an issue Jenkins / JENKINS-31619 java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N Issue Type: Bug Assignee: Unassigned Components: monitoring-plugin Created: 18/Nov/15 7:03 AM Environment: Jenkins ver. 1.625.1 Monitoring 1.57.0 Priority: Minor Reporter: Tomasz Śniatowski Nov 16, 2015 6:54:59 AM net.bull.javamelody.JavaLogger warn WARNING: exception while collecting data java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N at hudson.remoting.Channel$2.adapt(Channel.java:810) at hudson.remoting.Channel$2.adapt(Channel.java:805) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59) at net.bull.javamelody.RemoteCallHelper.collectDataByNodeName(RemoteCallHelper.java:169) at net.bull.javamelody.RemoteCallHelper.collectJavaInformationsListByName(RemoteCallHelper.java:179) at net.bull.javamelody.NodesCollector.collectWithoutErrorsNow(NodesCollector.java:154) at net.bull.javamelody.NodesCollector.collectWithoutErrors(NodesCollector.java:143) at net.bull.javamelody.NodesCollector$1.run(NodesCollector.java:87) at
[JIRA] [multiple-scms-plugin] (JENKINS-30243) NoClassDefFoundError during startup (Template Project plugin 1.5)
Title: Message Title Tomasz Śniatowski commented on JENKINS-30243 Re: NoClassDefFoundError during startup (Template Project plugin 1.5) I'm getting Nov 16, 2015 10:00:27 AM hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: h.getRelativeLinkTo(job) in /job/[foo]/configure. Reason: java.lang.NullPointerException java.lang.NullPointerException (no backtrace, any ideas on why I don't get a backtrace here?) quite often. I do have "Multiple SCMs" installed. Some of the jobs that trigger the error when entering their configuration screen do not use template-project, some do. What can I do? Should I file a separate bug? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [jobconfighistory-plugin] (JENKINS-24915) Extremely slow startup with template-project in combination with jobConfigHistory
Title: Message Title Tomasz Śniatowski commented on JENKINS-24915 Re: Extremely slow startup with template-project in combination with jobConfigHistory Seems the answer is "no". What now? 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] [conditional-buildstep-plugin] (JENKINS-30673) Plugin usage plugin does not count usages within a conditional build step
Title: Message Title Tomasz Śniatowski created an issue Jenkins / JENKINS-30673 Plugin usage plugin does not count usages within a conditional build step Issue Type: Bug Assignee: Dominik Bartholdi Components: conditional-buildstep-plugin, plugin-usage-plugin Created: 28/Sep/15 9:11 AM Priority: Minor Reporter: Tomasz Śniatowski 1. Install plugin usage plugin, conditional build step plugin, and a third plugin that can be used in the conditional step, for example 'fail the build' plugin 2. Set up a job that uses the third plugin in a conditional build step 3. Plugin Usage Plugin reports conditional-buildstep usage as 1 (OK) 4. Plugin Usage Plugin reports the third plugin usage as 0 (NOT OK) This is a false negative that can lead to people accidentally removing plugins that are in use. Add Comment
[JIRA] [jobconfighistory-plugin] (JENKINS-24915) Extremely slow startup with template-project in combination with jobConfigHistory
Title: Message Title Tomasz Śniatowski commented on JENKINS-24915 Re: Extremely slow startup with template-project in combination with jobConfigHistory We were mostly seeing startup delays severe enough that made maintenance almost impossible, and ended up disabling the job config history plugin... I don't think we care about report links in particular that much, but having publishers be more reliable in general is something we might be relying on without realizing. As it is though, the situation is pretty bad. It seems worse in practice than 500ms/job, we're seeing numbers more in line with the original report which stated 30 minutes for 1000 jobs, so almost 2s/job. 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] [jobconfighistory-plugin] (JENKINS-24915) Extremely slow startup with template-project in combination with jobConfigHistory
Title: Message Title Tomasz Śniatowski commented on JENKINS-24915 Re: Extremely slow startup with template-project in combination with jobConfigHistory Any updates? 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-27223) Clicking Login when you have 30+ slaves defaults you to the bottom of the web page
Title: Message Title Tomasz Śniatowski commented on JENKINS-27223 Re: Clicking Login when you have 30+ slaves defaults you to the bottom of the web page This problem also happens on some other pages, like /newJob. It is a common annoyance and I believe the priority should be raised. 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-27223) Clicking Login when you have 30+ slaves defaults you to the bottom of the web page
Title: Message Title
Tomasz Śniatowski commented on JENKINS-27223
Re: Clicking Login when you have 30+ slaves defaults you to the bottom of the web page
This problem appears to be triggered by any sidebar content that is tall enough, we're experiencing it without that many executors, but with the next executions widget taking up some vertical space. It is quite annoying, especially on failed logins where the user has to scroll up manually to see the error message.
The workaround by Christian Rasp helps, but I had to make sure it doesn't run too soon like so:
document.addEventListener(DOMContentLoaded, function() {
if(window.location.href.indexOf(/login) -1){
window.scrollTo(0, 0);
}
});
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-auth-plugin] (JENKINS-7103) Horizontal scrollbars on Configure page when using matrix-based security
Title: Message Title Tomasz Śniatowski commented on JENKINS-7103 Re: Horizontal scrollbars on Configure page when using matrix-based security Could someone merge the config.jelly change by Mark Lewis? Having an extra span element would allow CSS workarounds that are not possible now (there's a standing bug in Chrome that makes writing-mode not work on a td/th directly, see https://crbug.com/409155) 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] [view-job-filters-plugin] (JENKINS-22574) Hide/Disable the built-in filters
Title: Message Title Tomasz Śniatowski commented on JENKINS-22574 Re: Hide/Disable the built-in filters +1 on this. It would be great to be able to hide the default checkboxes, maybe just leave a note saying how many jobs are selected. BTW this request fits one of the version 1.x ideas listed on the plugin page at https://wiki.jenkins-ci.org/display/JENKINS/View+Job+Filters: These features are not entered as JIRA tickets because technically no one is requesting them. If you want one of these features, please Enter a JIRA Ticket and the feature will probably be added within a week. Retrofit existing filters to be default extensions (like the way columns work). Justifications are Allow for other views besides list view to more easily make use of them (for example, the status filter wasn't picked up by other views) Minor benefit is that if you have hundreds of jobs, your view edit screen is cluttered by the list of jobs when all you wanted was a regex or a status. So, you could delete any filters you don't want to see and they won't show up again. Another strategy to handle this might simply be a checkbox titled hide view list. However, this would obscure the fact that often a job is added to a view accidentally by clicking the new job link while on that view. 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] [view-job-filters-plugin] (JENKINS-22574) Hide/Disable the built-in filters
Title: Message Title
Tomasz Śniatowski edited a comment on JENKINS-22574
Re: Hide/Disable the built-in filters
+1onthis.Itwouldbegreattobeabletohidethedefaultcheckboxes,maybejustleaveanotesayinghowmanyjobsareselected.BTWthisrequestfitsoneoftheversion1.xideaslistedonthepluginpageathttps://wiki.jenkins-ci.org/display/JENKINS/View+Job+Filters:{quote}ThesefeaturesarenotenteredasJIRAticketsbecausetechnicallynooneisrequestingthem.Ifyouwantoneofthesefeatures,pleaseEnteraJIRATicketandthefeaturewillprobablybeaddedwithinaweek.Retrofitexistingfilterstobedefaultextensions(likethewaycolumnswork).JustificationsareAllowforotherviewsbesideslistviewtomoreeasilymakeuseofthem(forexample,thestatusfilterwasn'tpickedupbyotherviews)Minorbenefitisthatifyouhavehundredsofjobs,yourvieweditscreenisclutteredbythelistofjobswhenallyouwantedwasaregexorastatus.So,youcoulddeleteanyfiltersyoudon'twanttoseeandtheywon'tshowupagain.Anotherstrategytohandlethismightsimplybeacheckboxtitledhideviewlist.However,thiswouldobscurethefactthatoftenajobisaddedtoaviewaccidentallybyclickingthenewjoblinkwhileonthatview.{quote}
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups Jenkins Issues 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] [git-plugin] (JENKINS-9052) Git plugin needs a better error diagnosis when failing to check out
Title: Message Title Tomasz Śniatowski commented on JENKINS-9052 Re: Git plugin needs a better error diagnosis when failing to check out It is better now. I managed to do a quick test with a broken clone uri. Before: git -c core.askpass=true fetch --tags --progress localhost.host:/home/BROKEN +refs/heads/*:refs/remotes/origin/* ERROR: Error fetching remote repo 'origin' ERROR: Error fetching remote repo 'origin' On master with the above change there's an ugly backtrace, but at the errror message is there: ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from localhost:/home/BROKEN at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:737) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:984) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1015) at hudson.scm.SCM.checkout(SCM.java:484) at hudson.model.AbstractProject.checkout(AbstractProject.java:1270) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:374) Caused by: hudson.plugins.git.GitException: Command git -c core.askpass=true fetch --tags --progress localhost:/home/BROKEN +refs/heads/*:refs/remotes/origin/* returned status code 128: stdout: stderr: fatal: '/home/BROKEN' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) 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) at ..remote call to test-2(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1360) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:753) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at
[JIRA] [git-plugin] (JENKINS-27625) Git submodules, option for reseting local changes on submodules
Title: Message Title Tomasz Śniatowski commented on JENKINS-27625 Re: Git submodules, option for reseting local changes on submodules This problem is still present in current git plugin master (06415b9b9d3dd46d11a620b78ff56b19847c141a) 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] [git-plugin] (JENKINS-9052) Git plugin needs a better error diagnosis when failing to check out
Title: Message Title Tomasz Śniatowski commented on JENKINS-9052 Re: Git plugin needs a better error diagnosis when failing to check out I'll try testing that some time this week, currently occupied elsewhere and couldn't find the time. 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] [git-plugin] (JENKINS-9052) Git plugin needs a better error diagnosis when failing to check out
Title: Message Title Tomasz Śniatowski commented on JENKINS-9052 Re: Git plugin needs a better error diagnosis when failing to check out I believe this was resolved erroneously. The bug report was about the git plugin hiding error output, and the output Mark mentioned is only a log of all the commands issued – but if any of them fails, their stderr is still not logged. This sometimes makes debugging difficult, especially in the case of transient errors. It's not helpful at all, for example, if we have a single error 24h ago that fixed itself later, where all we get in the log is Error cloning remote repo 'origin' with no way to know if it was a timeout, authentication error or a broken workspace. Getting git's stderr into the log would be much better. I was about to report this as a new bug but found this instead. I can file it again if you prefer – but I think this one should be reopened. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-19939) Discard Old Builds I/O Performance Issue
Title: Message Title Tomasz Śniatowski commented on JENKINS-19939 Re: Discard Old Builds I/O Performance Issue Hi, thanks a lot for replying. Re 1: I personally do not find it a critical problem that something happens after a build status is determined, but before a next build can happen. It might be a bit confusing, but not the largest UI issue here from my POV. Re 2: This is my main gripe. If something bad happens and discarding takes a long time, there is no trace left anywhere. This makes it hard to analyse or report the problem. Re 3: I have no hard data (because without any logs it's difficult for me) but I do get a feeling that the discarding process is far more IO-heavy than it should be. It might worthwhile to mention something in the config section, but waiting for more data is probably fine too. Yesterday we had a transient IO performance issue in our Jenkins master disk hardware, and a job config change that ended up discarding some 20k builds (almost empty: no artifacts; 10 files and 40KB per build directory). This took over an hour, and I could see it deleting a couple build directories per second. Now whether this was solely caused by the hardware, or if discarding is otherwise sub-optimal (like syncing too much), is something I don't know – but shell IO at the time did not feel as bad. I have to admit though that without better data (like the actual time spent discarding, the time it took to just rm equivalent files, whether there was anything else going on, reproducibility, etc.) it's hard to tell. That's why I primarily just would like to have the logging. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit
[JIRA] [ldap-plugin] (JENKINS-28474) Confusing Chrome password manager behavior on ldap auth settings page
Title: Message Title Tomasz Śniatowski commented on JENKINS-28474 Re: Confusing Chrome password manager behavior on ldap auth settings page As per the above it seems that using autocomplete with a value other than off might work 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-19939) Discard Old Builds I/O Performance Issue
Title: Message Title Tomasz Śniatowski commented on JENKINS-19939 Re: Discard Old Builds I/O Performance Issue Hi, I'm hoping this bug can be revisited. We just spent an unpleasant amount of time trying to figure out why finished builds sometimes seem stuck on a spinner for a random amount of time, turns out it's often the discard old builds step. Some sort of info in the log info be very welcome. It's not very user friendly when jobs are stuck and it's not obvious what's going on. Some other plugins that do work after a build completes, such as Calculation of disk usage of workspace, do log the time they took. I think this plugin should do so as well. 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] [git-plugin] (JENKINS-27625) Git submodules, option for reseting local changes on submodules
Title: Message Title Tomasz Śniatowski commented on JENKINS-27625 Re: Git submodules, option for reseting local changes on submodules I believe this bug is more serious and could use more attention. Right now submodules behave differently from top-level repositories and builds can run with a broken or stale submodule checkout. It doesn't even take a misbehaving build step – if a build is aborted while checking out submodules, it will leave the submodule dirty. Subsequent builds in this workspace will then to not update the submodule at all, while not producing any useful diagnostics. This can be reproduced with a simple job restricted to one node, and a helper git repository with a submodule: # create submodule repository (mkdir sub cd sub git init echo subfile git commit -a -msub) # create outer repository (mkdir outer cd outer git init echo outerfile submodule add ../sub git commit -a -mouter) Configure a job to use the outer repository with git advanced behavior Recursively update submodules checked and the following execute shell build step: cat file cat sub/file # simulate modified workspace / aborted checkout rm file rm sub/file When the job is run the first time, the output is as expected; outer and sub. The second time outer is printed because the plugin issued a checkout -f, but the build fails because sub/file is still gone. There is no error message during the git step. This means currently it's very risky to use submodules with the git plugin unless workspaces or checkouts are force-cleaned: at best you'll sometimes get a build error, at worst – silent build corruption by using stale sources. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [ldap-plugin] (JENKINS-28474) Confusing Chrome password manager behavior on ldap auth settings page
Title: Message Title Tomasz Śniatowski created an issue Jenkins / JENKINS-28474 Confusing Chrome password manager behavior on ldap auth settings page Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: ldap-plugin Created: 19/May/15 10:07 AM Environment: Linux, Chrome 43 Jenkins 1.606 LDAP plugin 1.11 Priority: Minor Reporter: Tomasz Śniatowski With ldap plugin configured with no manager DN or password, visit configureSecurity with Chrome 43 that has Jenkins auth data remembered. Click Advanced on the LDAP settings and notice that Chrome has auto-filled the ldap Manager DN and Manager Password fields with the user's Jenkins login data. If the LDAP server requires these to be empty, loading configureSecurity and clicking save/apply, which should be a no-op, will break the configuration and the user might not realize what's going on. What most likely is going on is that Chrome is trying to be too helpful in detecting where a login / password field combination is. If I remove the stored Jenkins password from Chrome, it is not auto-filled, re-remembering it makes the problem return. As much as this could be regarded as a Chrome problem, it would be useful if the plugin did not trigger this behavior, especially as it happens on a hidden field. Note
[JIRA] [ldap-plugin] (JENKINS-28474) Confusing Chrome password manager behavior on ldap auth settings page
Title: Message Title Tomasz Śniatowski commented on JENKINS-28474 Re: Confusing Chrome password manager behavior on ldap auth settings page Not quite. It appears that a lot of this is working as intended which doesn't help. See for example: https://code.google.com/p/chromium/issues/detail?id=370363 https://code.google.com/p/chromium/issues/detail?id=352347 As per the above it could probably be worked around by using autocomplete=chromeplease but that's just ugly. Perhaps autocomplete=new-password as supported since https://code.google.com/p/chromium/issues/detail?id=375333 would be better. 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] [throttle-concurrent-builds-plugin] (JENKINS-27708) Concurrent build limits not honored on Jenkins 1.607
Tomasz Śniatowski commented on JENKINS-27708 Concurrent build limits not honored on Jenkins 1.607 Both appear to work for me. 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] [copy-project-link-plugin] (JENKINS-13517) CopyProjectLink plugin: does not work with jobs using 'display name' feature
Tomasz Śniatowski commented on JENKINS-13517 CopyProjectLink plugin: does not work with jobs using display name feature This is still a problem, can anyone take a look at the pull request? 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-27700) Node configuration missing after downgrading from 1.607 to 1.606
Tomasz Śniatowski created JENKINS-27700 Node configuration missing after downgrading from 1.607 to 1.606 Issue Type: Bug Assignee: Unassigned Components: core Created: 01/Apr/15 1:49 PM Description: It looks like 1.607 changed where node configuration is stored, it used to be in the main config.xml, now it's stored nodes/$NODE/. While the upgrade process works, downgrades don't merge the configurations back resulting in no nodes configured. This makes it difficult to investigate regressions across this version. Project: Jenkins Priority: Minor Reporter: Tomasz Śniatowski 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] [throttle-concurrent-builds-plugin] (JENKINS-27708) Concurrent build limits not honored on Jenkins 1.607
Tomasz Śniatowski created JENKINS-27708 Concurrent build limits not honored on Jenkins 1.607 Issue Type: Bug Assignee: Oleg Nenashev Components: throttle-concurrent-builds-plugin Created: 02/Apr/15 5:40 AM Description: After upgrading to 1.607 we noticed the throttle plugin doesn't always prevent jobs from running in parallel as expected. Steps to reproduce: 1. Create a throttle category with global limit 1, per-node limit 1. 2. Create 3 jobs using the category, restricted to a node with two executors, sleep 60 as a build step. 3. Request builds of all 3 jobs. What should happen: 4. Jobs run in sequence; 1 then 2 then 3. What actually happens: 5. Job 1 starts building, jobs 2 and 3 wait in queue (OK). 6. After job 1 finishes, both job 2 and 3 start running (not OK). Plugin version is 1.8.4. Issue does not appear in Jenkins 1.606 with the same version of the plugin. Issue is reproducible on a fresh install. We were forced to downgrade back to 1.606 as a workaround (which is unfortunately not trivial due to JENKINS-27700). Environment: Jenkins 1.607 Throttle concurrent builds plugin 1.8.4 Project: Jenkins Priority: Critical Reporter: Tomasz Śniatowski 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-27700) Node configuration missing after downgrading from 1.607 to 1.606
Tomasz Śniatowski commented on JENKINS-27700 Node configuration missing after downgrading from 1.607 to 1.606 I understand; and I was about to suggest that mentioning this in the changelog would be nice 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/d/optout.
