[JIRA] (JENKINS-56217) allow to hide version number
Title: Message Title Thomas Wabner created an issue Jenkins / JENKINS-56217 allow to hide version number Issue Type: Improvement Assignee: Unassigned Components: jenkinsfile-runner Created: 2019-02-20 15:35 Environment: LTS Priority: Trivial Reporter: Thomas Wabner It would be nice to have a option (-D or something similar) to hide the version information of the running jenkins master instance. This would avoid (make it harder) for hackers to attack a jenkins instance which has known vulnerabilities. Currently the website shows in the footer the current running jenkins version. I would like to hide this information or overwrite it with "-1" or similar. Such option can be set a java system property. We are running jenkins master as WAR archive inside a tomcat container. So the java system property would be the best way to solve this. PS: feel free to change the component .. there seems to be no component for jenkins master or the general UI available. Add Comment
[JIRA] (JENKINS-39917) project update with dsl-script does not update "rootPom" settings for maven job
Title: Message Title
Thomas Wabner created an issue
Jenkins / JENKINS-39917
project update with dsl-script does not update "rootPom" settings for maven job
Issue Type:
Bug
Assignee:
Daniel Spilker
Components:
job-dsl-plugin
Created:
2016/Nov/21 5:59 PM
Environment:
jobDslVersion=1.53 jenkinsVersion=2.19.3 (LTS)
Priority:
Major
Reporter:
Thomas Wabner
We have some job-dsl scripts which are generating maven jobs. I have run the scripts with a seed job with a setup of something like this:
...
rootPOM('myproject')
...
This generates a jenkins job where in the rootPom section the correct setting "myproject/pom.xml" is generated. Now I needed, because of project refactoring, to remove this setting in my job-dsl script. After removing the statement and running the seed job again, the root pom entry "myproject/pom.xml" is still there. So it seems, the update does not affect this statement. After remove the jenkins job per hand and running the seed job again, the root pom statement was correct removed. So in general the generation of the job seems to be correct. It seems that only a job-update for the root-pom section is defect.
[JIRA] (JENKINS-36870) Build hangs in several phases (post build, pre build, email-ext)
Title: Message Title Thomas Wabner closed an issue as Not A Defect Thanks for your help. We have tried to check with debug enabled and started to disable some plugins. Therefore we found one suspecting plugin which uses ldap callbacks to get email adresses for users from AD backend. And this plugin makes a deadlock. After disabled security at all, all build running fine. After patching the ldap plugin we have a working jenkins instance back. Thank you again. Jenkins / JENKINS-36870 Build hangs in several phases (post build, pre build, email-ext) Change By: Thomas Wabner Status: Open Closed Resolution: Not A Defect Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-36870) Build hangs in several phases (post build, pre build, email-ext)
Title: Message Title
Thomas Wabner updated an issue
Jenkins / JENKINS-36870
Build hangs in several phases (post build, pre build, email-ext)
Change By:
Thomas Wabner
After upgrading Jenkins LTS version from 1.651. 2 1 to 2.7.1 we have nearly all builds hanging. Some of them hanging in "Before Build" phase and some are seem to be finished but hanging also.For example the output for a hanging build in "before build" phase:{quote}[EnvInject] - Variables injected successfully.Email was triggered for: Before BuildSending email for trigger: Before Build{quote}And an example about the "finished build" phase:{quote}[INFO] BUILD SUCCESS[INFO] [INFO] Total time: 01:33 min[INFO] Finished at: 2016-07-22T10:34:15+02:00[INFO] Final Memory: 71M/809M[INFO] Waiting for Jenkins to finish collecting datachannel stoppedJava HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0{quote}We guess it is a general problem with jenkins master/node .. nothing plugin specific. But for example builds with simple scripts (powershell) working and sending emails (so not email-ext specific) and some builds are finishing after a great period of time.We have no clue which circumstances making this behavior.We have also seen this after trying to upgrade LTS from 1.651.2 to 1.651.3 .. so possible some changes between those versions making the difference.
Add Comment
[JIRA] (JENKINS-36870) Build hangs in several phases (post build, pre build, email-ext)
Title: Message Title
Thomas Wabner updated an issue
Jenkins / JENKINS-36870
Build hangs in several phases (post build, pre build, email-ext)
Change By:
Thomas Wabner
After upgrading Jenkins LTS version from 1.651.1 to 2.7.1 we have nearly all builds hanging. Some of them hanging in "Before Build" phase and some are seem to be finished but hanging also.For example the output for a hanging build in "before build" phase:{quote}[EnvInject] - Variables injected successfully.Email was triggered for: Before BuildSending email for trigger: Before Build{quote}And an example about the "finished build" phase:{quote}[INFO] BUILD SUCCESS[INFO] [INFO] Total time: 01:33 min[INFO] Finished at: 2016-07-22T10:34:15+02:00[INFO] Final Memory: 71M/809M[INFO] Waiting for Jenkins to finish collecting datachannel stoppedJava HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0{quote}We guess it is a general problem with jenkins master/node .. nothing plugin specific. But for example builds with simple scripts (powershell) working and sending emails (so not email-ext specific) and some builds are finishing after a great period of time.We have no clue which circumstances making this behavior.We have also seen this after trying to upgrade LTS from 1.651. 2 1 to 1.651. 3 2 .. so possible some changes between those versions making the difference.
Add Comment
[JIRA] (JENKINS-28373) apache maven 3.3.3 cannot be invoked anymore on windows
Title: Message Title Thomas Wabner commented on JENKINS-28373 Re: apache maven 3.3.3 cannot be invoked anymore on windows I have seen that this issue is fixed in a recent jenkins version? (we have switched to LTS .. so not checked if it was closed already here). 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-36870) Build hangs in several phases (post build, pre build, email-ext)
Title: Message Title Thomas Wabner created an issue Jenkins / JENKINS-36870 Build hangs in several phases (post build, pre build, email-ext) Issue Type: Bug Assignee: David van Laatum Attachments: delpzs9900dsrv-thread-dump.txt, Thread dump [Jenkins].html Components: email-ext-plugin, maven-plugin Created: 2016/Jul/22 9:36 AM Environment: Windows 2012 slave and master installation Labels: jenkins master node Priority: Blocker Reporter: Thomas Wabner After upgrading Jenkins LTS version from 1.651.2 to 2.7.1 we have nearly all builds hanging. Some of them hanging in "Before Build" phase and some are seem to be finished but hanging also. For example the output for a hanging build in "before build" phase: [EnvInject] - Variables injected successfully. Email was triggered for: Before Build Sending email for trigger: Before Build And an example about the "finished build" phase: [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 01:33 min [INFO] Finished at: 2016-07-22T10:34:15+02:00 [INFO] Final Memory:
[JIRA] [job-dsl-plugin] (JENKINS-32598) Folder authorization permission NPE
Title: Message Title
Thomas Wabner updated an issue
Jenkins / JENKINS-32598
Folder authorization permission NPE
Change By:
Thomas Wabner
The folder currently does not support authorization/permission elements because the variable availablePermissions seems to be null (not declared/initializes).https://jenkinsci.github.io/job-dsl-plugin/#path/folder-authorizationYou can also check this in the API browser:http://job-dsl.herokuapp.com/{{ folder('example-2') {authorization {permission('hudson.model.Item.Discover', 'anonymous')}} }}Exception:{{java.lang.NullPointerException: Cannot invoke method contains() on null object at java_util_Set$contains$2.call(Unknown Source) at javaposse.jobdsl.dsl.helpers.AuthorizationContext.permission(AuthorizationContext.groovy:49)}}I guess, a simple variable declaration should be enough. But I'am not that groovy aware to create pull requests for this.
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] [job-dsl-plugin] (JENKINS-32598) Folder authorization permission NPE
Title: Message Title
Thomas Wabner updated an issue
Jenkins / JENKINS-32598
Folder authorization permission NPE
Change By:
Thomas Wabner
The folder currently does not support authorization/permission elements because the variable availablePermissions seems to be null (not declared/initializes).https://jenkinsci.github.io/job-dsl-plugin/#path/folder-authorizationYou can also check this in the API browser:http://job-dsl.herokuapp.com/{quote}folder('example-2') {authorization {permission('hudson.model.Item.Discover', 'anonymous')}}{quote}Exception:{ { quote} java.lang.NullPointerException: Cannot invoke method contains() on null object at java_util_Set$contains$2.call(Unknown Source) at javaposse.jobdsl.dsl.helpers.AuthorizationContext.permission(AuthorizationContext.groovy:49) {quote } } I guess, a simple variable declaration should be enough. But I'am not that groovy aware to create pull requests for this.
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] [job-dsl-plugin] (JENKINS-32598) Folder authorization permission NPE
Title: Message Title
Thomas Wabner created an issue
Jenkins / JENKINS-32598
Folder authorization permission NPE
Issue Type:
Bug
Assignee:
Daniel Spilker
Components:
job-dsl-plugin
Created:
25/Jan/16 6:28 PM
Environment:
job-dsl-plugin 1.42
Priority:
Blocker
Reporter:
Thomas Wabner
The folder currently does not support authorization/permission elements because the variable availablePermissions seems to be null (not declared/initializes).
https://jenkinsci.github.io/job-dsl-plugin/#path/folder-authorization
You can also check this in the API browser:
http://job-dsl.herokuapp.com/
{{folder('example-2') { authorization { permission('hudson.model.Item.Discover', 'anonymous') }
}}}
Exception: {{java.lang.NullPointerException: Cannot invoke method contains() on null object at java_util_Set$contains$2.call(Unknown Source) at javaposse.jobdsl.dsl.helpers.AuthorizationContext.permission(AuthorizationContext.groovy:49)}}
I guess, a simple variable declaration should be enough. But I'am not that groovy aware to create pull requests for this.
[JIRA] [job-dsl-plugin] (JENKINS-32598) Folder authorization permission NPE
Title: Message Title
Thomas Wabner updated an issue
Jenkins / JENKINS-32598
Folder authorization permission NPE
Change By:
Thomas Wabner
The folder currently does not support authorization/permission elements because the variable availablePermissions seems to be null (not declared/initializes).https://jenkinsci.github.io/job-dsl-plugin/#path/folder-authorizationYou can also check this in the API browser:http://job-dsl.herokuapp.com/ {{ {quote} folder('example-2') {authorization {permission('hudson.model.Item.Discover', 'anonymous')}} {quote } } Exception:{{java.lang.NullPointerException: Cannot invoke method contains() on null object at java_util_Set$contains$2.call(Unknown Source) at javaposse.jobdsl.dsl.helpers.AuthorizationContext.permission(AuthorizationContext.groovy:49)}}I guess, a simple variable declaration should be enough. But I'am not that groovy aware to create pull requests for this.
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-32435) Branches to build does not read content of environment variable
Title: Message Title
Thomas Wabner commented on JENKINS-32435
Re: Branches to build does not read content of environment variable
First of all: many thanks for this dep analyze!
I can confirm that it works, if I change the variable from
GIT*-RELEASE_BRANCH to GIT_*RELEASE_BRANCH
Beside: If have used a maven styled job ... but nevertheless ... in general variable substitution works in this way. I was not aware of, that in Jenkins it is required to name the variables in such style.
If you think, also the variable GIT-RELEASE_BRANCH
should also expand, we can create another JIRA issue for this.
I would expect, that every variable with common variable patterns inside ${} should be useable?
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-32435) Branches to build does not read content of environment variable
Title: Message Title
Thomas Wabner edited a comment on JENKINS-32435
Re: Branches to build does not read content of environment variable
First of all: many thanks for this dep analyze!I can confirm that it works, if I change the variable from {{GIT * - * RELEASE_BRANCH to GIT*_*RELEASE_BRANCH GIT_RELEASE_BRANCH }} Beside: If have used a maven styled job ... but nevertheless ... in general variable substitution works in this way. I was not aware of, that in Jenkins it is required to name the variables in such style.If you think, also the variable {{GIT-RELEASE_BRANCH}}should also expand, we can create another JIRA issue for this. I would expect, that *every* variable with common variable patterns inside ${} should be useable?
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-23477) git-client-plugin sparse checkout path field does not expand variables
Title: Message Title Thomas Wabner updated an issue Jenkins / JENKINS-23477 git-client-plugin sparse checkout path field does not expand variables Change By: Thomas Wabner Priority: Minor Major 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-23477) git-client-plugin sparse checkout path field does not expand variables
Title: Message Title
Thomas Wabner commented on JENKINS-23477
Re: git-client-plugin sparse checkout path field does not expand variables
We see the same situation:
we using some maven jobs and prepare the environment with some predefind variables like
project_rel_path=maven/parents/web-parent
Then we want to use in sparse-checkout path this variable like _$ {project_rel_path}
_. But we get then errors like * stderr: error: Sparse checkout leaves no entry on working directory*
We need such "central" point of configuration for our project definitions, because if we sparse checkout such path, the path is checked out as it is. So the workspace contains a folder like
/maven/parents/web-parent/
As for a standard maven job, we need to define where to find the pom.xml ... in such way with sparse checkout, we need to configure, that the pom can be found under maven/parents/web-parent/pom.xml (and we cannot rely on default maven job behaviour, that the pom.xml is in root of workspace).
One possible solution would be to provide a option to sparse checkout to root ... or to honor environment/build variables like $ {xyz}
and expand them.
Environment:
Windows 64, git client 2.7.0, jenkins 1.643, git plugin 2.4.1
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-32435) Branches to build does not read content of environment variable
Title: Message Title
Thomas Wabner created an issue
Jenkins / JENKINS-32435
Branches to build does not read content of environment variable
Issue Type:
Bug
Assignee:
Mark Waite
Components:
git-plugin
Created:
13/Jan/16 5:12 PM
Environment:
Windows, git executeable, jenkins 1.643, git-plugin 2.4.1
Priority:
Major
Reporter:
Thomas Wabner
We try to use the "Branches to build" setting of the GIT plugin with variable substitution.
That it should be possible and work is stated in the inline help for this parameter: === {{$ {ENV_VARIABLE}
It is also possible to use environment variables. In this case the variables are evaluated and the result is used as described above. E.g. $ {TREEISH}
, refs/tags/$ {TAGNAME}
,...}} ===
We have setup our job with the flag "Prepare environment to run" and added following parameter as "Properties Content":
GIT-RELEASE_BRANCH=refs/heads/release/20160113
In the field of "Branches to build" we tried to use $ {GIT-RELEASE_BRANCH} We have also tried ${ENV_GIT-RELEASE_BRANCH}. We can see for a specific build that the parameter is available as
[JIRA] [maven-invoker-plugin] (JENKINS-28373) apache maven 3.3.3 cannot be invoked anymore on windows
Title: Message Title
Thomas Wabner updated an issue
Jenkins / JENKINS-28373
apache maven 3.3.3 cannot be invoked anymore on windows
Change By:
Thomas Wabner
Thenewapache maven version3.3.3hasremovedthemvn.batfileandintroducedanewfilemvn.cmd.Ifweusethisversioninourmavenstylebuilds,wegetmoreorlessthefollowingerror:{{FATAL:Couldn’tfindanyexecutableinD:\current-maven}}Ilookslike,theJenkinsmavenbuildalwayscallsmvn.batinsteadofmvnonly.Itcanbefixedbycreatingalinkwith{{mklink}}onwindowslike{{current-maven/binmklinkmvn.batmvn.cmd}}
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] [maven-invoker-plugin] (JENKINS-28373) apache maven 3.3.3 cannot be invoked anymore on windows
Title: Message Title
Thomas Wabner updated an issue
Jenkins / JENKINS-28373
apache maven 3.3.3 cannot be invoked anymore on windows
Change By:
Thomas Wabner
Thenewapacheversion3.3.3hasremovedthemvn.batfileandintroducedanewfilemvn.cmd.Ifweusethisversioninourmavenstylebuilds,wegetmoreorlessthefollowingerror:{{FATAL:Couldn’tfindanyexecutableinD:\current-maven}}Ilookslike,theJenkinsmavenbuildalwayscallsmvn.batinsteadofmvnonly.Itcanbefixed my by creatingalinkwith {{ mklink }} onwindowslike{{current-maven/binmklinkmvn.batmvn.cmd}}
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] [maven-invoker-plugin] (JENKINS-28373) apache maven 3.3.3 cannot be invoked anymore on windows
Title: Message Title
Thomas Wabner updated an issue
Jenkins / JENKINS-28373
apache maven 3.3.3 cannot be invoked anymore on windows
Change By:
Thomas Wabner
Thenewapacheversion3.3.3hasremovedthemvn.batfileandintroducedanewfilemvn.cmd.Ifweusethisversioninourmavenstylebuilds,wegetmoreorlessthefollowingerror:{{FATAL:Couldn’tfindanyexecutableinD:\current-maven}}Ilookslike,theJenkinsmavenbuildalwayscallsmvn.batinsteadofmvnonly.Itcanbefixedmycreatingalinkwithmklinkonwindowslike{{current-maven/binmklinkmvn.batmvn.cmd }}
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] [maven-invoker-plugin] (JENKINS-28373) apache maven 3.3.3 cannot be invoked anymore on windows
Title: Message Title
Thomas Wabner created an issue
Jenkins / JENKINS-28373
apache maven 3.3.3 cannot be invoked anymore on windows
Issue Type:
Bug
Assignee:
olamy
Components:
maven-invoker-plugin
Created:
13/May/15 9:29 AM
Environment:
Jenkins Node running on Windows
Priority:
Major
Reporter:
Thomas Wabner
The new apache version 3.3.3 has removed the mvn.bat file and introduced a new file mvn.cmd. If we use this version in our maven style builds, we get more or less the following error:
FATAL: Couldn’t find any executable in D:\current-maven
I looks like, the Jenkins maven build always calls mvn.bat instead of mvn only.
It can be fixed my creating a link with mklink on windows like
{{current-maven/bin mklink mvn.bat mvn.cmd }}
[JIRA] [configurationslicing-plugin] (JENKINS-25964) NullPointerExcpetion when try to slice parameters
Thomas Wabner created JENKINS-25964 NullPointerExcpetion when try to slice parameters Issue Type: Bug Assignee: mdonohue Components: configurationslicing-plugin Created: 09/Dec/14 8:16 AM Description: If I try to "slice" parameters for my projects I get a empty page. After taking a look into the log files I see the following stack trace: INFO: Loaded: class configurationslicing.tools.GroovySlicer Dec 09, 2014 9:08:27 AM hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: it.configuredValues in /jenkins/slicing/parameters/. 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:606) 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:74) 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:269) 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.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:95) at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:147) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) 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.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) 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.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120) at
[JIRA] [configurationslicing-plugin] (JENKINS-25964) NullPointerExcpetion when try to slice parameters
Thomas Wabner commented on JENKINS-25964 NullPointerExcpetion when try to slice parameters Found one missed piece in the log: Caused by: java.lang.NullPointerException at java.lang.String$CaseInsensitiveComparator.compare(String.java:1177) at java.lang.String$CaseInsensitiveComparator.compare(String.java:1170) at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324) at java.util.TimSort.sort(TimSort.java:189) at java.util.TimSort.sort(TimSort.java:173) at java.util.Arrays.sort(Arrays.java:659) at java.util.Collections.sort(Collections.java:217) at configurationslicing.UnorderedStringSlice.getConfiguredValues(UnorderedStringSlice.java:110) ... 130 more 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] [configurationslicing-plugin] (JENKINS-25964) NullPointerExcpetion when try to slice parameters
Thomas Wabner
commented on JENKINS-25964
NullPointerExcpetion when try to slice parameters
I have found the root cause of this error:
I have a project with a parameter definition like this:
hudson.model.StringParameterDefinition
namedeployment_reason/name
/hudson.model.StringParameterDefinition
It is missing the description and defaultValue tags. It should look like this
hudson.model.StringParameterDefinition
namedeployment_reason/name
description /
defaultValue /
/hudson.model.StringParameterDefinition
I have changed the code in UnorderedStringSlice for the method addLineWithSets to following:
private static void addLineWithSets(MapString, SetString map, String s, String name) {
if (null == s) {
LOGGER.severe("found illegal line with null value for name: "+name);
// do nothing
return;
}
if(!map.containsKey(s)) {
map.put(s, new HashSetString());
}
SetString list= map.get(s);
list.add(name);
}
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] [maven-plugin] (JENKINS-25416) text parameter with newlines causing the default goal run
Thomas Wabner commented on JENKINS-25416 text parameter with newlines causing the default goal run Yes, I have tried with ant ... more or less the same result: testwebapp_svn_commit $ cmd.exe /C '"D:\applications\prg\jenkinsSlave1\tools\hudson.tasks.Ant_AntInstallation\ant-1.9.3\bin\ant.bat -Ddeployment_reason=a b c -Dpart_svn_url=trunk/devopts/testprojects clean exit %%ERRORLEVEL%%"' Buildfile: D:\applications\prg\jenkinsSlave1\workspace\test-webapp\testwebapp_svn_commit\build.xml test-offline: get-deps: the default goal is "package", but the goal configured is "clean" (which never tries to get the dependencies). With a one-liner it works. I have set for the parameter "deployment_reason" the content a b c I'm afraid that someone (the user) can also inject other commands into the command shell call and in the worst case hack or destroy the build agent (I have not started to check this ... but the escaping thing looks like a possible target) 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-25416) text parameter with newlines causing the default goal run
Thomas Wabner commented on JENKINS-25416 text parameter with newlines causing the default goal run one additional note about the maven project: If the job is a maven project and you use such text parameter, also all pre- and post steps will fail (if they invoke for example a maven or ant tool). In such case you can "unset" the parameter with the env-inject plugin and remember it into another variable ... this variable will then not added as a parameter to the job ... but this is still very hackish. So the problem exists also for maven jobs with pre- or post-steps. I do not know, if it is a good idea to reduce the priority, because of the possibility to "destroy" the Jenkins slave with a unchecked parameter ... but I do not know enough about the JIRA rules for this project. Possible more investigation about the consequences should be made, to decide about the priority. 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] [maven-plugin] (JENKINS-25416) text parameter with newlines causing the default goal run
Thomas Wabner created JENKINS-25416 text parameter with newlines causing the default goal run Issue Type: Bug Assignee: Unassigned Components: maven-plugin Created: 03/Nov/14 2:57 PM Description: I have a required build-parameter "build_reason" of type text. Our users can insert some free-text for the build reason. If the parameter contains, for example, following input in the text-box: "first line second line" then jenkins calling maven in the following way: testwebapp_svn_commit $ D:\applications\prg\ApacheMaven\current-maven\bin\mvn.bat -Dbuild_reason_org=first line scond line -Dpart_svn_url=trunk/devopts/testprojects validate This causes maven to simple run the default goal and ignore all other parameters. It seems that the text parameter is not escaped correct. This problem does not apply only to maven .. it applies to all builds where such parameter is injected. Waffel Environment: Jenkins 1.583, Windows, Java 7U72 Project: Jenkins Labels: jenkins maven3 parameter build Priority: Major Reporter: Thomas Wabner 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] [maven-plugin] (JENKINS-25416) text parameter with newlines causing the default goal run
Thomas Wabner commented on JENKINS-25416 text parameter with newlines causing the default goal run It is a freestyle project. I have started to check with a maven project ... here the problem seems to not exists. I guess it is not maven relevant, because the freestyle project calls mvn.bat ... same problem can be exists for ANT or other tools which are called via cmd. Possible it is a general "shell" problem under Windows. 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.
