How do you configure bamboo specs for plan branches

[Chris Johnston]

I have a java bamboo spec configured on the configured master repository.  This works fine whenever I make a commit to master.  If the plan changes, it updates the plan and then you can run it, etc.

However, the plan uses feature branches, and is configured to create a plan branch any time a new feature-branch is created.

What I'd like to have happen, is for bamboo to also update the build plans for these feature branches.  The feature branch itself may have changes to how the builds are done.

I cannot figure out how to configure bamboo to also look for changes to the bamboo-specs build plans on the feature branches.

Any help is appreciated.

[Bruce Szalwinski]

See https://jira.atlassian.com/browse/BAM-19620

[Robert W]

Chris,

If you have Repository Stored Bamboo Specs, any time a commit is pushed to the Specs Repository, Bamboo will reconfigure the defined build plans according to the new Specs.

If you'd like to manage Plan Branches with Bamboo Specs, please refer to the Plan Branches section of the below article:

Bamboo Specs Documentation

[Vaisakh PS]

@Robert W - Good One. But how can i override the variables after creating the plan branch using Java Specs. In the above docs it's given to automatically create branches using specs, but no code samples how to update the branch specs variables. It will be much appreciated if you can give some code samples of the above req.

[Chris Johnston]

This doesn't answer the question.

I have a repository, [repository], on the master branch of that repository I have the following two areas:

bamboo-specs\

  PlanMasterPlan.java

src\

Within the configuration of Bamboo, I have spec polling enabled.  The default 'branch' of [repository] is set to master.

Within PlanMasterPlan.java amongst the other jobs/tasks it does, it sets up the plan to support plan branches,

      /* Setup plan branches */
      plan.planBranchManagement(new PlanBranchManagement()
              .createForVcsBranchMatching("feature/.*|bugfix/.*")
              .delete(new BranchCleanup()
                      .whenRemovedFromRepositoryAfterDays(7)
                      .whenInactiveInRepositoryAfterDays(30))
              .notificationLikeParentPlan());

Now, lets assume that is all deployed.  This means, that when my developer goes into bitbucket (or however) and creates a new branch called feature/JIRA-1234...

Then a new branch will be created in bitbucket for them to work, and additionally, bamboo will create a new plan branch for JIRA-1234 and compile it to achieve build #1 as per the current config spec.

Next, the developer uses git and switches to feature/JIRA-1234 branch and begins coding.

At some point, they decide the build plan needs updating, so they navigate to the bamboo-specs\ directory within branch feature/JIRA-1234 and makes changes.

They then commit those changes and push them to bitbucket.

At this point is where the problem occurs.  This push does not trigger bamboo to refresh the build plan.  Instead (assuming a trigger is enabled in the plan), it attempts to execute the plan as it is defined in the master branch (what is currently deployed in bamboo).  Of course, since the developer just made a change to it in his branch (presumably to support some new code he wrote in the same branch), this build will now fail.

The only way I can see to resolve this would be to either publish the new plan manually (in which case you might as well disable the spec polling in the repo) or push the bamboo-spec code directly to master instead of your branch.

There are lots of problems with either of these approaches.

[Roy van de Korput]

Found a solution for this @Chris Johnston ?  I see the same issue...

[Chris Johnston]

Not really.  We just taught our developers if they change the build code, they have to manually push it up if they want to validate it.  It requires some coordination since obviously if any developer does this, all other dev branches will (likely) start failing.

We created an automated job that re-publishes the build plans on a daily basis before the nightly builds kick in... just in case during the day, a developer changes it to test something, and then forgets to change it back.

[Einar Coutin]

@Chris Johnston  Even the wording on the documentation seems contradictory. From @Robert Watson link:

https://docs.atlassian.com/bamboo-specs-docs/6.5.0/specs-java.html#plan-branches

"...with the plan branch using the same build configuration as your plan...."

"

• Any new branch created in the repository can be automatically built and tested using the same build configuration as that of the parent plan.

"

vs

"

• You have the flexibility to individually configure branch plans, by overriding the parent plan, if required.

"

I can understand how the latter can be done manually, but this is a serious blocker for CI/CD efforts, even given the documentation Atlassian links to on their own documentation:

From here: https://confluence.atlassian.com/bamboo/using-plan-branches-289276872.html

To here:

https://martinfowler.com/bliki/FeatureBranch.html

"

I see CI as primarily giving birth to a release candidate at each commit. The job of the CI system and deployment process is to disprove the production-readiness of a release candidate. This model relies on the need to have some mainline that represents the current shared, most up to date picture of complete.

-- Dave Farley

" 

Isn't the whole point of branching and bamboo specs to mirror the patterns of CI and Feature branching with Distributed VCS?

If that's the case then my reasoning points to the conclusion the "bamboo specs" feature is incomplete and therefore we need the aforementioned JIRA issue fixed to have a complete solution, thanks to @Bruce Szalwinski for the link :

https://jira.atlassian.com/browse/BAM-19620

[vpogrebi]

This is NOT an answer, but rather yet another "complaint" related to Bamboo Branch Plan implementation...

What my team has learned (the "hard way") - is that when main build plan (usually associated with the 'master' branch) gets rebuilt (in our particular case - we are converting existing plans to be based on repository-stored Java specs), branch plans do not get automatically rebuilt at the same time. In a sense, branch plans kind-of "divert" - which is demonstrated in some global Bamboo variables (example: ${bamboo.planRepository_repositoryUrl} and ${bamboo.planRepository_branch}) be not set during branch plan execution at all, and instead - "numbered" variables (${bamboo.planRepository_1_repositoryUrl} and ${bamboo.planRepository_1_branch}, ${bamboo.planRepository_2_repositoryUrl} and ${bamboo.planRepository_2_branch}) are being set.

We had some script tasks that used these global variables (${bamboo.planRepository_repositoryUrl} and ${bamboo.planRepository_branch}) - which got "broken" because of this. It took use very long time (testing/debugging) to figure out what caused these issues. Now we know that whenever main plan is rebuilt - it is necessary to (manually) rebuild (delete and recreate) branch plans...