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

Characters not being escaped correctly, resulting in unknown task

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: gradle-plugin
    • Labels:
      None
    • Environment:
      gradle-plugin: 1.24
      Jenkins: 1.656
    • Similar Issues:

      Description

      In the output log this command below produced a "Task not found" error

      Command:
      cmd.exe /C "gradle.bat -DghprbTargetBranch=master... '"-DghprbPullLongDescription=It was found that ANYvalid NEC format IR code would trigger a \""force occupied\"" event...

      Error:

      • What went wrong:
        Task 'occupied"" event...' not found in root project 'jUnit'.

      It appears that the quotations are not being escaped correctly in this instance, causing gradle to think that the text of DghprbPullLongDescription is a task.

      The text as posted on github is as follows:
      It was found that ANYvalid NEC format IR code would trigger a "force occupied" event...

        Attachments

          Activity

          Hide
          robcook124 Robert Cook added a comment -

          Looks as if development on this plug-in may have halted some time ago, but on the slight chance I am wrong... It appears to me that the plug-in is grabbing all environment variables set in the job and adding them on via the -D option, which is why a ghprb variable appears in the command. Not sure of the reasoning behind this as it seems inefficient and could easily fail the command as seen here. A suggestion would be to instead let the user decide what to pass on.

          Show
          robcook124 Robert Cook added a comment - Looks as if development on this plug-in may have halted some time ago, but on the slight chance I am wrong... It appears to me that the plug-in is grabbing all environment variables set in the job and adding them on via the -D option, which is why a ghprb variable appears in the command. Not sure of the reasoning behind this as it seems inefficient and could easily fail the command as seen here. A suggestion would be to instead let the user decide what to pass on.
          Hide
          gsimpson George Simpson added a comment -

          Hi Robert,
          Development stalled a bit. We have managed to merge a few PRs and would like to release a new version over the summer. If you want to submit a PR I will gladly merge it. If that's not possible, I will gladly take a look at this issue later in the summer. Thanks for going to the effort of testing this.

          Show
          gsimpson George Simpson added a comment - Hi Robert, Development stalled a bit. We have managed to merge a few PRs and would like to release a new version over the summer. If you want to submit a PR I will gladly merge it. If that's not possible, I will gladly take a look at this issue later in the summer. Thanks for going to the effort of testing this.
          Hide
          wolfs Stefan Wolf added a comment -

          This should be fixed now. Please try 1.27.1 and re-open if necessary. Note that you can now opt-out of passing all parameters as system properties to Gradle.

          Show
          wolfs Stefan Wolf added a comment - This should be fixed now. Please try 1.27.1 and re-open if necessary. Note that you can now opt-out of passing all parameters as system properties to Gradle.

            People

            Assignee:
            wolfs Stefan Wolf
            Reporter:
            robcook124 Robert Cook
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: