Continuum

Scheduled build loses track of proper reactor order after a release

Details

  • Type: Bug Bug
  • Status: Reopened Reopened
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 1.1
  • Fix Version/s: 1.4.1 (Beta)
  • Component/s: Web interface
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    2

Description

After a release, the scheduled build fails because the build order doesn't start with the parent. The parent doesn't get built first because the last build status of the parent is already green--and so builds the submodules first. To work this out, a manual build should be triggered.

Issue Links

Activity

Hide
Nap Ramirez added a comment -

If the build order is dependent on the previous build state of a project, I'd like to suggest resetting the build state of newly released projects so the build order won't get messed up. Besides, the project was already released and the build state refers to the previous version.

Wdyt?

Show
Nap Ramirez added a comment - If the build order is dependent on the previous build state of a project, I'd like to suggest resetting the build state of newly released projects so the build order won't get messed up. Besides, the project was already released and the build state refers to the previous version. Wdyt?
Hide
Nap Ramirez added a comment -

I tried addressing this issue with my suggestion, but it didn't work. I built a multimodule project (with inter-module deps), and released it. When the scheduled build triggered, nothing was built. Seems I was wrong to rely on the build state in determining the build order. But the weird thing I observed was the way scheduled builds treat projects with changes, as it was different when forcing a build. I can't say anything definite yet, I just based it on the event logs. I'm digging deeper into this.

Show
Nap Ramirez added a comment - I tried addressing this issue with my suggestion, but it didn't work. I built a multimodule project (with inter-module deps), and released it. When the scheduled build triggered, nothing was built. Seems I was wrong to rely on the build state in determining the build order. But the weird thing I observed was the way scheduled builds treat projects with changes, as it was different when forcing a build. I can't say anything definite yet, I just based it on the event logs. I'm digging deeper into this.
Hide
Nap Ramirez added a comment -

Attached a tarball of the multimodule project I used for this issue (multimodule-project.tar.gz).

It contains:

multimodule-parent
  |
  +-- submodule-one
  |
  +-- submodule-two
  |
  +-- submodule-three

three depends on one, one depends on two. So the the build order should go parent->two>one->three.

Show
Nap Ramirez added a comment - Attached a tarball of the multimodule project I used for this issue (multimodule-project.tar.gz). It contains:
multimodule-parent
  |
  +-- submodule-one
  |
  +-- submodule-two
  |
  +-- submodule-three
three depends on one, one depends on two. So the the build order should go parent->two>one->three.
Hide
Nap Ramirez added a comment -

Some more observations:

1. Added the multimodule project in continuum
2. forced a build of the project group (build order was correct)
3. released the project group
4. wait for a scheduled build (build order was correct, but skipped building the parent)

Show
Nap Ramirez added a comment - Some more observations: 1. Added the multimodule project in continuum 2. forced a build of the project group (build order was correct) 3. released the project group 4. wait for a scheduled build (build order was correct, but skipped building the parent)
Hide
Nap Ramirez added a comment -

Attached the logs of the scheduled build right after the release (continuum.log).

Show
Nap Ramirez added a comment - Attached the logs of the scheduled build right after the release (continuum.log).
Hide
Maria Catherine Tan added a comment -

Fixed in rev 699165

Show
Maria Catherine Tan added a comment - Fixed in rev 699165
Hide
Wendy Smoak added a comment - - edited

http://svn.apache.org/viewvc?view=rev&revision=699165 includes:

 +        //CONTINUUM-1815: additional check for projects recently released
 +        if ( !continuumProject.getVersion().equals( project.getVersion() )
 )
 +        {
 +            getLogger().info( "Found changes in project's version ( maybe project was recently released ), building" );
 +            return true;
 +        }

This is causing problems in CONTINUUM-1979, because the release triggers the next scheduled build (which is a release) in an endless loop.

Show
Wendy Smoak added a comment - - edited http://svn.apache.org/viewvc?view=rev&revision=699165 includes:
 +        //CONTINUUM-1815: additional check for projects recently released
 +        if ( !continuumProject.getVersion().equals( project.getVersion() )
 )
 +        {
 +            getLogger().info( "Found changes in project's version ( maybe project was recently released ), building" );
 +            return true;
 +        }
This is causing problems in CONTINUUM-1979, because the release triggers the next scheduled build (which is a release) in an endless loop.
Hide
Maria Catherine Tan added a comment -

We need to revert changes made to this

Show
Maria Catherine Tan added a comment - We need to revert changes made to this
Hide
Maria Catherine Tan added a comment -

I tried this in the continuum-flat-multi-module branch and using a single checkout directory for a multi-module project fixes this problem. So i'm changing the fix version for this to 1.4.0

Show
Maria Catherine Tan added a comment - I tried this in the continuum-flat-multi-module branch and using a single checkout directory for a multi-module project fixes this problem. So i'm changing the fix version for this to 1.4.0

People

Vote (2)
Watch (2)

Dates

  • Created:
    Updated: