Nice hackaround. I will try that in the uncooperative parts of my script.
Ah yes, *def x* vs *x*. On the face of it the two declarations should be
identical--roughly typing *x* as an *Object*. But there are different
scoping implications
<http://stackoverflow.com/questions/15619216/groovy-scope-how-to-access-script-variable-in-a-method>
for each.
On Wednesday, April 27, 2016 at 3:00:43 PM UTC-7, Norbert Lange wrote:
>
> Hi Brian,
>
> every single method in the "final foo...." - including the String
> Constructor requires approval. I was hoping for a proper subset that would
> work within the sandbox.
> What I ended with (several dozen "Builds" later ) is using a helper
> function squeezing the map into a list, seems the most sane aproach so far
> =(
>
> Btw, whats the difference of using "def x" vs "x"?
>
> node {
> ....
> for (it2 in mapToList(depmap)) {
> name = it2[0]
> revision = it2[1]
> }
> }
> @NonCPS
> def mapToList(depmap) {
> def dlist = []
> for (entry in depmap) {
> dlist.add([entry.key, entry.value])
> }
> dlist
> }
>
>
>
>
> Am Mittwoch, 27. April 2016 18:26:51 UTC+2 schrieb Brian Ray:
>>
>> FWIW I recently replaced several C-style loops with *for ( x in y )* for
>> iterating over both lists and maps in CPS code and for the most part
>> conversion went fine. There were a couple of CPS sections where I could not
>> use that construct and had to fall back on the C-loops and further do a
>> torturous cast to avoid a serialization error getting keys and values from
>> the map. I want to say *Set<Map.Entry<K,V>>* caused the exception
>> because *AbstractMap.SimpleEntry* and *.SimpleImmutableEntry* are
>> serializable, while *Set *is not, per the JDK.
>>
>> for ( int i = 0; i < myMap.size(); i++ ) {
>>
>> // hacktacular String() cloning to avoid NotSerializableException;
>> also
>> // hacktacular Map > Set > Array morph to enable C-style looping
>> final foo = new String( myMap.entrySet().toArray()[i].value )
>>
>> // do stuff with foo...
>>
>> }
>>
>>
>> Nonetheless as mentioned in another part of the script I had no problem
>> using the shorter alternative, nor accessing keys and values using
>> *myMap.key* and *myMap.value*. Not sure what the difference is with my
>> more stubborn loop.
>>
>> On Wednesday, April 27, 2016 at 8:21:45 AM UTC-7, Norbert Lange wrote:
>>>
>>>
>>>
>>> Am Mittwoch, 27. April 2016 16:41:40 UTC+2 schrieb Jesse Glick:
>>>>
>>>> On Tuesday, April 26, 2016 at 7:18:55 PM UTC-4, Norbert Lange wrote:
>>>>>
>>>>> There seem to be some arcane rules on how to iterate over some
>>>>> builtin Groovy/Java Types within a sandbox. I haven`t found a way that
>>>>> works without manually allowing the function.
>>>>
>>>>
>>>> Which methods did you need to approve? We can easily add them to the
>>>> default whitelist in the Script Security plugin. But anyway
>>>>
>>>> The map`s each (at least)
>>>
>>>
>>>>
>>>>> 2) Serialization issues for iterators.
>>>>>
>>>>
>>>> `for (x : list) {…}` works as of `workflow-cps` 2.x. Other iterators do
>>>> not yet work (outside a `@NonCPS` method). Probably fixing them is not
>>>> hard, just have not gotten to it yet
>>>>
>>>
>>> Yes, these issues I can very likely work around. For someone who is new
>>> to Groovy and Jenkins sandboxing, a list of preferred methods would be very
>>> welcome (the examples from the workflow libs are rather simple). There are
>>> atleast 3 different ways to iterate over containers, and several variations
>>> of those for maps.
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> take the createDList
>>>>> which seems to execute the code differently (throws errrors, need to
>>>>> define a explicit variable)
>>>>>
>>>>
>>>> Not sure what this is about. If you find something you think should
>>>> work which does not work in a minimal reproducible script, please file a
>>>> bug report for it.
>>>>
>>> Where? Is that a feature-not-bug of Groovy, an issue in Jenkins or some
>>> Plugin? I was hoping for some feedback as I am not proficient in either of
>>> those to pinpoint issues.
>>> The code above should be able to explain the issue, the exact same
>>> method body in the node scope works fine, the call will result in some
>>> message about "it not defined". Similary there seems some issues with name
>>> clashes (if variables in functions are named like those in the node scope),
>>> but it mightve been some flukes during trial-and-error
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> Are variables from Closures global?
>>>>>
>>>>
>>>> Local `def` variables in a closure? Not sure what you are referring to
>>>> here.
>>>>
>>> See last point, and the code were I can access the it variable after the
>>> closure were its used (Noted with "// Weird !" )
>>>
>>>>
>>>> The main problem you are presumably hitting is the well-known
>>>> JENKINS-26481 <https://issues.jenkins-ci.org/browse/JENKINS-26481>. We
>>>> are working on a fix, but in the meantime, do not use any method built
>>>> into
>>>> Groovy which takes a closure argument, such as `list.each {x -> …}` or
>>>> `someText.eachLine {line -> …}`. Rather use a Java-style loop. (To be on
>>>> the safe side, also avoid iterators, meaning use a C- or JDK 1.4-style
>>>> loop
>>>> with an index.)
>>>>
>>> Could you please post me the preferable code for iterating a map in this
>>> way? (Not sure I fully understand the bug )
>>>
>>>
>>>> Incidentally `it` does not currently work in closures as noted in
>>>> JENKINS-33468
>>>> <https://www.google.com/url?q=https%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-33468&sa=D&sntz=1&usg=AFQjCNHCpckU-LtRXqq1a2tEPCzNrYhPTw>;
>>>>
>>>> use an explicit parameter name instead.
>>>>
>>> That seems to be one of the issues I am fighting with, and might be that
>>> the supposed name-clashes came from unfocused variations of the code.
>>> Strangely it does seem to somewhat work in the node body?
>>>
>>> Kind Regards,
>>> Norbert
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/acfaa0de-8585-44ce-bbd7-ba96cf00022a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
