MavenModuleSetBuild.getResult looks for the worst result of any of the last builds of the component modules. If you are using Maven 2, some of these might have been run after the MavenModuleSetBuild itself completed, either because you build modules in parallel, or because you manually rebuilt one of the modules; in such cases the result of the module set can be retroactively worsened. (Although Run.setResult is only permitted while building, getResult is nonfinal, effectively a backdoor to get around that restriction.)

      Besides the logical confusion over whether a given build of a job was successful or not, this logic is very problematic for lazy-loading:

      at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:496) 
      at hudson.model.AbstractProject.getNearestOldBuild(AbstractProject.java:1067) 
      at hudson.maven.MavenModuleSetBuild.getModuleLastBuilds(MavenModuleSetBuild.java:434) 
      at hudson.maven.MavenModuleSetBuild.getResult(MavenModuleSetBuild.java:189) 
      at hudson.model.PermalinkProjectAction$Permalink$3.apply(PermalinkProjectAction.java:134) 
      at jenkins.model.PeepholePermalink.resolve(PeepholePermalink.java:95) 
      at hudson.model.Job.getLastSuccessfulBuild(Job.java:802)
      

      For example, every time the Maven job is displayed in a view, getResult is called at least once for the icon color. (Probably also to verify the permalink even when the symlink such as lastSuccessfulBuild exists, which after JENKINS-16023 it should.) But this forces the most recent build of each module to be loaded, too, and if there are a lot of modules that can take significant time, either after startup or after some have been evicted from memory.

      Not clear what can be done here. Options:

      1. Delete this override and break functional compatibility. Means that jobs using parallel module building will not show meaningful status.
      2. Suppress the override in case the job is currently configured to use Maven 3, which does not support the trigger conditions to begin with. But it is not trivial to tell this; a MavenInstallation will resolve to a specific version only during a build (it might not exist at all on the master).
      3. Store the current effective result in build.xml and use some listener to update it after relevant module builds.

          [JENKINS-18895] MavenModuleSetBuild.getResult is expensive

          Jesse Glick created issue -
          SCM/JIRA link daemon made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]
          Jesse Glick made changes -
          Resolution Original: Fixed [ 1 ]
          Status Original: Resolved [ 5 ] New: Reopened [ 4 ]
          SCM/JIRA link daemon made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: Reopened [ 4 ] New: Resolved [ 5 ]
          James Nord made changes -
          Labels Original: lazy-loading performance New: lazy-loading lts-candidate performance
          Oliver Gondža made changes -
          Labels Original: lazy-loading lts-candidate performance New: lazy-loading lts-1.509.3-fixed performance
          Oliver Gondža made changes -
          Labels Original: lazy-loading lts-1.509.3-fixed performance New: 1.509.3-fixed lazy-loading performance
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-25075 [ JENKINS-25075 ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 150342 ] New: JNJira + In-Review [ 193477 ]

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: