[JIRA] (JENKINS-14325) CCE ...cannot be cast to jenkins.model.Jenkins in job index page
jglick created JENKINS-14325 CCE ...cannot be cast to jenkins.model.Jenkins in job index page Issue Type: Bug Assignee: jglick Components: core Created: 05/Jul/12 4:22 PM Description: Noticed when using Folders plugin, but in principle could affect an installation using any plugin which has special ItemGroup implementations. ... hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: it.parent == app. Reason: java.lang.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) at org.apache.commons.jexl.parser.ASTEQNode.value(ASTEQNode.java:71) at org.apache.commons.jexl.parser.ASTExpression.value(ASTExpression.java:54) at org.apache.commons.jexl.parser.ASTExpressionExpression.value(ASTExpressionExpression.java:56) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) ... Caused by: java.lang.ClassCastException: an ItemGroup impl cannot be cast to jenkins.model.Jenkins at hudson.model.AbstractItem.getParent(AbstractItem.java) ... 91 more Apparent cause is the use of @WithBridgeMethods(value=Jenkins.class,castRequired=true) in AbstractItem.getParent. Probable mechanism of bug is that Job/index.jelly evaluates it.parent, JEXL looks for a getParent() method, and picks the overload returning Jenkins rather than the one returning ItemGroup. If the job is in fact in a folder rather than at top level, the cast (generated in bytecode by a Maven plugin) fails. Might happen to work on JDK 6 due to Class.getMethods returning methods in bytecode order, but this is not the case in JDK 7. Symptom: stack trace in log; probably suppresses "This project is currently disabled" message. "Major" only in that the error can be thrown repeatedly for a wide class of jobs. Environment: 1.424, JDK 7 Project: Jenkins Labels: exception Priority: Major Reporter: jglick 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-14325) CCE ...cannot be cast to jenkins.model.Jenkins in job index page
jglick commented on JENKINS-14325 CCE ...cannot be cast to jenkins.model.Jenkins in job index page Code as of a2b6a60. Complicated by fact that current Jelly will incorrectly suppress disable GUI for nested jobs - it is supposed to hide it for Maven modules and matrix configurations. 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-14325) CCE ...cannot be cast to jenkins.model.Jenkins in job index page
jglick started work on JENKINS-14325 CCE ...cannot be cast to jenkins.model.Jenkins in job index page Change By: jglick (05/Jul/12 4:37 PM) Status: Open InProgress 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-14325) CCE ...cannot be cast to jenkins.model.Jenkins in job index page
jglick updated JENKINS-14325 CCE ...cannot be cast to jenkins.model.Jenkins in job index page Change By: jglick (05/Jul/12 8:02 PM) URL: https://github.com/jenkinsci/jenkins/pull/515 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-14330) NPE from UnlabeldLoadStatistics.computeTotalExecutors
jglick created JENKINS-14330 NPE from UnlabeldLoadStatistics.computeTotalExecutors Issue Type: Bug Assignee: Unassigned Components: core Created: 05/Jul/12 10:52 PM Description: Saw several exceptions in console of the form: Jul 05, 2012 6:44:08 PM hudson.triggers.SafeTimerTask run SEVERE: Timer task hudson.model.LoadStatistics$LoadStatisticsUpdater@1d857b7 failed java.lang.NullPointerException at jenkins.model.UnlabeldLoadStatistics.computeTotalExecutors(UnlabeldLoadStatistics.java:61) at hudson.model.LoadStatistics.updateExecutorCounts(LoadStatistics.java:188) at hudson.model.LoadStatistics$LoadStatisticsUpdater.doRun(LoadStatistics.java:223) at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:54) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) Environment: 1.475 Project: Jenkins Priority: Minor Reporter: jglick 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-14330) NPE from UnlabeldLoadStatistics.computeTotalExecutors
jglick started work on JENKINS-14330 NPE from UnlabeldLoadStatistics.computeTotalExecutors Change By: jglick (05/Jul/12 10:57 PM) Status: Open InProgress 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-14330) NPE from UnlabeldLoadStatistics.computeTotalExecutors
jglick assigned JENKINS-14330 to jglick NPE from UnlabeldLoadStatistics.computeTotalExecutors Change By: jglick (05/Jul/12 10:57 PM) Assignee: jglick 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-14330) NPE from UnlabeldLoadStatistics.computeTotalExecutors
jglick updated JENKINS-14330 NPE from UnlabeldLoadStatistics.computeTotalExecutors Change By: jglick (05/Jul/12 11:28 PM) URL: https://github.com/jenkinsci/jenkins/pull/517 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-9711) variables are not resolved in Test report XMLs-path
jglick updated JENKINS-9711 variables are not resolved in Test report XMLs-path Change By: jglick (10/Jul/12 2:21 PM) URL: https://github.com/jenkinsci/jenkins/pull/501 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-14365) Wacky number for changes in build using multiscm/hg
jglick commented on JENKINS-14365 Wacky number for changes in build using multiscm/hg Odd. Probably a bug in multiple-scms. For example, http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/9339/changes shows changes 1-10 but the #9339 section of http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/changes shows 93, 94, 740, 741, 43638, 43639, 43640, 43641, 529, and 1! 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-14365) Wacky number for changes in build using multiscm/hg
jglick started work on JENKINS-14365 Wacky number for changes in build using multiscm/hg Change By: jglick (10/Jul/12 3:19 PM) Status: Open InProgress 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-14365) Wacky number for changes in build using multiscm/hg
jglick commented on JENKINS-14365 Wacky number for changes in build using multiscm/hg Visible at http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/changes for example: third item in build #9339 is displayed as "740. Performance: ..." because HTML has li value="0740d2a6bcb311de7531ef4c9f4e3838274b990f"Performance: ..." which is wrong. 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-14365) Wacky number for changes in build using multiscm/hg
jglick commented on JENKINS-14365 Wacky number for changes in build using multiscm/hg Trying to add cause in a comment, but failing so far... 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-14365) Wacky number for changes in build using multiscm/hg
jglick updated JENKINS-14365 Wacky number for changes in build using multiscm/hg li value="0740d2a6bcb311de7531ef4c9f4e3838274b990f" for example at http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/changes shows as item #740. 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-14365) Wacky number for changes in build using Mercurial plugin
jglick
updated JENKINS-14365
Wacky number for changes in build using Mercurial plugin
In fact reproducible without multiple-scms plugin, just on a plain job using Mercurial. The problem is in jenkins/core/src/main/resources/hudson/scm/SCM/project-changes.jelly which uses {{li value="${c.revision}"}} even though no getRevision method is defined in the core ChangeLogSet.Entry (MercurialChangeSet happens to define it without overriding).
Change By:
jglick
(10/Jul/12 3:47 PM)
Summary:
Wackynumberforchangesinbuildusing
multiscm/hg
Mercurialplugin
Priority:
Major
Minor
Component/s:
core
Component/s:
multiple-scms
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-11377) Changes view: show which repository a changeset is from
jglick commented on JENKINS-11377 Changes view: show which repository a changeset is from Parts of https://github.com/jenkinsci/multiple-scms-plugin/pull/1 were accepted, but not this; see discussion for reason. https://github.com/jglick/multiple-scms-plugin/tree/JENKINS-11377 holds my attempt. 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-14365) Wacky number for changes in build using Mercurial plugin
jglick
edited a comment on JENKINS-14365
Wacky number for changes in build using Mercurial plugin
In fact reproducible without multiple-scms plugin, just on a plain job using Mercurial. The problem is in jenkins/core/src/main/resources/hudson/scm/SCM/project-changes.jelly which uses li value="${c.revision}" even though no getRevision method is defined in the core ChangeLogSet.Entry (MercurialChangeSet happens to define it without overriding).
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-14365) Wacky number for changes in build using Mercurial plugin
jglick
commented on JENKINS-14365
Wacky number for changes in build using Mercurial plugin
To answer my own question: because SubversionChangeLogSet.LogEntry does define an public int getRevision() which is meaningful. Really it should have been the Subversion plugin which defined a custom project-changes.jelly with the special behavior of replacing list item numbers with Subversion revision numbers, a trick that of course is only meaningful for centralized SCMs which use integer revision numbers.
The various fix options are:
1. Remove value="${c.revision}" in core, override project-changes.jelly in the Subversion plugin, and eventually remove the project-changes.jelly override in the Git plugin (and anywhere else this might have been worked around) perhaps once the core fix makes it into an LTS release.
2. Work around in the Mercurial plugin the same way as in the Git plugin, basically compounding the error.
3. Change core to use getRevision only if it returns an Integer, rather than a String as the Git or Mercurial plugins would.
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-14365) Wacky number for changes in build using Mercurial plugin
jglick assigned JENKINS-14365 to jglick Wacky number for changes in build using Mercurial plugin Change By: jglick (10/Jul/12 4:15 PM) Assignee: KohsukeKawaguchi jglick 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-7363) Improve label choice to provide both dropdown (for simple) and textbox (for complex)
jglick resolved JENKINS-7363 as Fixed Improve label choice to provide both dropdown (for simple) and textbox (for complex) dty did this in 3f1f53f238cf894695b2e564f6fce18bcd030f5b in Nov 2010. Change By: jglick (10/Jul/12 7:18 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-7117) Quick Search should check content of jobs/*/config.xml
jglick commented on JENKINS-7117 Quick Search should check content of jobs/*/config.xml Does not appear possible currently. The "search" box is really a navigation tool. There is an extension point SearchFactory, but (1) implementing it cancels (rather than supplements) the standard implementation, (2) it is only called from SearchableModelObject.getSearch which itself does not seem to be called at all. 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-7117) Quick Search should check content of jobs/*/config.xml
jglick edited a comment on JENKINS-7117 Quick Search should check content of jobs/*/config.xml Does not appear possible currently. The "search" box is really a navigation tool. There is an extension point SearchFactory, but (1) implementing it cancels (rather than supplements) the standard implementation, (2) it is only called from SearchableModelObject.getSearch which itself does not seem to be called at all. Anyway Search has no instance fields, or apparent subtypes. 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-14388) Allow other emma-maven-plugins as precondition for Jenkins Emma Plugin
jglick commented on JENKINS-14388 Allow other emma-maven-plugins as precondition for Jenkins Emma Plugin Pull requests on https://github.com/jenkinsci/emma-plugin preferred to attaching patches, I think - easier to track and review. BTW your patch changes whitespace gratuitously. 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-14423) Declare direct deps on all Aether artifacts
jglick created JENKINS-14423 Declare direct deps on all Aether artifacts Issue Type: Bug Assignee: olamy Attachments: x.diff Components: maven Created: 13/Jul/12 2:13 PM Description: I have a project which declares a dependency on org.jenkins-ci.lib:lib-jenkins-maven-embedder. With 3.7 it worked fine. Changing the version to 3.9 makes it not work: NoClassDefFoundError on ConfigUtils, a newer aether-utils class. Turns out that aether-utils 1.11 was being used, via dep from maven-core 3.0.3, whereas 1.13 was really needed for use from aether-connector-wagon. lib-jenkins-maven-embedder declared the correct versions in dependencyManagement, but since this is a jar project, that only affected its own version of Aether, not that of projects depending on it. Suggested patch just makes these simple dependencies. Workaround from client of 3.9 is to explicitly request aether-spi and aether-util in 1.13, though there is still some problem with the version of AbstractHttpClientWagon I am trying to diagnose. Project: Jenkins Priority: Minor Reporter: jglick 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-14423) Declare direct deps on all Aether artifacts
jglick commented on JENKINS-14423 Declare direct deps on all Aether artifacts Client must also apparently depend on wagon-provider-api:org.apache.maven.wagon:2.2 to get AbstractWagon.getTimeout, though I am still unclear on why. 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-14423) Declare direct deps on all Aether artifacts
jglick commented on JENKINS-14423 Declare direct deps on all Aether artifacts The project does not explicitly depend on Aether; just calls MavenEmbedder.buildProjects. 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-14423) Declare direct deps on all Aether artifacts
jglick edited a comment on JENKINS-14423 Declare direct deps on all Aether artifacts Client must also apparently depend on org.apache.maven.wagon:wagon-provider-api:2.2 to get AbstractWagon.getTimeout, though I am still unclear on why. 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-14423) Declare direct deps on all Aether artifacts
jglick
commented on JENKINS-14423
Declare direct deps on all Aether artifacts
Thanks but I do not think I need a release; explicit deps from client project work fine for now. I would anyway first want to figure out what was going on with AbstractWagon.getTimeout - trying to use 2.1 (the default by transitivity) throws {{NoSuchMethodError}}s.
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-14423) Declare direct deps on all Aether artifacts
jglick edited a comment on JENKINS-14423 Declare direct deps on all Aether artifacts Thanks but I do not think I need a release; explicit deps from client project work fine for now. I would anyway first want to figure out what was going on with AbstractWagon.getTimeout - trying to use 2.1 (the default by transitivity) throws NoSuchMethodError. 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-14423) Declare direct deps on all Aether artifacts
jglick commented on JENKINS-14423 Declare direct deps on all Aether artifacts Oh, looks like you already updated wagonVersion in 3.10-SNAPSHOT, so the problem I had was probably limited to 3.9. 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-14410) Xvnc does not set DISPLAY variable
jglick commented on JENKINS-14410 Xvnc does not set DISPLAY variable Odd. Does the build log claim to be setting DISPLAY? 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-14402) Don't show up Invoke ANT Advanced value in Job Configuration
jglick resolved JENKINS-14402 as Duplicate Dont show up Invoke ANT Advanced value in Job Configuration Change By: jglick (13/Jul/12 3:51 PM) Status: Open Resolved Resolution: Duplicate 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-14435) No incremental display of progress within a line
jglick
created JENKINS-14435
No incremental display of progress within a line
Issue Type:
Bug
Assignee:
Unassigned
Components:
core
Created:
15/Jul/12 4:52 PM
Description:
The /console and /consoleText logs for a job using
hudson.tasks.Shell
commandset +x
echo -n Sleeping; for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20; do echo -n .; sleep 1; done; echo/command
/hudson.tasks.Shell
do not show progress until the very end, even though the log on disk gets updated every second.
Note that
@Test public void subLineProgress() throws Exception {
ByteBuffer buf = new ByteBuffer();
LargeText text = new LargeText(buf, false);
buf.write("Started.\n".getBytes());
StringWriter w = new StringWriter();
text.writeLogTo(0, w);
assertEquals("Started.\n", w.toString());
buf.write("Running...".getBytes());
w = new StringWriter();
text.writeLogTo(0, w);
assertEquals("Started.\nRunning...", w.toString());
buf.write("done.\n".getBytes());
w = new StringWriter();
text.writeLogTo(0, w);
assertEquals("Started.\nRunning...done.\n", w.toString());
}
fails, but according to the Javadoc this seems to be intentional. A fix would probably need a coordinated fix in Stapler, though AnnotatedLargeText may also contribute to the problem.
Environment:
Linux, JDK 7
Project:
Jenkins
Labels:
console
buffering
Priority:
Major
Reporter:
jglick
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-11362) Strange delay during a maven job build
jglick assigned JENKINS-11362 to jglick Strange delay during a maven job build Change By: jglick (17/Jul/12 8:12 PM) Assignee: kutzi jglick 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-11362) Strange delay during a maven job build
jglick resolved JENKINS-11362 as Wont Fix Strange delay during a maven job build Found http://jira.codehaus.org/browse/MNG-5312 as the root cause. The hudson.maven.PomInfo constructor calls MavenProject.getParent and this can be exceedingly slow. Options for Jenkins include Wait for a Maven release (3.0.5?) with the performance problem fixed. Bundle a patched version of maven-core with the plugin. Stop calling getParent from PomInfo, at least at the user's option. But this might cause Jenkins to be missing dependency information needed for build triggers: an update to a parent POM (other than the relativePath default of ../pom.xml) would not be "noticed" by modules using it. Provisionally going with option #1, hence closing this issue since we would anyway bundle any new Maven release with the plugin when it becomes available. But I could work on #2 or #3 instead if anyone thinks it would be a good idea. Unclear if many users are affected by this issue; the impact is on projects using lots of scopeimport/scope. Change By: jglick (17/Jul/12 8:35 PM) Status: Open Resolved Resolution: WontFix 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-14443) Build is broken out of the box
jglick updated JENKINS-14443 Build is broken out of the box John Hsing on jenkins-dev also running into trouble; bumping priority. (Assignee is on vacation, so perhaps another maintainer wants to apply this fix?) Change By: jglick (17/Jul/12 9:37 PM) Priority: Minor Major 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-14492) IAE Illegal character(s) in message header value from com.saucelabs.rest.Credential.call
jglick
created JENKINS-14492
IAE Illegal character(s) in message header value from com.saucelabs.rest.Credential.call
Issue Type:
Bug
Assignee:
Kohsuke Kawaguchi
Components:
sauce-ondemand
Created:
18/Jul/12 8:08 PM
Description:
A user reports getting an error message when attempting to use the Test Connection button. The meat of the exception is
java.lang.IllegalArgumentException: Illegal character(s) in message header value: Basic someLongBase64EncodedMessHereEtcEtcEtcEtcEtcEtcEtcEtcEtcEtcEtcEtcEtcAndAnEOL
sun.net.www.protocol.http.HttpURLConnection.checkMessageHeader(HttpURLConnection.java:428)
sun.net.www.protocol.http.HttpURLConnection.isExternalMessageHeaderAllowed(HttpURLConnection.java:394)
sun.net.www.protocol.http.HttpURLConnection.setRequestProperty(HttpURLConnection.java:2374)
sun.net.www.protocol.https.HttpsURLConnectionImpl.setRequestProperty(HttpsURLConnectionImpl.java:296)
com.saucelabs.rest.Credential.call(Credential.java:167)
com.saucelabs.rest.Credential.call(Credential.java:151)
com.saucelabs.rest.SauceTunnelFactory.list(SauceTunnelFactory.java:88)
hudson.plugins.sauce_ondemand.PluginImpl$DescriptorImpl.doValidate(PluginImpl.java:137)
Note that HttpURLConnection is complaining rightly that the authentication string contains a newline. Credential.call has
String userpassword = username + ":" + key;
con.setRequestProperty("Authorization", "Basic " + new BASE64Encoder().encode(userpassword.getBytes()));
You can see that this will fail in some cases:
public class Demo {
public static void main(String... args) {
System.out.println("got: '" + new sun.misc.BASE64Encoder().encode(new String("someusername:apiKeyEtc01234567890123456789012345678901234").getBytes()) + "'");
}
}
produces
got: 'c29tZXVzZXJuYW1lOmFwaUtleUV0YzAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0
'
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947917 discusses a similar bug in the JRE, and suggests the workaround:
public class Demo {
public static void main(String... args) {
System.out.println("got: '" + new sun.misc.BASE64Encoder() {
@Override protected int bytesPerLine() {
return ;
}
}.encode(new String("someusername:apiKeyEtc01234567890123456789012345678901234").getBytes()) + "'");
}
}
producing
got: 'c29tZXVzZXJuYW1lOmFwaUtleUV0YzAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0'
By the way https://github.com/infradna/saucerest-java/ seems to be the source of the REST API, but this appears long out of date whereas https://github.com/saucelabs/saucerest-java/ looks to be the authoritative library (which however still appears to suffer from this same bug, at least according to an inspection of sources).
Environment:
1.14
Project:
Jenkins
Priority:
Major
Reporter:
jglick
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-14492) IAE Illegal character(s) in message header value from com.saucelabs.rest.Credential.call
jglick assigned JENKINS-14492 to Ross Rowe IAE Illegal character(s) in message header value from com.saucelabs.rest.Credential.call Change By: jglick (18/Jul/12 8:16 PM) Assignee: KohsukeKawaguchi RossRowe 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-5949) Trim JUnit stack traces logs to reasonable length before mailing
jglick commented on JENKINS-5949 Trim JUnit stack traces logs to reasonable length before mailing That does not help if you have just one or two failed tests but each has a huge volume of log output. 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-14507) NPE from JUnitParser.parse
jglick created JENKINS-14507 NPE from JUnitParser.parse Issue Type: Bug Assignee: Unassigned Components: junit Created: 19/Jul/12 5:57 PM Description: Found in a user's log: [date] hudson.model.AbstractBuild$AbstractRunner performAllBuildSteps WARNING: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception java.lang.NullPointerException at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:83) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:122) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:134) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:697) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:672) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:650) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:619) at hudson.model.Run.run(Run.java:1429) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) No clue what the underlying cause is, but this can be handled better than with an NPE. Environment: 1.447 Project: Jenkins Priority: Minor Reporter: jglick 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-14443) Build is broken out of the box
jglick assigned JENKINS-14443 to jglick Build is broken out of the box Change By: jglick (20/Jul/12 11:46 AM) Assignee: NicolasDeLoof jglick 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-14538) Separate configure tools page
jglick commented on JENKINS-14538 Separate configure tools page I committed a different UI to the branch, a much less disruptive change from the current UI: all tools still shown in /configure, but collapsed by default, with Advanced-style buttons labeled e.g. "Ant installations...". Working except for button alignment which is gratuitously indented. 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-14538) Separate configure tools page
jglick started work on JENKINS-14538 Separate configure tools page Change By: jglick (24/Jul/12 3:14 PM) Status: Open InProgress 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-14538) Separate configure tools page
jglick
updated JENKINS-14538
Separate configure tools page
Change By:
jglick
(24/Jul/12 3:37 PM)
Description:
CurrentlyifyouwanttomanagetoolinstallationsinaJenkinsinstance,youjustgotothemaster{{/configure}}page.Unfortunatelythiscangetoutofhand:whentherearealotoftoolsalready(suchastwentydot-dotJDKreleases),regularJenkinsconfigurationcangetlostinthemess.The{{configureTools}}branch(seeURL)proposestosplittoolinstallationsoffintotheirownconfigurationpageforcomfort.Openissues:#Alltoolsareshownonasinglepage,thoughitmayalsobefeasibletoproduceonepagepertooltype(Ant,Maven,JDK,...);oronepagewithtabs,iftherewereaclearmeaningforSaveandApplyinthatcase.#Themanagementlinkusesthesame{{setting.png}}asthemain{{/configure}}page;probablyneedsitsownicon.#TBDwhetherotherbitsofconfigurationbelonginthenewlocation,notably{{ToolLocationNodeProperty}}and{{Shell.DescriptorImpl}}-shouldtherebeawayofindicatingthatagiven{{Descriptor}}wouldliketobe
renderer
rendered
onanalternateconfigpage?
URL:
https://github.com/jenkinsci/jenkins/
compare
commit
/
master...configureTools
468c5210355d41020ba168cfe45e2b4ef128ccc1
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-14492) IAE Illegal character(s) in message header value from com.saucelabs.rest.Credential.call
jglick closed JENKINS-14492 as Fixed IAE Illegal character(s) in message header value from com.saucelabs.rest.Credential.call User says the 1.18 plugin is working as expected. Thanks! Change By: jglick (24/Jul/12 5:50 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-14393) Jenkins CLI is not giving enough information to builds that it kicks off
jglick resolved JENKINS-14393 as Fixed Jenkins CLI is not giving enough information to builds that it kicks off BTW include the text FIXED JENKINS-14393 in one of your commits to ensure that JIRA gets updated when the fix is pushed. Change By: jglick (24/Jul/12 8:02 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-13774) Provide option for cloning all branches with Mercurial SCM
jglick commented on JENKINS-13774 Provide option for cloning all branches with Mercurial SCM Are you sure you do not want to use the Multiple SCMs Plugin for this use case? 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-14487) Allow parameterization of whether to use Xvnc for a build
jglick commented on JENKINS-14487 Allow parameterization of whether to use Xvnc for a build Pull requests welcome. 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-7501) POST'ing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc)
jglick commented on JENKINS-7501 POSTing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc) I suspect the use of javax.xml.transform.Transformer is to blame; this has been there since the POST support was added in 2008 (eabb943). 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-7501) POST'ing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc)
jglick commented on JENKINS-7501 POSTing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc) Confirmed that this is broken in Jenkins dev for both creating and modifying jobs, though they seem to use different code paths: curl -d @config.xml -H 'Content-Type: text/xml' 'http://localhost:8080/createItem?name=new' curl -d @config.xml http://localhost:8080/job/existing/config.xml 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-7501) POST'ing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc)
jglick edited a comment on JENKINS-7501 POSTing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc) Confirmed that this is broken in Jenkins dev for both creating and modifying jobs, though they seem to use different code paths: curl -d @config.xml -H 'Content-Type: text/xml' 'http://localhost:8080/createItem?name=new' curl -d @config.xml http://localhost:8080/job/existing/config.xml 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-7501) POST'ing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc)
jglick resolved JENKINS-7501 as Not A Defect POSTing a config.xml to create a new job via the XML API results in newlines being removed from XML elements containing them (ant build steps, winbatch steps, etc) In fact Jenkins is working fine. The problem is in your script: you need to use -data-binary rather than -data. Change By: jglick (25/Jul/12 1:11 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
[JIRA] (JENKINS-14616) Corrupted plugin updates leads to plugin uninstall and lost job configuration
jglick commented on JENKINS-14616 Corrupted plugin updates leads to plugin uninstall and lost job configuration More: https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-dev/ueaAOGrtVDI 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-14381) Html publish plugin doesn't show any fields in Jenkins 1.474
jglick resolved JENKINS-14381 as Duplicate Html publish plugin doesnt show any fields in Jenkins 1.474 Change By: jglick (30/Jul/12 4:42 PM) Status: Open Resolved Resolution: Duplicate 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-14514) Repeatable jelly tag appears to be broken in 1.474+
jglick started work on JENKINS-14514 Repeatable jelly tag appears to be broken in 1.474+ Change By: jglick (30/Jul/12 4:44 PM) Status: Open InProgress 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-14514) Repeatable jelly tag appears to be broken in 1.474+
jglick commented on JENKINS-14514 Repeatable jelly tag appears to be broken in 1.474+ Confirmed that https://github.com/jenkinsci/jenkins/commit/96442cd9cd7b432a19d05dd945502a854541cae7 introduced 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
[JIRA] (JENKINS-14514) Repeatable jelly tag appears to be broken in 1.474+
jglick updated JENKINS-14514 Repeatable jelly tag appears to be broken in 1.474+ Change By: jglick (30/Jul/12 4:44 PM) Component/s: htmlpublisher Component/s: gui 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-14472) Columns cannot be deleted from configure view page
jglick resolved JENKINS-14472 as Duplicate Columns cannot be deleted from configure view page Change By: jglick (30/Jul/12 10:51 PM) Status: Open Resolved Resolution: Duplicate 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-14434) Delete buttons in view configuration not working
jglick assigned JENKINS-14434 to jglick Delete buttons in view configuration not working Change By: jglick (30/Jul/12 10:55 PM) Assignee: jglick 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-14434) Delete buttons in view configuration not working
jglick started work on JENKINS-14434 Delete buttons in view configuration not working Change By: jglick (30/Jul/12 10:55 PM) Status: Open InProgress 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-14505) Delete button broken (and many more)
jglick resolved JENKINS-14505 as Duplicate Delete button broken (and many more) Change By: jglick (30/Jul/12 10:54 PM) Status: Open Resolved Resolution: Duplicate 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-11739) Mysterious FilerException: Attempt to reopen a file for path ...
jglick assigned JENKINS-11739 to jglick Mysterious FilerException: Attempt to reopen a file for path ... Change By: jglick (01/Aug/12 10:07 PM) Assignee: KohsukeKawaguchi jglick 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-11739) Mysterious FilerException: Attempt to reopen a file for path ...
jglick commented on JENKINS-11739 Mysterious FilerException: Attempt to reopen a file for path ... Same happens (but with no workaround) in 1.466.1 when processing Plugin declarations, just running javac (i.e. APT is not to blame): at com.sun.tools.javac.processing.JavacFiler.checkFileReopening(JavacFiler.java:535) at com.sun.tools.javac.processing.JavacFiler.createResource(JavacFiler.java:431) at jenkins.PluginSubtypeMarker.write(PluginSubtypeMarker.java:99) at jenkins.PluginSubtypeMarker.access$100(PluginSubtypeMarker.java:60) at jenkins.PluginSubtypeMarker$1.visitType(PluginSubtypeMarker.java:71) at jenkins.PluginSubtypeMarker$1.visitType(PluginSubtypeMarker.java:64) at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:892) at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:141) at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:131) at javax.lang.model.util.ElementScanner6.visitPackage(ElementScanner6.java:160) at com.sun.tools.javac.code.Symbol$PackageSymbol.accept(Symbol.java:692) at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:141) at jenkins.PluginSubtypeMarker.process(PluginSubtypeMarker.java:85) 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-11739) Mysterious FilerException: Attempt to reopen a file for path ...
jglick commented on JENKINS-11739 Mysterious FilerException: Attempt to reopen a file for path ... The processor is not really written correctly; the right way to write processors which generate an index is to read the existing file, if any, queue up writes while !processingOver, then when processingOver perform them (unless errorRaised). org.openide.util.lookup.implspi.AbstractServiceProviderProcessor is an example. But the immediate bug is triggered, as Stephen found, by package-info.java since you are incorrectly scanning package elements. 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-11739) Mysterious FilerException: Attempt to reopen a file for path ...
jglick assigned JENKINS-11739 to Kohsuke Kawaguchi Mysterious FilerException: Attempt to reopen a file for path ... Final fix is in Stapler, but I did not manage to release it. Change By: jglick (02/Aug/12 1:52 AM) Assignee: jglick KohsukeKawaguchi 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-14672) deleteAllDisabledModules produced with incorrect basedir
jglick created JENKINS-14672 deleteAllDisabledModules produced with incorrect basedir Issue Type: Bug Assignee: Unassigned Components: maven Created: 02/Aug/12 8:45 PM Description: I have a sample Maven job configured. From /job/mercurial-plugin/ there is a link /job/mercurial-plugin/deleteAllDisabledModules which works (whatever it does). But if I first click on the "Workspace" link, and then click on "Delete All Disabled Modules", I am taken to /job/mercurial-plugin/ws/deleteAllDisabledModules which is a 404. (Similarly for other actions which have a basedir, e.g. /job/mercurial-plugin/move/deleteAllDisabledModules when using the Folders plugin.) Seems like MavenModuleSet/actions.jelly is failing to set a proper base URL. Environment: 1.466.1 Project: Jenkins Priority: Minor Reporter: jglick 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-7782) Excessive logging causes the Hudson log to flood and memory to leak
jglick resolved JENKINS-7782 as Fixed Excessive logging causes the Hudson log to flood and memory to leak recampbell seems to have fixed this in 1a0a6b2b5fd5d71fba43ef4fdfb6836ed087abd7. Change By: jglick (02/Aug/12 3:47 PM) Status: Open Resolved Assignee: shinodkm recampbell 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-14669) downstream-buildview incompatible with folders
jglick created JENKINS-14669 downstream-buildview incompatible with folders Issue Type: Bug Assignee: jglick Components: downstream-buildview Created: 02/Aug/12 3:43 PM Description: User of this plugin in combination with CloudBees Folders Plugin reports exceptions such as java.lang.NullPointerException at org.jvnet.hudson.plugins.DownstreamBuildViewUpdateListener.onStarted(DownstreamBuildViewUpdateListener.java:85) at org.jvnet.hudson.plugins.DownstreamBuildViewUpdateListener.onStarted(DownstreamBuildViewUpdateListener.java:46) at hudson.model.listeners.RunListeners.fireStarted(RunListener.java:188) at hudson.model.Run.run(Run.java:1371) at hudson.ivy.IvyModuleSetBuild.run(IvyModuleSetBuild.java:282) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:175) Also observed: java.lang.NullPointerException at org.jvnet.hudson.plugins.DownstreamBuildViewAction.findDownstream(DownstreamBuildViewAction.java:66) at org.jvnet.hudson.plugins.DownstreamBuildViewAction.getDownstreamBuildList(DownstreamBuildViewAction.java:221) (JENKINS-14325 also observed, but this is unrelated to the downstream-buildview plugin.) Project: Jenkins Labels: exception folders Priority: Major Reporter: jglick 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-14669) downstream-buildview incompatible with folders
jglick started work on JENKINS-14669 downstream-buildview incompatible with folders Change By: jglick (02/Aug/12 4:09 PM) Status: Open InProgress 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-14514) Repeatable jelly tag appears to be broken in 1.474+
jglick commented on JENKINS-14514 Repeatable jelly tag appears to be broken in 1.474+ @Brian: not really sure what is in 1.476; http://jenkins-ci.org/changelog does not list it, and there is no tag for it! I think I specifically tested the HTML Publisher plugin against this change, but if you still see the bug when running against master (currently 1.477-SNAPSHOT) please reopen JENKINS-14381. 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-14495) Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder
jglick commented on JENKINS-14495 Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder I think you are getting at the crux of the problem when you find that there are duplicates in registered behaviors. My fix of JENKINS-14514 was just a blind workaround for that, and it seems like pull #533 is very similar. My guess is that splitting _javascript_ into separate files resulted in behavior registration being run repeatedly from the same st:adjunct/, and apparently this was not idempotent. Will look deeper. 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-14495) Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder
jglick started work on JENKINS-14495 Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder Change By: jglick (03/Aug/12 2:30 PM) Status: Open InProgress 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-14679) Mercurial cache is not used
jglick assigned JENKINS-14679 to jglick Mercurial cache is not used Change By: jglick (03/Aug/12 3:32 PM) Assignee: KohsukeKawaguchi jglick 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-14478) 1.474 breaks adding a list-view to sectioned-view plugin
jglick resolved JENKINS-14478 as Duplicate 1.474 breaks adding a list-view to sectioned-view plugin Change By: jglick (03/Aug/12 4:58 PM) Status: Open Resolved Resolution: Duplicate 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-14495) Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder
jglick resolved JENKINS-14495 as Fixed Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder Change By: jglick (03/Aug/12 5:00 PM) Status: InProgress 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-14632) Hetero lists broken in Jenkins 1.455+ by introduction of resource adjuncts
jglick assigned JENKINS-14632 to Kohsuke Kawaguchi Hetero lists broken in Jenkins 1.455+ by introduction of resource adjuncts Change By: jglick (03/Aug/12 5:00 PM) Assignee: KohsukeKawaguchi 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-14495) Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder
jglick commented on JENKINS-14495 Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder Looks like my change caused a couple of test failures, investigating... 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-14107) Unable to monitor external job in 1.470 (IllegalAccessError)
jglick assigned JENKINS-14107 to jglick Unable to monitor external job in 1.470 (IllegalAccessError) Change By: jglick (06/Aug/12 11:15 PM) Assignee: jglick 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-14107) Unable to monitor external job in 1.470 (IllegalAccessError)
jglick started work on JENKINS-14107 Unable to monitor external job in 1.470 (IllegalAccessError) Change By: jglick (06/Aug/12 11:16 PM) Status: Open InProgress 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-14709) Replace org.jenkins-ci:trilead-ssh2 with Orion SSH2
jglick updated JENKINS-14709 Replace org.jenkins-ci:trilead-ssh2 with Orion SSH2 Change By: jglick (07/Aug/12 1:25 PM) Issue Type: Bug Task 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-14709) Replace org.jenkins-ci:trilead-ssh2 with Orion SSH2
jglick created JENKINS-14709 Replace org.jenkins-ci:trilead-ssh2 with Orion SSH2 Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: cli, core Created: 07/Aug/12 1:24 PM Description: The patches in https://github.com/jenkinsci/trilead-ssh2 seems to have been merged into the trunk of https://sourceforge.net/apps/mediawiki/orion-ssh2/ so we need an Orion 215 release to be published in Maven Central and replace our custom fork. Project: Jenkins Priority: Major Reporter: jglick 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-13774) Provide option for cloning all branches with Mercurial SCM
jglick commented on JENKINS-13774 Provide option for cloning all branches with Mercurial SCM Dave's reported case sounds a lot like the caching feature built in to the plugin, which would not require a special job or Copy Artifact - you just configure your Hg installation to use caching, and then any job using a given public repo location will automatically share the cache (and slaves do not need to make the remote connection). If you are trying to do something more subtle, such as archiving particular snapshots of the repository, then I guess a freeform build step with hg clone -U would be suitable, but I am not sure what trigger to use; the Mercurial plugin is designed to maintain a checkout of a particular branch and poll for changes in it, which is a quite different use case. You would really want a custom build trigger which just looked for activity of any kind in a given repo. Henrik's case is different and probably suited to Multiple SCMs - place a checkout of each named branch in its own subdirectory of the workspace. Each branch will be polled for changes. That ought to work fine with the current Mercurial plugin unless I am missing something. 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-14749) Errors in style.css
jglick created JENKINS-14749 Errors in style.css Issue Type: Bug Assignee: Unassigned Components: core Created: 09/Aug/12 1:29 PM Description: war/src/main/webapp/css/style.css has various CSS errors as reported by HtmlUnit, such as filter: alpha(opacity=40); /* msie */ -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)"; These clutter log output when running HudsonTestCase/JenkinsRule tests, and might confuse standards-compliant browsers. Perhaps better to split browser-specific hacks into separate CSS files inserted only when the client identifies itself as that browser. Project: Jenkins Labels: css Priority: Minor Reporter: jglick 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-14759) Job created by posting config.xml to /createItem does not set GitHub webhook
jglick updated JENKINS-14759 Job created by posting config.xml to /createItem does not set GitHub webhook Change By: jglick (10/Aug/12 12:22 PM) Summary: Jobcreatedbypostingconfig.xmlto/ creatIemdontgetwebhook createItemdoesnot set ongithub GitHubwebhook 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-14759) Job created by posting config.xml to /createItem does not set GitHub webhook
jglick updated JENKINS-14759 Job created by posting config.xml to /createItem does not set GitHub webhook Change By: jglick (10/Aug/12 12:23 PM) Component/s: github 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-14813) 404 when canceling queue item that has already gone to an executor
jglick created JENKINS-14813 404 when canceling queue item that has already gone to an executor Issue Type: Bug Assignee: Unassigned Components: core Created: 15/Aug/12 5:55 PM Description: 1.479-SNAPSHOT. Set system quiet period to two seconds. Click Build Now next to a job, and when the queue item appears, click the red X next to it to cancel. Sometimes you will be shown http://localhost:8080/queue/item/21/cancelQueue as an error page: 404 Not Found Stapler processed this HTTP request as follows, but couldn't find the resource to consume the request - evaluate(hudson.model.Hudson@75cdd3 :hudson.model.Hudson,"/queue/item/21/cancelQueue") - evaluate(((StaplerProxy)hudson.model.Hudson@75cdd3).getTarget(),"/queue/item/21/cancelQueue") - evaluate(hudson.model.Hudson@75cdd3.getQueue(),"/item/21/cancelQueue") - evaluate(hudson.model.Queue@1f1f1f2 :hudson.model.Queue,"/item/21/cancelQueue") - evaluate(hudson.model.Queue@1f1f1f2.getItem(21),"/cancelQueue") - unexpected null! If this 404 is unexpected, double check the last part of the trace to see if it should have evaluated to null. Presumably item #21 had already been sent to an executor, but the AJAX code to refresh the queue executor list had not yet gotten a chance to run. Fine, but Jenkins should recover more gracefully than this - just redirect to the calling page and ignore the request. Project: Jenkins Labels: 404 queue Priority: Minor Reporter: jglick 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-14813) 404 when canceling queue item that has already gone to an executor
jglick assigned JENKINS-14813 to jglick 404 when canceling queue item that has already gone to an executor Change By: jglick (15/Aug/12 5:59 PM) Assignee: jglick 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-14814) Ping-pong builds store excessively large CauseAction
jglick created JENKINS-14814 Ping-pong builds store excessively large CauseAction Issue Type: Bug Assignee: jglick Components: core Created: 15/Aug/12 6:05 PM Description: Create two jobs, a and b, each of which does nothing but trigger the other. (Useless by itself, but a similar idiom can be used to alternate indefinitely between two actions, such as checking for changes in some part of the environment and reacting to those changes.) Let this run for a few dozen iterations. The build.xml file for each build can soon run into multiple megabytes. For example, on just the fourth cycle, a/builds/4/build.xml has this lengthy "cause" section: hudson.model.CauseAction causes hudson.model.Cause_-UpstreamCause upstreamProjectb/upstreamProject upstreamUrljob/b//upstreamUrl upstreamBuild3/upstreamBuild upstreamCauses hudson.model.Cause_-UpstreamCause upstreamProjecta/upstreamProject upstreamUrljob/a//upstreamUrl upstreamBuild3/upstreamBuild upstreamCauses hudson.model.Cause_-UpstreamCause upstreamProjectb/upstreamProject upstreamUrljob/b//upstreamUrl upstreamBuild2/upstreamBuild upstreamCauses hudson.model.Cause_-UpstreamCause upstreamProjecta/upstreamProject upstreamUrljob/a//upstreamUrl upstreamBuild2/upstreamBuild upstreamCauses hudson.model.Cause_-UpstreamCause upstreamProjectb/upstreamProject upstreamUrljob/b//upstreamUrl upstreamBuild1/upstreamBuild upstreamCauses hudson.model.Cause_-UpstreamCause upstreamProjecta/upstreamProject upstreamUrljob/a//upstreamUrl upstreamBuild1/upstreamBuild upstreamCauses hudson.model.Cause_-UserIdCause/ /upstreamCauses /hudson.model.Cause_-UpstreamCause /upstreamCauses /hudson.model.Cause_-UpstreamCause /upstreamCauses /hudson.model.Cause_-UpstreamCause /upstreamCauses /hudson.model.Cause_-UpstreamCause /upstreamCauses /hudson.model.Cause_-UpstreamCause /upstreamCauses /hudson.model.Cause_-UpstreamCause /causes /hudson.model.CauseAction Excessive disk usage consumption is not the only problem; Jenkins may even refuse to start, since loading one of these files can produce a stack overflow: hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:180) hudson.util.XStream2$PassthruConverter.unmarshal(XStream2.java:323) hudson.util.XStream2$AssociatedConverterImpl.unmarshal(XStream2.java:293) com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60) com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71) hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85) com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:61) hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConverter.java:76) com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
[JIRA] (JENKINS-14816) 404 from Cause/UpstreamCause/description.jelly
jglick
created JENKINS-14816
404 from Cause/UpstreamCause/description.jelly
Issue Type:
Bug
Assignee:
jglick
Components:
core
Created:
15/Aug/12 6:49 PM
Description:
While reproducing JENKINS-14814 I tried configuring each job to only keep the last five builds. Now when build #87 of each has been done, from http://localhost:8080/job/b/83/ there is a link
spanStarted by upstream project a href="" class="code-quote">"/job/a/"a/a build number a href="" class="code-quote">"/job/a/82/"82/a/span
but http://localhost:8080/job/a/82/ gives a 404:
- evaluate(hudson.model.Hudson@1c15348 :hudson.model.Hudson,"/job/a/82")
- evaluate(((StaplerProxy)hudson.model.Hudson@1c15348).getTarget(),"/job/a/82")
- evaluate(hudson.model.Hudson@1c15348.getJob("a"),"/82")
- evaluate(hudson.model.FreeStyleProject@a6125[a] :hudson.model.FreeStyleProject,"/82")
- evaluate(hudson.model.FreeStyleProject@a6125[a].getDynamic("82",...),"")
hudson.model.FreeStyleProject@a6125[a].getDynamic("82",...)==null. Back tracking.
- No matching rule was found on hudson.model.FreeStyleProject@a6125[a] for "/82"
The description should not issue a link to a build (or job!) known to no longer exist.
Project:
Jenkins
Labels:
upstream
404
Priority:
Minor
Reporter:
jglick
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-14818) Stack overflow when jobs are mutually downstream
jglick created JENKINS-14818 Stack overflow when jobs are mutually downstream Issue Type: Bug Assignee: shinodkm Components: downstream-buildview Created: 15/Aug/12 7:05 PM Description: Use the setup in JENKINS-14814 to reproduce. Clicking on http://localhost:8080/job/b/85/downstreambuildview/ produces a blank status and an error on console: Aug 15, 2012 3:01:32 PM hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: it.downstreamBuildList. Reason: java.lang.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) at org.apache.commons.jelly._expression_.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) at org.apache.commons.jelly._expression_.ExpressionSupport.evaluateAsIterator(ExpressionSupport.java:94) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:89) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.OtherwiseTag.doTag(OtherwiseTag.java:41) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at
[JIRA] (JENKINS-14814) Ping-pong builds store excessively large CauseAction
jglick started work on JENKINS-14814 Ping-pong builds store excessively large CauseAction Change By: jglick (15/Aug/12 9:22 PM) Status: Open InProgress 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-14814) Ping-pong builds store excessively large CauseAction
jglick commented on JENKINS-14814 Ping-pong builds store excessively large CauseAction Filed https://github.com/jenkinsci/jenkins/pull/541 for review. 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-14814) Ping-pong builds store excessively large CauseAction
jglick
commented on JENKINS-14814
Ping-pong builds store excessively large CauseAction
Workaround:
perl -i.bak -n -e 'print unless m{hudson\.model\.CauseAction}..m{/hudson\.model\.CauseAction}' jobs/*/builds/*-*/build.xml
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-14827) Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save
jglick created JENKINS-14827 Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save Issue Type: Bug Assignee: Unassigned Components: core Created: 16/Aug/12 3:20 PM Description: 1.479-SNAPSHOT. Create a freeform project, add a shell build step, and enter [ -n x ] for the script. (This should pass.) Now visit config.xml and you will see hudson.tasks.Shell commandquot;[ -n x ]quot;/command /hudson.tasks.Shell which is clearly wrong and would fail: [test] $ /bin/sh -xe /tmp/hudson123.sh + [ -n x ] /tmp/hudson123.sh: 2: /tmp/hudson123.sh: [ -n x ]: not found Build step 'Execute shell' marked build as failure Workaround: test -n x Project: Jenkins Labels: shell unix Priority: Minor Reporter: jglick 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-14827) Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save
jglick commented on JENKINS-14827 Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save Not the fault of Shell - reproducible in HelloWorldBuilder: (foo) stored as is but foo translated to "[foo]". So some problem with form/JSON infrastructure. 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-14827) Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save
jglick commented on JENKINS-14827 Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save Posted request is fine, but StaplerRequest.getSubmittedForm is broken. Seems to be a bug in JSONObject; see call to JSONUtils.mayBeJSON. 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-14827) Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save
jglick
commented on JENKINS-14827
Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save
net.sf.json-lib:json-lib:2.4:jdk15 passes the test
assertEquals("[foo]", JSONObject.fromObject("{x=\"[foo]\"}").getString("x"));
but org.kohsuke.stapler:json-lib:2.1-rev7 fails it. Seems to have been fixed upstream in 2.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
[JIRA] (JENKINS-14827) Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save
jglick commented on JENKINS-14827 Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save Seems https://github.com/jenkinsci/json-lib/commit/c9ba3240cc0ab47231e411ed999a32aabb51cad1 was incomplete. 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-14827) Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save
jglick started work on JENKINS-14827 Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save Change By: jglick (16/Aug/12 5:26 PM) Status: Open InProgress 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-14827) Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save
jglick assigned JENKINS-14827 to Kohsuke Kawaguchi Cannot use /usr/bin/[ as a shell script step: wrapped in ... after save I committed 71809a8 in our fork which seems to fix the problem, but am not sure what I might be missing. Anyway, if you like the fix please release, and use in Stapler / Jenkins. Change By: jglick (16/Aug/12 6:03 PM) Assignee: KohsukeKawaguchi 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
