Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-26699

Workflow plugin silently breaks regular Groovy maps

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Minor Minor
    • pipeline
    • Jenkins 1.598
      Workflow 1.2

      The docs mention the need for all data in steps to be serializable, but it doesn't mention that it somehow breaks Groovy maps in order to do.

      If I run

      def map =  [foo: "bar", test: 'hello']
      
      println 'Using Groovy version ' + GroovySystem.getVersion()
      println map
      
      map.each { k, v -> println "$k := $v" }
      

      I will see the following when I run groovy locally:

      Using Groovy version 1.8.9
      [foo:bar, test:hello]
      foo := bar
      test := hello
      

      However, I'll get this output from the Jenkins workflow plugin: (note that the each() iteration only shows the first element, and it is not a key/value pair

      Using Groovy version 1.8.9
      Running: Print Message
      {foo=bar, test=hello}
      Running: Print Message
      foo=bar := null
      

      If this is expected behavior, it means users cannot use maps as expected, unless specifically passed to workflow classes that know how to read those parameters.

      Am I doing something wrong here, or should the docs just be updated to reflect this?

          [JENKINS-26699] Workflow plugin silently breaks regular Groovy maps

          Jesse Glick added a comment -

          The map is fine, the each is not.

          Jesse Glick added a comment - The map is fine, the each is not.

          James VL added a comment -

          I'm realizing that now, in trying to use lists in other places. If that was in the docs somewhere I totally missed it.

          Shall I assume that most groovy features which work with closures are not permitted in the workflow script then?

          James VL added a comment - I'm realizing that now, in trying to use lists in other places. If that was in the docs somewhere I totally missed it. Shall I assume that most groovy features which work with closures are not permitted in the workflow script then?

          Jesse Glick added a comment -

          If that was in the docs somewhere I totally missed it.

          We do not generally write up obvious bugs (as opposed to fundamental limitations) in documentation. The time would be better spent fixing them. The Workflow index page links to a JIRA query of open issues.

          Shall I assume that most groovy features which work with closures are not permitted in the workflow script then?

          Closures in general work. (For example the Docker demo uses a function taking a closure as an argument.) JENKINS-26481 just notes that some built-in operations on collections taking closures do not appear to work, presumably a bug in the groovy-cps library which provides CPS-transformed code for every Groovy operator and control flow element. For these cases you currently need to use other syntactic idioms, such as plain old loops.

          Jesse Glick added a comment - If that was in the docs somewhere I totally missed it. We do not generally write up obvious bugs (as opposed to fundamental limitations) in documentation. The time would be better spent fixing them. The Workflow index page links to a JIRA query of open issues. Shall I assume that most groovy features which work with closures are not permitted in the workflow script then? Closures in general work. (For example the Docker demo uses a function taking a closure as an argument.) JENKINS-26481 just notes that some built-in operations on collections taking closures do not appear to work, presumably a bug in the groovy-cps library which provides CPS-transformed code for every Groovy operator and control flow element. For these cases you currently need to use other syntactic idioms, such as plain old loops.

          James VL added a comment -

          Thanks for taking the time to clarify this - I appreciate it. Didn't find the duplicate bug reort when I first searched.

          I wasn't sure if this feel under "fundamental limitation" or "CPS / Serialization bug". I've reverted to plain old loops in the mean time.

          James VL added a comment - Thanks for taking the time to clarify this - I appreciate it. Didn't find the duplicate bug reort when I first searched. I wasn't sure if this feel under "fundamental limitation" or "CPS / Serialization bug". I've reverted to plain old loops in the mean time.

          Jesse Glick added a comment -

          Someone also noted that some loop idioms use for example java.util.ArrayList$Itr, which is not Serializable, and so cannot be used in a workflow. I thought this was filed in JIRA but I do not see it now. Whether it is even fixable is another question; I can only imagine fixing it by making reference to JRE implementation details, which is not robust.

          Jesse Glick added a comment - Someone also noted that some loop idioms use for example java.util.ArrayList$Itr , which is not Serializable , and so cannot be used in a workflow. I thought this was filed in JIRA but I do not see it now. Whether it is even fixable is another question; I can only imagine fixing it by making reference to JRE implementation details, which is not robust.

            jglick Jesse Glick
            jamesvl James VL
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: