Continuum
  1. Continuum
  2. CONTINUUM-2705

Can't build projects with null builddef fields

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4.1
    • Fix Version/s: 1.4.2
    • Component/s: None
    • Labels:
      None
    • Environment:
      linux, tomcat
    • Complexity:
      Intermediate
    • Number of attachments :
      2

      Description

      I am trying to understand the code and may be provide some fixes/patches (example: http://jira.codehaus.org/browse/CONTINUUM-2704). Checked out latest code from trunk (1.4.2-SNAPSHOT). Trying to execute a shell build when it fails. StackTrace given below. This is a new build created after running the continuum-webapp (built from trunk code) for the first time. This is not a migrated build (meaning it was a new build defined in the fresh instance).

      Screenshot of continuum UI showing the failing build (Test.sh) is also attached.

      Can someone please help? What is the reason for this error?

      StackTrace
      =========

      2013-03-05 15:42:17,691 [pool-3-thread-2] ERROR org.apache.continuum.buildmanager.ParallelBuildsManager - Null values set on build definition (id=6)
      2013-03-05 15:42:17,691 [pool-3-thread-2] ERROR org.apache.maven.continuum.scm.queue.PrepareBuildProjectsTaskExecutor - Unable to build project due to null values set on ( GOALS , ARGUMENTS , BUILD_FILE, SCHEDULE_ID_OID ) of BUILDDEFINITION ID : 6 Please notify your system adminitrator
      org.apache.continuum.buildmanager.BuildManagerException: Unable to build project due to null values set on ( GOALS , ARGUMENTS , BUILD_FILE, SCHEDULE_ID_OID ) of BUILDDEFINITION ID : 6 Please notify your system adminitrator
      at org.apache.continuum.buildmanager.ParallelBuildsManager.buildProjects(ParallelBuildsManager.java:193)
      at org.apache.maven.continuum.core.action.CreateBuildProjectTaskAction.execute(CreateBuildProjectTaskAction.java:123)
      at org.apache.maven.continuum.scm.queue.PrepareBuildProjectsTaskExecutor.buildProjects(PrepareBuildProjectsTaskExecutor.java:647)
      at org.apache.maven.continuum.scm.queue.PrepareBuildProjectsTaskExecutor.executeTask(PrepareBuildProjectsTaskExecutor.java:215)
      at org.apache.continuum.taskqueueexecutor.ParallelBuildsThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ParallelBuildsThreadedTaskQueueExecutor.java:120)
      at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
      at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
      at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987)
      at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528)
      at java.lang.Thread.run(Thread.java:662)
      2013-03-05 15:42:17,692 [pool-3-thread-2] ERROR org.apache.continuum.taskqueueexecutor.ParallelBuildsThreadedTaskQueueExecutor - Error executing task
      org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'build-project'
      at org.apache.maven.continuum.scm.queue.PrepareBuildProjectsTaskExecutor.buildProjects(PrepareBuildProjectsTaskExecutor.java:657)
      at org.apache.maven.continuum.scm.queue.PrepareBuildProjectsTaskExecutor.executeTask(PrepareBuildProjectsTaskExecutor.java:215)
      at org.apache.continuum.taskqueueexecutor.ParallelBuildsThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ParallelBuildsThreadedTaskQueueExecutor.java:120)
      at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
      at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
      at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987)
      at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528)
      at java.lang.Thread.run(Thread.java:662)
      Caused by: org.apache.continuum.buildmanager.BuildManagerException: Unable to build project due to null values set on ( GOALS , ARGUMENTS , BUILD_FILE, SCHEDULE_ID_OID ) of BUILDDEFINITION ID : 6 Please notify your system adminitrator
      at org.apache.continuum.buildmanager.ParallelBuildsManager.buildProjects(ParallelBuildsManager.java:193)
      at org.apache.maven.continuum.core.action.CreateBuildProjectTaskAction.execute(CreateBuildProjectTaskAction.java:123)
      at org.apache.maven.continuum.scm.queue.PrepareBuildProjectsTaskExecutor.buildProjects(PrepareBuildProjectsTaskExecutor.java:647)
      ... 7 more

      1. CONTINUUM-2705.patch
        3 kB
        Murali Mohan
      1. Screenshot-8.png
        116 kB

        Issue Links

          Activity

          Hide
          Brent N Atkinson added a comment -

          I saw this one as well. I was able to work around the issue by changing the type to an ant build, setting the target to 'nomatter' and simultaneously changing the type back to shell. seems like the logic for the merged ant/shell builds page needs some love.

          Show
          Brent N Atkinson added a comment - I saw this one as well. I was able to work around the issue by changing the type to an ant build, setting the target to 'nomatter' and simultaneously changing the type back to shell. seems like the logic for the merged ant/shell builds page needs some love.
          Hide
          Brent N Atkinson added a comment - - edited

          I don't think the stacktrace reported on CONTINUUM-2346 came from the reported version. I looked at ParallelBuildsManager.java:193 from 1.3.3 and the line numbers don't match up to anything meaningful. However, it appears the only field on BuildDefinition that could cause an NPE in that method is the schedule since we call buildDef.getSchedule().getBuildQueues() and buildDefinition.getSchedule().getMaxJobExecutionTime() on ParallelBuildsManager.java:201,242.

          The original fix was less than ideal because it introduced coupling to details of the various build types in a way that isn't appropriate for a generic build manager. These checks would be more appropriate as polymorphic behavior so we wouldn't have to code for every build variant.

          Also, the patch doesn't look to capture the spirit of the original rule if we're not just concerned with NPEs in the method invocation. The rule should be:

          boolean mavenBuild = MAVEN_TWO_BUILD_EXECUTOR.equals( buildDef.getType() ) || MAVEN_ONE_BUILD_EXECUTOR.equals( buildDef.getType() );
          
          if ( ( mavenBuild && buildDef.getGoals() == null ) || buildDef.getBuildFile() == null || buildDef.getSchedule() == null )
          

          The reason is that all build types need a build file:

          • shell: command
          • ant: build.xml or equivalent
          • m1/m2: project.xml/pom.xml

          They also need a schedule, but maven builds also require goals:

          • m1: goal(s)
          • m2: phase(s)

          Oddly, the build definition template interface doesn't require these for the build types.

          Show
          Brent N Atkinson added a comment - - edited I don't think the stacktrace reported on CONTINUUM-2346 came from the reported version. I looked at ParallelBuildsManager.java:193 from 1.3.3 and the line numbers don't match up to anything meaningful. However, it appears the only field on BuildDefinition that could cause an NPE in that method is the schedule since we call buildDef.getSchedule().getBuildQueues() and buildDefinition.getSchedule().getMaxJobExecutionTime() on ParallelBuildsManager.java:201,242 . The original fix was less than ideal because it introduced coupling to details of the various build types in a way that isn't appropriate for a generic build manager. These checks would be more appropriate as polymorphic behavior so we wouldn't have to code for every build variant. Also, the patch doesn't look to capture the spirit of the original rule if we're not just concerned with NPEs in the method invocation. The rule should be: boolean mavenBuild = MAVEN_TWO_BUILD_EXECUTOR.equals( buildDef.getType() ) || MAVEN_ONE_BUILD_EXECUTOR.equals( buildDef.getType() ); if ( ( mavenBuild && buildDef.getGoals() == null ) || buildDef.getBuildFile() == null || buildDef.getSchedule() == null ) The reason is that all build types need a build file: shell: command ant: build.xml or equivalent m1/m2: project.xml/pom.xml They also need a schedule, but maven builds also require goals: m1: goal(s) m2: phase(s) Oddly, the build definition template interface doesn't require these for the build types.
          Hide
          Brent N Atkinson added a comment -

          If we just want to prevent the NPEs as reported on CONTINUUM-2346, we can just check that the build definition has a non-null schedule.

          Show
          Brent N Atkinson added a comment - If we just want to prevent the NPEs as reported on CONTINUUM-2346 , we can just check that the build definition has a non-null schedule.
          Hide
          Brent N Atkinson added a comment -

          The ParallelBuildManager implementation looks strange to me. I may be misunderstanding how it's implemented. It appears as though:

          • The buildProjects method is executed for all projects for a given groupId
          • If the first project found has a null schedule, it will prevent any from being built
          • If a project in the group has a null schedule, it will prevent any subsequent from being built

          The reason is that an exception will be thrown and rather than skipping to another, it will stop the process at the first.

          Also, I'm not sure I understand why the build queues are constructed using the schedule from only the first project.

          Show
          Brent N Atkinson added a comment - The ParallelBuildManager implementation looks strange to me. I may be misunderstanding how it's implemented. It appears as though: The buildProjects method is executed for all projects for a given groupId If the first project found has a null schedule, it will prevent any from being built If a project in the group has a null schedule, it will prevent any subsequent from being built The reason is that an exception will be thrown and rather than skipping to another, it will stop the process at the first. Also, I'm not sure I understand why the build queues are constructed using the schedule from only the first project.
          Hide
          Brent N Atkinson added a comment -

          I changed the check to be less defensive and just check for NPEs chaining on builddef schedules. I checked the downstream usage of the build definition fields and they appear to be null safe.

          Fixed in r1491081.

          Show
          Brent N Atkinson added a comment - I changed the check to be less defensive and just check for NPEs chaining on builddef schedules. I checked the downstream usage of the build definition fields and they appear to be null safe. Fixed in r1491081.

            People

            • Assignee:
              Brent N Atkinson
              Reporter:
              Murali Mohan
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: