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

Wrong parameter type and squashing its content when trigger a job

      I have a job triggered by CI Event (JMS Messaging provider). The job has a declared parameter CI_MESSAGE of type Multi-line String Parameter, according the config.xml of the job, the parameter is

             <hudson.model.TextParameterDefinition>
                <name>CI_MESSAGE</name>
                <description></description>
                <defaultValue></defaultValue>
              </hudson.model.TextParameterDefinition>
       

      When the job is triggered by this plugin, it very ofter puts the content of this parameter as a String, according the build.xml as:

              <hudson.model.StringParameterValue>
                <name>CI_MESSAGE</name>
                <value>...content...</value>
              </hudson.model.StringParameterValue>
      

      although the definition in the same build.xml still says:

                  <hudson.model.TextParameterDefinition>
                    <name>CI_MESSAGE</name>
                    <description></description>
                    <defaultValue></defaultValue>
                  </hudson.model.TextParameterDefinition>
                </parameterDefinitions>
      

      Very rare the parameter is correctly stored in build.xml as:

              <hudson.model.TextParameterValue>
                <name>CI_MESSAGE</name>
                <description></description>
                <value>...content...</value>
              </hudson.model.TextParameterValue>
      

      and the definition is the same as previous.

      UI is confused and String parameter has a far different rendering than Text parameter.

      It is related to the other weird state - when it put the content of the parameter as String, it separate each key=value pair to separate line, when it put the content of the parameter as Text, it squash all pairs to the one line as:
      Content from hudson.model.StringParameterValue:

      <value>build=aaa
      param2=128
      url=foo</value>
      

      Equal content from hudson.model.TextParameterValue:

      <value>build=aaaparam2=128url=foo</value>
      

      I don't know what is the source of CI_MESSAGE content, but it doesn't matter - the content type should be always TextParameter, not the other one (StringParameter).

          [JENKINS-57642] Wrong parameter type and squashing its content when trigger a job

          Pavel Janoušek created issue -
          Pavel Janoušek made changes -
          Description Original: I have a job triggered by CI Event (JMS Messaging provider). The job has a declared parameter CI_MESSAGE of type Multi-line String Parameter, according the config.xml of the job, the parameter is
          {code:java}
                 <hudson.model.TextParameterDefinition>
                    <name>CI_MESSAGE</name>
                    <description></description>
                    <defaultValue></defaultValue>
                  </hudson.model.TextParameterDefinition>
           {code}
          When the job is triggered by this plugin, it very ofter puts the content of this parameter as a String, according the build.xml as:
          {code:java}
                  <hudson.model.StringParameterValue>
                    <name>CI_MESSAGE</name>
                    <value>...content...</value>
                  </hudson.model.StringParameterValue>
          {code}
          although the definition in the same build.xml still says:
          {code:java}
                      <hudson.model.TextParameterDefinition>
                        <name>CI_MESSAGE</name>
                        <description></description>
                        <defaultValue></defaultValue>
                      </hudson.model.TextParameterDefinition>
                    </parameterDefinitions>
          {code}
          Very rare the parameter is correctly stored in build.xml as:
          {code:java}
                  <hudson.model.TextParameterValue>
                    <name>CI_MESSAGE</name>
                    <description></description>
                    <value>...content...</value>
                  </hudson.model.TextParameterValue>
          {code}
          ans the definition is the same as previous.

          UI is confused and String parameter has a far different rendering than Text parameter.

          It is related to the other weird state - when it put the content of the parameter as String, it separate each key=value pair to separate line, when it put the content of the parameter as Text, it squash all pairs to the one line as:
           Content from hudson.model.StringParameterValue:
          {code:java}
          <value>build=aaa
          param2=128
          url=foo</value>
          {code}
          Equal content from hudson.model.TextParameterValue:
          {code:java}
          <value>build=aaaparam2=128url=foo</value>
          {code}

          I don't know what is the source of CI_MESSAGE content, but it doesn't matter - the content type should be always TextParameter, not the other one (StringParameter).
          New: I have a job triggered by CI Event (JMS Messaging provider). The job has a declared parameter CI_MESSAGE of type Multi-line String Parameter, according the config.xml of the job, the parameter is
          {code:java}
                 <hudson.model.TextParameterDefinition>
                    <name>CI_MESSAGE</name>
                    <description></description>
                    <defaultValue></defaultValue>
                  </hudson.model.TextParameterDefinition>
           {code}
          When the job is triggered by this plugin, it very ofter puts the content of this parameter as a String, according the build.xml as:
          {code:java}
                  <hudson.model.StringParameterValue>
                    <name>CI_MESSAGE</name>
                    <value>...content...</value>
                  </hudson.model.StringParameterValue>
          {code}
          although the definition in the same build.xml still says:
          {code:java}
                      <hudson.model.TextParameterDefinition>
                        <name>CI_MESSAGE</name>
                        <description></description>
                        <defaultValue></defaultValue>
                      </hudson.model.TextParameterDefinition>
                    </parameterDefinitions>
          {code}
          Very rare the parameter is correctly stored in build.xml as:
          {code:java}
                  <hudson.model.TextParameterValue>
                    <name>CI_MESSAGE</name>
                    <description></description>
                    <value>...content...</value>
                  </hudson.model.TextParameterValue>
          {code}
          and the definition is the same as previous.

          UI is confused and String parameter has a far different rendering than Text parameter.

          It is related to the other weird state - when it put the content of the parameter as String, it separate each key=value pair to separate line, when it put the content of the parameter as Text, it squash all pairs to the one line as:
           Content from hudson.model.StringParameterValue:
          {code:java}
          <value>build=aaa
          param2=128
          url=foo</value>
          {code}
          Equal content from hudson.model.TextParameterValue:
          {code:java}
          <value>build=aaaparam2=128url=foo</value>
          {code}

          I don't know what is the source of CI_MESSAGE content, but it doesn't matter - the content type should be always TextParameter, not the other one (StringParameter).
          Scott Hebert made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Scott Hebert made changes -
          Status Original: In Progress [ 3 ] New: In Review [ 10005 ]
          Scott Hebert made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: In Review [ 10005 ] New: Resolved [ 5 ]

            scoheb Scott Hebert
            pajasoft Pavel Janoušek
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: