[JIRA] (JENKINS-61883) Can't access JSONObject entries
Title: Message Title
Roman Donchenko created an issue
Jenkins / JENKINS-61883
Can't access JSONObject entries
Issue Type:
Bug
Assignee:
Unassigned
Components:
script-security-plugin
Created:
2020-04-13 16:19
Environment:
Jenkins 2.190.1 Script Security plugin 1.71
Priority:
Minor
Reporter:
Roman Donchenko
Try executing this pipeline:
def o = readJSON text: '{"foo": "bar"}'
for (entry in o) {
echo entry.class.toString()
echo "$entry.key -> $entry.value"
}
The output is:
class org.apache.commons.collections.map.ListOrderedMap$ListOrderedMapEntry
Scripts not permitted to use method org.apache.commons.collections.KeyValue getKey. Administrators can decide whether to approve or reject this signature.
The reason for that is that readJSON returns a net.sf.json.JSONObject, whose entry class is org.apache.commons.collections.map.ListOrderedMap.ListOrderedMapEntry, which implements org.apache.commons.collections.KeyValue, whose members are not whitelisted. It would be nice if you could do at least one of these: 1. Whitelist org.apache.commons.collections.KeyValue getKey and getValue. 2. Make it so that the existing whitelist entries for java.util.Map.Entry getKey and g
[JIRA] (JENKINS-61590) RebuildCause should not inherit from UpstreamCause
Title: Message Title
Roman Donchenko updated an issue
Jenkins / JENKINS-61590
RebuildCause should not inherit from UpstreamCause
Change By:
Roman Donchenko
Currently, [{{RebuildCause}}|https://github.com/jenkinsci/rebuild-plugin/blob/rebuild-1.31/src/main/java/com/sonyericsson/rebuild/RebuildCause.java] inherits from {{Cause.UpstreamCause}}. This causes several problems:* {{currentBuild.upstreamBuilds}} includes the build that the current build was rebuilt from, even though that's not actually an upstream build.* In downstream jobs of a rebuilt job, the {{RebuildCause}} gets transformed into a plain {{UpstreamCause}} due to [ Cause UpstreamCause .trim|https://github.com/jenkinsci/jenkins/blob/jenkins-2.226/core/src/main/java/hudson/model/Cause.java#L232], which makes it impossible to distinguish a child of a rebuild job from a grandchild of the original job.It would be nice if this was fixed in some way, either by making {{RebuildCause}} not inherit from {{UpstreamCause}} or maybe, if compatibility constraints make that impossible, by introducing a new rebuild cause class.
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
[JIRA] (JENKINS-61590) RebuildCause should not inherit from UpstreamCause
Title: Message Title Roman Donchenko created an issue Jenkins / JENKINS-61590 RebuildCause should not inherit from UpstreamCause Issue Type: Improvement Assignee: ragesh_nair Components: rebuild-plugin Created: 2020-03-19 16:28 Priority: Minor Reporter: Roman Donchenko Currently, RebuildCause inherits from Cause.UpstreamCause. This causes several problems: currentBuild.upstreamBuilds includes the build that the current build was rebuilt from, even though that's not actually an upstream build. In downstream jobs of a rebuilt job, the RebuildCause gets transformed into a plain UpstreamCause due to Cause.trim, which makes it impossible to distinguish a child of a rebuild job from a grandchild of the original job. It would be nice if this was fixed in some way, either by making RebuildCause not inherit from UpstreamCause or maybe, if compatibility constraints make that impossible, by introducing a new rebuild cause class. Add Comment
[JIRA] (JENKINS-59492) False positive CPS mismatch warning when calling a method pointer
Title: Message Title
Roman Donchenko created an issue
Jenkins / JENKINS-59492
False positive CPS mismatch warning when calling a method pointer
Issue Type:
Bug
Assignee:
Unassigned
Components:
workflow-cps-plugin
Created:
2019-09-23 16:31
Environment:
Jenkins: 2.176.3 Pipeline: Groovy: 2.74
Priority:
Minor
Reporter:
Roman Donchenko
Run this pipeline:
def hello() {
echo 'hello'
}
(this.&hello).call()
The output is as follows:
[Pipeline] Start of Pipeline
expected to call org.kohsuke.groovy.sandbox.impl.SandboxedMethodClosure.call but wound up catching WorkflowScript.hello; see: https://jenkins.io/redirect/pipeline-cps-method-mismatches/
[Pipeline] echo
hello
[Pipeline] End of Pipeline
Finished: SUCCESS
As evidenced by the "hello" output, the hello method runs normally, so the warning is a false positive.
[JIRA] (JENKINS-27512) Support icons for folders
Title: Message Title Roman Donchenko commented on JENKINS-27512 Re: Support icons for folders No, there should be at least two: StockFolderIcon (the default icon) MetadataActionFolderIcon Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.161314.1426786361000.1735.1562235780158%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51202) choiceParam not listed in JobDSL API viewer
Title: Message Title Roman Donchenko reopened an issue I think there is still a bug here. There is a non-dynamic version of choiceParam (https://github.com/jenkinsci/job-dsl-plugin/blob/job-dsl-1.74/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/BuildParametersContext.groovy#L86), and that one is not visible in the API viewer. Compare it with, for example, booleanParam, for which both dynamic and non-dynamic versions are shown. Jenkins / JENKINS-51202 choiceParam not listed in JobDSL API viewer Change By: Roman Donchenko Resolution: Not A Defect Status: Closed Reopened Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenki
[JIRA] (JENKINS-27512) Support icons for folders
Title: Message Title Roman Donchenko commented on JENKINS-27512 Re: Support icons for folders branch-api-plugin is not deprecated, and neither is MetadataActionFolderIcon that is defined in it. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.161314.1426786361000.7967.1561456320902%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-27512) Support icons for folders
Title: Message Title Roman Donchenko commented on JENKINS-27512 Re: Support icons for folders There is other icon to choose from Assuming you mean no other icon. That would explain why there's no Appearance section. I've no idea why you don't get the other icon descriptors, though... Just in case, these are the classes that implement the icon types I mentioned in my original comment: https://github.com/jenkinsci/multi-branch-project-plugin/blob/master/src/main/java/com/github/mjdetullio/jenkins/plugins/multibranch/SelectJobsBallColorFolderIcon.java https://github.com/jenkinsci/multi-branch-project-plugin/blob/master/src/main/java/com/github/mjdetullio/jenkins/plugins/multibranch/BallColorFolderIcon.java https://github.com/jenkinsci/multi-branch-project-plugin/blob/master/src/main/java/com/github/mjdetullio/jenkins/plugins/multibranch/SelectJobsBallColorFolderIcon.java https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/MetadataActionFolderIcon.java Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.161314.1426786361000.2489.1560870180154%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-27512) Support icons for folders
Title: Message Title Roman Donchenko commented on JENKINS-27512 Re: Support icons for folders That's odd... all you need to install are the Folders and Multi-Branch Project plugins. Then just create a folder, and "Appearance" will be the first section on the configure page. And here is where this section is defined in the code. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.161314.1426786361000.2274.1560851940350%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-27512) Support icons for folders
Title: Message Title Roman Donchenko assigned an issue to Daniel Spilker Jenkins / JENKINS-27512 Support icons for folders Change By: Roman Donchenko Assignee: Roman Donchenko Daniel Spilker Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.161314.1426786361000.2277.1560851940489%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-27512) Support icons for folders
Title: Message Title Roman Donchenko commented on JENKINS-27512 Re: Support icons for folders They're in the Configure page for a folder, under Appearance -> Icon. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.161314.1426786361000.1587.1560765360535%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-27512) Support icons for folders
Title: Message Title Roman Donchenko assigned an issue to Daniel Spilker Jenkins / JENKINS-27512 Support icons for folders Change By: Roman Donchenko Assignee: Roman Donchenko Daniel Spilker Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.161314.1426786361000.1590.1560765360583%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55867) sh step termination is never detected if the wrapper process is killed
Title: Message Title
Roman Donchenko created an issue
Jenkins / JENKINS-55867
sh step termination is never detected if the wrapper process is killed
Issue Type:
Bug
Assignee:
Unassigned
Components:
durable-task-plugin
Created:
2019-01-30 13:23
Environment:
Jenkins 2.150.2 Durable Task Plugin 1.28
Priority:
Major
Reporter:
Roman Donchenko
When you execute a shell step, Jenkins runs a wrapper shell process that's responsible for saving the exit code of your script. If this process is killed, then Jenkins never discovers that your script has terminated, and the step hangs forever. This can be easily demonstrated by killing the wrapper process yourself:
node() {
sh 'kill $PPID'
}
Run this pipeline and the sh step will never terminate. I believe this happens due to a bug in the log-touching subshell spawned by the wrapper process. Specifically, the subshell checks whether the wrapper process is still alive with this _expression_:
\( -d /proc/$pid -o \! -d /proc/$$ \)
But $$ expands to the PID of the parent shell, not the subshell. This means that $pid and $$ are the same thing, and the whole _expression_ always evaluates to true.
[JIRA] (JENKINS-27512) Support icons for folders
Title: Message Title Roman Donchenko reopened an issue Jenkins / JENKINS-27512 Support icons for folders Change By: Roman Donchenko Resolution: Won't Fix Status: Closed Reopened Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-27512) Support icons for folders
Title: Message Title Roman Donchenko commented on JENKINS-27512 Re: Support icons for folders I'd like to reopen this, because now there are open source plugins with folder icon implementations: The Multi-Branch Project plugin has "Aggregate Ball Color Status Icon (All Jobs)" and "Aggregate Ball Color Status Icon (Select Jobs)". The Branch API plugin has "Metadata Folder Icon". Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55479) Using workspace classes from multiple DSL scripts fails
Title: Message Title
Roman Donchenko created an issue
Jenkins / JENKINS-55479
Using workspace classes from multiple DSL scripts fails
Issue Type:
Bug
Assignee:
Daniel Spilker
Components:
job-dsl-plugin
Created:
2019-01-09 13:30
Environment:
Jenkins 2.150.1 Job DSL plugin 1.71
Priority:
Major
Reporter:
Roman Donchenko
Create a pipeline job with the following script:
node('master') {
writeFile file: 'a.groovy', text: 'new C()'
writeFile file: 'b.groovy', text: 'new C()'
writeFile file: 'C.groovy', text: 'class C {}'
jobDsl targets: 'a.groovy,b.groovy', sandbox: true
}
Add appropriate authorization to the job and run it. It will fail with output like this:
Started by user [...]
Running as [...]
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] node
Running on Jenkins in /var/jenkins_home/workspace/test
[Pipeline] {
[Pipeline] writeFile
[Pipeline] writeFile
[Pipeline] writeFile
[Pipeline] jobDsl
Processing DSL script a.groovy
Processing DSL script b.groovy
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: Scripts not permitted to use new C
Finished: FAILURE
This only happens if multiple DSL scripts are used. If you change the jobDsl step to onl
[JIRA] (JENKINS-54960) Closure-less overloads in DefaultGroovyMethods should be whitelisted
Title: Message Title Roman Donchenko created an issue Jenkins / JENKINS-54960 Closure-less overloads in DefaultGroovyMethods should be whitelisted Issue Type: Improvement Assignee: Andrew Bayer Components: script-security-plugin Created: 2018-11-30 14:50 Priority: Minor Reporter: Roman Donchenko These collection utility methods from DefaultGroovyMethods are currently whitelisted: any collect every find findAll max min However, only the overloads taking a closure as an argument are whitelisted. There are also overloads that don't take a closure (calling which is equivalent to passing Closure.IDENTITY as the argument). I think those should be whitelisted as well. Add Comment
[JIRA] (JENKINS-54960) Closure-less overloads in DefaultGroovyMethods should be whitelisted
Title: Message Title Roman Donchenko created an issue Jenkins / JENKINS-54960 Closure-less overloads in DefaultGroovyMethods should be whitelisted Issue Type: Improvement Assignee: Andrew Bayer Components: script-security-plugin Created: 2018-11-30 14:50 Priority: Minor Reporter: Roman Donchenko These collection utility methods from DefaultGroovyMethods are currently whitelisted: any collect every find findAll max min However, only the overloads taking a closure as an argument are whitelisted. There are also overloads that don't take a closure (calling which is equivalent to passing Closure.IDENTITY as the argument). I think those should be whitelisted as well. Add Comment
[JIRA] (JENKINS-54643) A connection interruption causes the pipeline to fail when USE_WATCHING=true
Title: Message Title
Roman Donchenko updated an issue
Jenkins / JENKINS-54643
A connection interruption causes the pipeline to fail when USE_WATCHING=true
Change By:
Roman Donchenko
Run Jenkins with {{-Dorg.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep.USE_WATCHING=true}}. Add an agent launched via SSH (the launch method may not be important; this is just what I've observed the issue with).Add a pipeline job with this script:{code:groovy}node('mynode') {sh '''#!/bin/sh -efor n in $(seq 100); doecho "$n"sleep 1done'''sh 'echo OK'}{code}Run the pipeline. When is it starts printing numbers to the log, disconnect the master from the network. After 30 seconds, reconnect it.What happens is that for a while (haven't measured, but it feels like a couple of minutes) nothing new appears in the log. After that, the job instantly completes, but:* Some of the output is missing from the log.* The "echo OK" step doesn't run.* The pipeline fails with an {{EOFException}}.I'm attaching a full example log.By contrast, with {{USE_WATCHING=false}} the log resumes a few seconds after the reconnection, no output is skipped and the job succeeds.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
T
[JIRA] (JENKINS-54643) A connection interruption causes the pipeline to fail when USE_WATCHING=true
Title: Message Title
Roman Donchenko created an issue
Jenkins / JENKINS-54643
A connection interruption causes the pipeline to fail when USE_WATCHING=true
Issue Type:
Bug
Assignee:
Unassigned
Attachments:
failure-log.txt
Components:
workflow-durable-task-step-plugin
Created:
2018-11-15 11:29
Environment:
Jenkins 2.138.3 workflow-durable-task-step 2.26
Labels:
regression
Priority:
Major
Reporter:
Roman Donchenko
Run Jenkins with -Dorg.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep.USE_WATCHING=true. Add an agent launched via SSH (the launch method may not be important; this is just what I've observed the issue with). Add a pipeline job with this script:
node('mynode') {
sh '''#!/bin/sh -e
for n in $(seq 100); do
echo "$n"
sleep 1
done
'''
sh 'echo OK'
}
Run the pipeline. When is starts printing numbers to the log, disconnect the master from the network. After 30 seconds, reconnect it. What happens is that for a while (haven't measured, but it feels like a couple of minutes) nothing new appears
[JIRA] (JENKINS-53750) Shell scripts keep the working directory locked on Windows
Title: Message Title
Roman Donchenko commented on JENKINS-53750
Re: Shell scripts keep the working directory locked on Windows
While it would be nice to improve the behavior here, it seems like there are some straightforward workarounds if I understand correctly:
Indeed. My workaround was simply to run sh using the bat step, instead of using the sh step.
something like this that has never worked (as far as I can tell)
I think the issue was introduced in this commit: https://github.com/jenkinsci/durable-task-plugin/commit/8c3504398e5c9292512410077da0e67eaae1c4c4, which is the one that added the timestamp-updating background job. I should also note that, while I encountered this issue on Windows, I think in rare cases it might cause problems on Linux, as well. Something like
sh 'mount -t tmpfs none foo'
dir('foo') { sh 'sleep 1' }
sh 'umount foo'
will probably fail in a similar way, although I have not tested this.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51577) Windows service wrapper for slave.jar can not connect to a SSL configured master
Title: Message Title Roman Donchenko commented on JENKINS-51577 Re: Windows service wrapper for slave.jar can not connect to a SSL configured master Note that it's possible to fix this without modifying WinSW itself. You can add: "Switch.System.Net.DontEnableSchUseStrongCrypto=false"/> to the section of jenkins-slave.exe.config. This will enable TLS 1.2 (and disable SSL 3.0) if WinSW is executed with .NET Framework 4.6 or later. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53874) ZipArchiver should set the type bits when setting the Unix mode
Title: Message Title Roman Donchenko created an issue Jenkins / JENKINS-53874 ZipArchiver should set the type bits when setting the Unix mode Issue Type: Bug Assignee: Unassigned Components: core Created: 2018-10-02 12:22 Environment: Jenkins 2.138.1 Priority: Minor Reporter: Roman Donchenko When ZipArchiver sets the Unix mode for files and directories in the archive, it only sets the permission part of the mode, and not the type part. This causes some problems: If you run zipinfo on such an archive, it shows the mode as ?rw-r--r-- - which is harmless, but confusing. Old versions of libarchive can't extract such files (see https://github.com/libarchive/libarchive/issues/441). There might be other extractors that have similar problems. FIxing this should be simple enough - just OR the mode with S_IFREG (010) for files and S_IFDIR (004) for directories.
[JIRA] (JENKINS-53750) Shell scripts keep the working directory locked on Windows
Title: Message Title
Roman Donchenko created an issue
Jenkins / JENKINS-53750
Shell scripts keep the working directory locked on Windows
Issue Type:
Bug
Assignee:
Unassigned
Components:
durable-task-plugin
Created:
2018-09-24 16:58
Environment:
Jenkins 2.138.1 Durable Task plugin 1.22
Labels:
windows sh
Priority:
Major
Reporter:
Roman Donchenko
Try to run the following pipeline on a Windows node (you'll need a Unix shell port; I am using bash from Git for Windows):
node('mynode') {
stage('Test') {
dir('foo/bar') { sh 'sleep 1' }
bat 'rename foo baz'
}
}
The bat step will fail with an "Access is denied" message. It seems that the reason for this is that when the Durable Task plugin runs its wrapper script (in BourneShellScript.launchWithCookie), it doesn't wait for the wrapper process to finish before it allows pipeline execution to proceed to the next step. It only waits until the result file gets created. This means that for a fraction of time, the bat step will be running concurrently with these three processes created for the sh step:
The wrapper script.
The nohup process
[JIRA] (JENKINS-51303) unzip step doesn't set permissions on extracted files
Title: Message Title
Roman Donchenko created an issue
Jenkins / JENKINS-51303
unzip step doesn't set permissions on extracted files
Issue Type:
Bug
Assignee:
rsandell
Components:
pipeline-utility-steps-plugin
Created:
2018-05-14 16:03
Environment:
Jenkins 2.107.3 Pipeline Utility Steps 2.1.0
Priority:
Minor
Reporter:
Roman Donchenko
Run this pipeline:
node() {
// create an example ZIP file
sh '''\
base64 -d > test.zip << EOF
UEsDBAoAAJ2SrkwIABwAdGVzdC5iaW5VVAkAA1qp+VpaqfladXgLAAEE
6AMAAAToAwAAUEsBAh4DCgAAnZKuTAgAGP2BAHRl
c3QuYmluVVQFAANaqfladXgLAAEE6AMAAAToAwAAUEsFBgABAAEATgAAAEIAAA==
EOF'''.stripIndent()
sh 'unzip -o test.zip && ls -l test.bin && rm test.bin'
unzip zipFile: 'test.zip', quiet: true
sh 'ls -l test.bin'
}
The (relevant) output is:
+ ls -l test.bin
-rwxrwxr-x 1 jenkins jenkins 0 May 14 15:20 test.bin
...
+ ls -l test.bin
-rw-r--r-- 1 jenkins jenkins 0 May 14 15:51 test.bin
You can see that the native unzip program extracts the file with the permissions it actually has in the archive (775), while the unzip step extracts it with defau
[JIRA] (JENKINS-50917) Safe navigation operator doesn't work for setting a property
Title: Message Title Roman Donchenko created an issue Jenkins / JENKINS-50917 Safe navigation operator doesn't work for setting a property Issue Type: Bug Assignee: Unassigned Components: workflow-cps-plugin Created: 2018-04-20 17:11 Environment: Jenkins 2.107.2 Pipeline: Groovy 2.48 Priority: Minor Reporter: Roman Donchenko Normally, this works in Groovy: groovy:000> null?.foo = 'bar' ===> bar But in a pipeline, it does not: java.lang.NullPointerException: Cannot set property 'foo' on null object at org.codehaus.groovy.runtime.NullObject.setProperty(NullObject.java:80) at org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:197) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:484) at org.kohsuke.groovy.sandbox.impl.Checker$7.call(Checker.java:347) at org.kohsuke.groovy.sandbox.impl.Checker.checkedSetProperty(Checker.java:351) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.setProperty(SandboxInvoker.java:33) at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawSet(PropertyAccessBlock.java:24) at WorkflowScript.run(WorkflowScript:1) at ___cps.transform___(Native Method) at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.set(PropertyishBlock.java:88) at com.cloudbees.groovy.cps.impl.Assignmen
[JIRA] (JENKINS-50914) Pipeline snippet generator doesn't work for the publishValgrind step
Title: Message Title Roman Donchenko created an issue Jenkins / JENKINS-50914 Pipeline snippet generator doesn't work for the publishValgrind step Issue Type: Bug Assignee: Johannes Ohlemacher Components: valgrind-plugin Created: 2018-04-20 14:30 Environment: Jenkins 2.107.2 Valgrind plugin 0.28 Priority: Major Reporter: Roman Donchenko If I select the publishValgrind step in the snippet generator, nothing appears underneath it, and this appears in the Jenkins log: Apr 20, 2018 2:26:50 PM hudson.widgets.RenderOnDemandClosure$1 generateResponse WARNING: Failed to evaluate the template closure org.apache.commons.jelly.JellyTagException: jar:file:/var/jenkins_home/plugins/valgrind/WEB-INF/lib/valgrind.jar!/org/jenkinsci/plugins/valgrind/steps/ValgrindPublisherStep/config.jelly:3:85: java.lang.NullPointerException at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:726) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:281) 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.a
[JIRA] (JENKINS-50913) JNLP container is launched with default arguments even with an explicit container definition
Title: Message Title
Roman Donchenko created an issue
Jenkins / JENKINS-50913
JNLP container is launched with default arguments even with an explicit container definition
Issue Type:
Bug
Assignee:
Carlos Sanchez
Components:
kubernetes-plugin
Created:
2018-04-20 13:33
Environment:
Jenkins 2.107.2 Kubernetes plugin 1.5.2
Priority:
Minor
Reporter:
Roman Donchenko
Since Kubernetes plugin 1.5.2, this pipeline script:
podTemplate (
cloud: 'my-cloud',
label: 'my-pod',
containers: [
containerTemplate(
name: 'jnlp',
image: 'my-image')]
) {
// ...
}
will run my-image with the default command line arguments, namely the node secret and node name. Prior to this version, it would run the image with no arguments. This is a problem for me, because my image gets confused by the additional arguments. I think this should be considered a regression.
