-
Bug
-
Resolution: Not A Defect
-
Major
-
None
This is due to the fact, that now all build listeners are called after every module as well. This might also break plugins.
Also, this leads to confusing behaviour when using incremental builds.
In our case, we have a huge project (~100 modules). An incremental build, which should only build about 5 modules waits for about 2 minutes (while moving through the listeners for all NOT_BUILT modules), before actually starting to work.
This was introduced by the fix for JENKINS-18846.
- is related to
-
-
- Resolved
-
[JENKINS-21597] New Maven Plugin causes slowdown for huge multimodule projects
Stephan Pauxberger
created issue -
Stephan Pauxberger
made changes -
| Description |
Original:
Also, this causes an extreme slow down, especially when using incremental build. In our case, we have a huge project (~100 modules). An incremental build, which should only build about 5 modules waits for about 2 minutes (while moving through the listeners for all NOT_BUILT modules), before actually starting to work. This was introduced by the fix for [ |
New:
This is due to the fact, that now all build listeners are called after every module as well. This might also break plugins. Also, this leads to confusing behaviour when using incremental builds. In our case, we have a huge project (~100 modules). An incremental build, which should only build about 5 modules waits for about 2 minutes (while moving through the listeners for all NOT_BUILT modules), before actually starting to work. This was introduced by the fix for [ |
| Summary | Original: New Maven Plugin causes build listeners to be called after the completion of every module, causing a lot of plugins to break | New: New Maven Plugin causes slowdown for huge multimodule projects |
Stephan Pauxberger
made changes -
| Link |
New:
This issue is related to |
Stephan Pauxberger
added a comment - The actual slowdown was due to a bug in a plugin of mine. Still, some plugins like gerrit-trigger or build-failure-analyzer now behave differently. For example, bfa prints whole screens full of messages for each module.
Basically, all plugins using RunListener can be effected.
Problem is, they not simply exclude MavenBuild s from being handled, because that would introduce unwanted dependencies to maven-plugin.
Stephan Pauxberger
added a comment - The actual slowdown was due to a bug in a plugin of mine. Still, some plugins like gerrit-trigger or build-failure-analyzer now behave differently. For example, bfa prints whole screens full of messages for each module.
Basically, all plugins using RunListener can be effected.
Problem is, they not simply exclude MavenBuild s from being handled, because that would introduce unwanted dependencies to maven-plugin. Other plugins can for example check whether a Job is also a TopLevelItem.
| Resolution | New: Not A Defect [ 7 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
| Workflow | Original: JNJira [ 153595 ] | New: JNJira + In-Review [ 194606 ] |
I guess you mean due to https://github.com/jenkinsci/jenkins/commit/a92e9da978262c6a7e4d74d3b2750319cbc748fb#diff-ead68b986d300f65900815117a8aa40aR502 but this behavior is correct I think. And which RunListener implementation(s) are actually being slow in this context, or causing “confusing behavior”? Possibly really a bug in another plugin.