-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
1.634 or higher + Batch Task Plugin
The Batch task history panel is empty (Find pane only) since the 1.634 version.
Maybe linked, a blocking bug has been introduced within the 1.633 version (cf. JENKINS-30820) that impeded to add any batch task on job.
I guess the bug comes from the core but maybe the Batch Task Plugin should be upgraded 
Use case
To reproduce:
- install the Batch Tasks plugin
- create an empty freestyle job with Batch tasks option (echo "Hello world")
- run a build
- run the task several times
- look at the task build history (/job/<job name>/batchTasks/task/<task name>/)
Tested with 1.616, 1.632: the batch history panel displayed all the builds.
Tested with 1.633: cannot access to my job. Create a new one, cannot create Batch task because of ClassNotFoundException: org.jenkinsci.lib.envinject.service.EnvVarsResolver
Tested with 1.634, 1.642.3: the batch history panel is empty (Find pane only)
- links to
[JENKINS-33833] Lost the batch task history since 1.634
I checked out this plugin source, set the pom.xml to use Jenkins 1.632 and configured a job as described above. Even with 1.632 it looks a bit screwed up for me. See the screenshot....
Yeah is related to the build history widget for certain. Would need to dedicate some time to fixing this.
tfennelly The icon issue (screwed up display in Jenkins version 1.632) would be solved by JENKINS-24581, see the pull request there.
Started to look at this, but looks like it's not a quick fix. Either core needs to be altered in some way to allow the current BatchRun implementation to work (non-trivial - BatchRun extends Actionable, which doesn't have all of the necessary API methods provided by Run), or the BatchRun needs to extend Run, which is problematic because BatchRun build numbers are String}}s like {{"3-3", rather than the int}}s specified in {{Run. To preserve any history, a migration effort would have to be done.
lacostej
added a comment - I have made some progress on this issue, and would love to have feedback on the implementation.
lacostej
added a comment - I have made some progress on this issue, and would love to have feedback on the implementation .
lacostej
added a comment - After exploring a few ideas, I am a bit stuck as it seems I won't be able to solve this without either a major rework of the plugin, or some changes in the core.
As rysteboe noticed earlier, the history widget doesn't work anymore for the BatchRuns because the HistoryPageFilter supports QueueItems or Run subclasses.
Here's a summary of my attemts
| attempts | results |
|---|---|
| Make BatchRun a Run subclass | This has the benefit of removing quite a bit of code duplication in BatchRun. But this causes serialization issues, as Run subclasses are only allowed at top level to their own XML. This would require heavy migration of the BatchRun data outside of the build.xml files |
| Pass Run/Job adapters to the build history widget. | This has the benefit of I guess reducing the amount of migration work. But the Run instance state is self managed by the Run class, meaning I am unable to initialize some of its state (e.g. Result) while constructing the classes. This means that the history has wrong information about the Runs. |
I haven't yet tried to implement it as a QueueItem, but I assumed that Rebecca discarded this on some ground.
Any thoughts?
lacostej
added a comment - After exploring a few ideas, I am a bit stuck as it seems I won't be able to solve this without either a major rework of the plugin, or some changes in the core.
As rysteboe noticed earlier, the history widget doesn't work anymore for the BatchRuns because the HistoryPageFilter supports QueueItems or Run subclasses .
Here's a summary of my attemts
attempts
results
Make BatchRun a Run subclass
This has the benefit of removing quite a bit of code duplication in BatchRun.
But this causes serialization issues , as Run subclasses are only allowed at top level to their own XML. This would require heavy migration of the BatchRun data outside of the build.xml files
Pass Run/Job adapters to the build history widget.
This has the benefit of I guess reducing the amount of migration work.
But the Run instance state is self managed by the Run class, meaning I am unable to initialize some of its state (e.g. Result ) while constructing the classes. This means that the history has wrong information about the Runs.
I haven't yet tried to implement it as a QueueItem, but I assumed that Rebecca discarded this on some ground.
Any thoughts?
I'll have a look.