Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How do you configure bamboo specs for plan branches

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.

3 answers

1 vote
Robert W Atlassian Team Jun 18, 2018

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

@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.

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.

Like # people like this

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

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.

@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

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... 

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Bamboo

Bamboo 7.1 is here and is packed with value!

I'm happy to announce that Bamboo 7.1 has been released and it’s overflowing with awesome new features. Top-voted issues First and foremost, a bunch of JAC top voted issues has been delivered - y...

621 views 1 6
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you