Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Blocker
-
Resolution: Postponed
-
Component/s: multijob-plugin
-
Environment:multijob-plugin 1.25
jenkins 2.46.3
-
Similar Issues:
Description
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.
Closing issue as part of tikal-multijob-plugin issues cleanup.
If still relevant, please open a matching issue in https://github.com/jenkinsci/tikal-multijob-plugin/issues (you can refer to this issue in its description)