I noticed that if you have the Subversion plugin installed and a
jobs/*/builds/*/build.xml contains
<hudson.scm.SubversionTagAction>
<build class="build" reference="../../.."/>
</hudson.scm.SubversionTagAction>
then whenever you visit the job page you get
<time...> hudson.ExpressionFactory2$JexlExpression evaluate
WARNING: Caught exception evaluating: it.isTagged(). Reason:
java.lang.NullPointerException
java.lang.NullPointerException
at hudson.scm.SubversionTagAction.isTagged(SubversionTagAction.java:158)
...
and this is thrown on every reload of the page, which can quickly fill up the
log. (Thrown from SubversionTagAction/tagForm.jelly.)
Now clearly the build data is invalid - SubversionTagAction includes a 'tags' field which is missing in the serialized XML. How this invalid XML got written to begin with
is another question, but for now I am wondering how Jenkins is supposed to recover. When build.xml contains unrecognized sections, the loading of the build is skipped,
the console shows the problem once during Jenkins startup, and the /manage page shows a link to try to save corrected configuration by deleting unrecognized sections -
all reasonably friendly.
But apparently a missing field in an Action does not trigger the "something broken" logic. Is SubversionTagAction supposed to override readResolve to ensure that 'tags'
is defined to something non-null? (or throw an exception if it is not?) Or is XStream supposed to notice that there is no stored value for this final field and throw an
exception eagerly while loading build.xml? In other words, what is the general policy for detecting and addressing problems caused by incomplete or malformed stored XML?
