-
Bug
-
Resolution: Fixed
-
Major
-
None
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
added a comment - No Aleks, I was surprised too... The second part of the description is correct, squashing is realized when TextParameterValue is used... The thing why you don't see a correct rendering in the second case (when StringParameterValue is used) is that even in this case you have pairs split by EOL, they are rendered as text input box content (single line). In build.xml they are stored correctly:
<hudson.model.StringParameterValue>
<name>CI_MESSAGE</name>
<value>key1=val1
key2=val2
key3=val3</value>
</hudson.model.StringParameterValue>
Pavel Janoušek
added a comment - No Aleks, I was surprised too... The second part of the description is correct, squashing is realized when TextParameterValue is used... The thing why you don't see a correct rendering in the second case (when StringParameterValue is used) is that even in this case you have pairs split by EOL, they are rendered as text input box content (single line). In build.xml they are stored correctly:
<hudson.model.StringParameterValue>
<name>CI_MESSAGE</name>
<value>key1=val1
key2=val2
key3=val3</value>
</hudson.model.StringParameterValue>
We were actually hardcoding the use of StringParameterValue instead of looking at what the job was using for its CI_MESSAGE parameter.
I am working on a fix with proper tests for this use case.
You can try out a patched version with a fix here: https://ci.jenkins.io/job/Plugins/job/jms-messaging-plugin/job/PR-124/1/artifact/target/jms-messaging.hpi
Pavel Janoušek
added a comment - Thank you scoheb for the quick fix. I don't have any job/workflow for JMS Messaging plugin, so can you akostadinov verify if it works for you please?
Pavel Janoušek
added a comment - Thank you scoheb for the quick fix. I don't have any job/workflow for JMS Messaging plugin, so can you akostadinov verify if it works for you please? Pavel Janoušek
added a comment - Thank you very much Scott! 
I'd like to add that this is a huge problem for the job rebuild plugin. Because it seems to respect the type given by the jms-messaging-plugin instead of config.xml. This removes new lines from text parameter so job can't be effectively rebuilt.
P.S. maybe second part of description needs to be changed because removing of new lines happens with String rather than Text param. Or possibly I misread it.