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

Workflow plugin silently breaks regular Groovy maps

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Duplicate
    • Component/s: pipeline
    • Labels:
    • Environment:
      Jenkins 1.598
      Workflow 1.2
    • Similar Issues:

      Description

      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?

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            The map is fine, the each is not.

            Show
            jglick Jesse Glick added a comment - The map is fine, the each is not.
            Hide
            jamesvl 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?

            Show
            jamesvl 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?
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            jamesvl 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.

            Show
            jamesvl 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.
            Hide
            jglick 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.

            Show
            jglick 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.

              People

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

                Dates

                Created:
                Updated:
                Resolved: