-
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 assure you that the steps to reproduce are complete; with 1.632 (or older versions) and 1.634 (or newer versions) and without installing the EnvInject Plugin, you don't have this issue (ClassNotFoundException: org.jenkinsci.lib.envinject.service.EnvVarsResolver).
As a remark, with the 1.633 version, we have the issue with or without the EnvInject Plugin.
This issue makes the batch tasks hard to use: while the task is not executing, you don't see the waiting build and cannot know if the build request worked or even happened.
danielbeck, please link it with JENKINS-26445 if you think it's related. Why do you think so? Or maybe are you talking about one of it's subtasks or a side effect? JENKINS-26445 resolution dates and versions do not match. Did you mean that JENKINS-30899 introduced the regression?
Julien Carsique
added a comment - - edited This issue makes the batch tasks hard to use: while the task is not executing, you don't see the waiting build and cannot know if the build request worked or even happened.
danielbeck , please link it with JENKINS-26445 if you think it's related. Why do you think so? Or maybe are you talking about one of it's subtasks or a side effect? JENKINS-26445 resolution dates and versions do not match. Did you mean that JENKINS-30899 introduced the regression? jcarsique The fix for JENKINS-26554 was introduced in 1.633, refined in 1.634, and changes how the sidepanel build history works. So, one of the two, but they're closely related.
I looked deeper into the code trying to understand the cause of the issue.
I'm pretty sure that the changes on build history, pagination and so on, done by tfennelly (seen in Comparing changes 1.632...1.633), could explain the empty pane for batch tasks.
Indeed, from the Batch Task Plugin, BatchRun extends Actionable only. I did a quick test to make this class extends Queue.Item, here the results:
Not so good but Tom, maybe you see from where the issue comes from.
Thanks for your help
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?
envinject is not a dependency of Batch Tasks Plugin, so whatever is going on here, your steps to reproduce are incomplete.