-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
* Template1:
** Multiple SCMs:
*** Git[subprojectA]: git://server/subprojectA.git
*** Git[subprojectB]: git://server/subprojectB.git
* ProjectJob:
** Multiple SCMs:
*** Use SCM from another job: Template1
*** Git[project]: git://server/project.git
Using a configuration similar that outlined in the Environment field, Jenkins is unable to parse the changelog.xml file, because it results in a nested CDATA section. That is because Multiple-SCMs creates an XML structure similar to:
<multi-scm-log> <sub-log scm="hudson.plugins.git.GitSCM"> <![CDATA[Changes in origin/master ... ... ...]]> </sub-log> <sub-log scm="hudson.plugins.git.GitSCM"> </sub-log> </multi-scm-log>
That works fine for just the multiple-scm configuration. But when combined with the template-project "Use SCM from another project" option, the sub-log itself is completely wrapped in CDATA, thus resulting in an invalid XML document (it is invalid to nest CDATA sections):
<multiple-scms> <sub-log scm="hudson.plugins.git.GitSCM"> <![CDATA[Changes in origin/master, ... ... ...]]> </sub-log> <sub-log scm="hudson.plugins.templateproject.ProxySCM"> <![CDATA[<multiple-scms> <sub-log scm="hudson.plugins.git.GitSCM"> <![CDATA[Changes in projectA/master, ... ... ...]]> </sub-log> <sub-log scm="hudson.plugins.git.GitSCM"> <![CDATA[Changes in projectB/master, ... ... ...]]> </sub-log> </multiple-scms>]]> </sub-log> </multiple-scms>
As you can see, the GitSCM sub-log entries here are wrapped in CDATA, but the ProxySCM entry was already wrapped in CDATA.
Ideally, CDATA should only be used if needed (e.g., in this case, the nodes could simply be nested, and only use CDATA around the actual commit data [from GitSCM]).
- is related to
-
JENKINS-14099 Excessive exception logging
-
- Resolved
-
To elaborate, I think the problem is that ProxySCM should avoid the CDATA entirely, because it should be understood that the remote ("proxied") SCM will already use CDATA where it needs to:
That way, even if ProxySCM uses only a single remote GitSCM configuration, it is still valid. I haven't looked into the code, so the problem may actually be Multiple-SCMs using CDATA all the time, when it is only necessary for the actual final SCM log data. That may be difficult to determine though, since neither plugin was probably designed to work with the other. In our case though (as mentioned in the Environment field above), this combination is actually very useful, and we use it for dozens of jobs. It works well in general, the only thing that fails is the changelog parsing (which in turn causes our log file to fill up because of the error in parsing the changelog.xml file)