Each MultiJob build contains serialized references to subjob's builds. This is very, very evil because:
- the XML of the build is unnecessarily large, as it contains the complete downstream builds
- loading the build effectively reloads all downstream builds
- ... but from a different source, so you might end up with different Build objects for the same build, which leads to one of them having a parent of null, leading to wierd NPEs down the line.
Luckily, this is easy to fix:
- Make the build field transient and non-final.
- Add a final String buildid.
- On construction, set buildid to build.getExternalizableId() unless it is null.
- In the getBuild() method, first check if build is null, but buildid is not (which is the case after deserialization). Get Run.fromExternalizableId(buildid), if it is an AbstractBuild, assign to build.
- Don't do this at deserialization time. This will cause issues if relevant builds have not been fully loaded yet.
While we're at it, make the MultiJobAction in MultiJobBuilder a static class. Otherwise, the surrounding class is also serialized into the XML, and a surrounding object is recreated that is not even used and cannot be accessed.