Why does Bamboo rescan all plans when using Java inheritance?

[Kevin Matlock]

I have Bamboo Specs implemented for my build server hosting around 50 build and deploy plans.  All of this works great!

When I first setup all my Specs I had each plan represented by its own class file and commits made to any one of these classes resulted in only that plan being rescanned and updated; so far, so good.

I wanted to make my Specs source a little more supportable so I implemented some base classes in my Java source just to store common strings, etc.   All my build plans extend a single "build base" class and all my deploy plans extend a single "deploy base" class... then both of these base classes extend a common "plan base" class.  Functionally speaking, this also works well and I can make overarching changes whenever I need to without a lot of duplicated effort.

The problem comes from the fact that now when I make a change to any single plan classes, and make no changes to any of my base classes whatsoever, the Specs scanner always  senses that all plans have been modified so it builds every single one, every time I push a commit.  This isn't really a huge issue, but it's somewhat annoying in that all plans' history becomes cluttered with bogus Specs execution messages, even when they technically changed.  It's pretty difficult to know which particular plan was truly changed by looking at the Bamboo UI.

Seems to me that the Specs scan engine is tricked into sensing a change in a plan simply based on the normal rebuilding of inherited classes.  Is there any way I can avoid the rescan of unchanged plans and still use inheritance in my Specs project?

Thanks very much!

[Daniel Santos]

Hi @Kevin Matlock

I believe that the main issue is the fact that specs builds are shown as build results. It, therefore, leads developers to think that a new configuration was applied to those plans and also creating clutter to build results.

The fix would require removing the specs results from the build results section. We have a feature request for that:

• [BAM-20149] Add option to have Specs update events to NOT be considered as a build

Right now I don't see another option to solve this problem other than creating different repositories for each plan (which does not sound like a reasonable solution).

Please vote and set yourself as a watcher in the feature request above. That will help us to prioritize this issue and also send you new updates in case we have news about it.

[Kevin Matlock]

Hmmm, that's too bad but glad it wasn't something that I was doing incorrectly.  Ok, I'll vote the feature up; thanks for the clarification on the Bamboo behavior.

[Daniel Santos]

No, you are not doing something wrong.
Thank you for voting and you are welcome!

[Kevin Matlock]

I did offer a suggestion as to the "mixing" of the build output with that of the Specs update event.  That said, I do still feel that there's more to my issue. 

Let me try to simplify my question again - ever since I refactored my Specs Java source project to contain class hierarchy, any time I make a change to any single plan spec, ALL my plans are viewed as being updated, thus they all are rebuilt.  I could understand that if I made a change to one of my base classes, this would trigger a modified event for any extending class, but that's not the behavior that I'm seeing - any change to a single plan is enough to rebuild all of my plan specs.

Hope that clarifies my problem.

EDIT/ADDENDUM: Yes, I've confirmed that all my plans have an iterated build number associated with them, even though I made no modifications to them or one of their base classes.

[Victor Debone]

Hello @Kevin Matlock thanks for sharing your concerns :)

On the case of BAM-20149, your plans would not have their build numbers or build results used by updates of Specs. And from what you have described, that's your intended behavior. 

I think the way Bamboo process the Specs is an internal behavior that should not be of concern for our users and the intended effect of having the builds was to demonstrate that your plan had a change. Given the nature of Specs and how it can have multiplicative effects like the one you are experiencing, having the extra builds was not optimal and we are considering other options on how we can tackle it.

Does that answer you? :)

[Kevin Matlock]

I'm not sure if I understand your reply.  Are you acknowledging that Bamboo has undesired behavior where it rebuilds all plans, regardless if a plan has been modified or not, any time you use base classes within the Specs Java project?

Is the only work-around to not use any OO/Java 'extends' within the Specs project?

[Victor Debone]

Oh, not really. I intended to communicate that from the user perspective, you should not be worried about how Bamboo process the Specs changes. You as a user must be able to use Bamboo Specs the way it suits you the best and see that the affected plans were changed, nothing else. What is happening now is not an optimal behavior.

Currently, on the latest version of Bamboo, which still doesn't fix BAM-20149, if you want to work around not having every plan getting a new "Specs build", then yes, you are probably looking into not having use of base classes. Though we don't think that it's an optimal choice given the trade-offs.