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

Unable to use double quotes and round trip with them

    • 1.0, Blue Ocean 1.0-rc3, Blue Ocean 1.2-beta4, Blue Ocean 1.2, Blue Ocean 1.3

      If I create a shell step with double quotes in the text box:

      "echo 42"

      I get when I export:

      sh('"echo 42"')
      

      ie extra quotes - is this intended?

      When I import shell step with double quotes deliberately in the script, it isn't reflected in the text area, and when I export it again - they are gone (ie just single quotes)

          [JENKINS-41548] Unable to use double quotes and round trip with them

          Keith Zantow added a comment -

          This is working as expected. Whatever text you put in the shell script textarea should be sent to the node, it's single quoting as it's always currently isLiteral: true

          Keith Zantow added a comment - This is working as expected. Whatever text you put in the shell script textarea should be sent to the node, it's single quoting as it's always currently isLiteral: true

          Cliff Meyers added a comment -

          michaelneale I'm not sure if this was perhaps fixed in the intervening time? Here are my test steps:

          1. Create new shell step
          2. Enter "echo 42" including quotes
          3. Save
          4. Build fails (expected since the double quotes were preserved?)
          5. Reload the editor
          6. Select shell step
          7. Note that text is "echo 42" including quotes

          If this needs to behave differently, could you please clarify with more detail?

          Cliff Meyers added a comment - michaelneale I'm not sure if this was perhaps fixed in the intervening time? Here are my test steps: Create new shell step Enter "echo 42" including quotes Save Build fails (expected since the double quotes were preserved?) Reload the editor Select shell step Note that text is "echo 42" including quotes If this needs to behave differently, could you please clarify with more detail?

          Keith Zantow added a comment - - edited

          cliffmeyers it's a different problem. Use Cmd-S to open the pipeline paste dialog and input this pipeline:

          pipeline { stage('0') { steps { echo "hello" } } }
          

          Note the double-quotes around "hello". Save it, then Cmd-S again, note that there are single quotes. The model has a flag for each property called isLiteral. If it's literal, it should be output single quoted, otherwise it should be output verbatim. The issue here is we need to make sure that flag is preserved properly between paste and generating the pipeline.

          Keith Zantow added a comment - - edited cliffmeyers it's a different problem. Use Cmd-S to open the pipeline paste dialog and input this pipeline: pipeline { stage( '0' ) { steps { echo "hello" } } } Note the double-quotes around "hello". Save it, then Cmd-S again, note that there are single quotes. The model has a flag for each property called isLiteral . If it's literal, it should be output single quoted, otherwise it should be output verbatim. The issue here is we need to make sure that flag is preserved properly between paste and generating the pipeline.

          Michael Neale added a comment -

          I wonder if this bites the script step... 

          Michael Neale added a comment - I wonder if this bites the script step... 

          Keith Zantow added a comment -

          NOTE: !!!:

          To understand how this is working, you need to understand how declarative parses the files. It's using Groovy, so there are some limitations:

          The only case this works with double-quoted strings is when they include some expansion, e.g. "$user". If you have a plain string like "user" it will be functionally equivalent to 'user' and end up round-tripping back to a single-quoted string due to the way the declarative parser determines if the value "is output as-is to the agent" or not. For values unquoted, they are always treated as groovy code and will be round-tripped properly now.

          Keith Zantow added a comment - NOTE: !!!: To understand how this is working, you need to understand how declarative parses the files. It's using Groovy, so there are some limitations: The only case this works with double-quoted strings is when they include some expansion, e.g. "$user". If you have a plain string like "user" it will be functionally equivalent to 'user' and end up round-tripping back to a single-quoted string due to the way the declarative parser determines if the value "is output as-is to the agent" or not. For values unquoted, they are always treated as groovy code and will be round-tripped properly now.

          Michael Neale added a comment -

          dear god... ok. 

          String escaping will kill someone one day. 

          Michael Neale added a comment - dear god... ok.  String escaping will kill someone one day. 

            kzantow Keith Zantow
            michaelneale Michael Neale
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: