Currently we are using the monorepo strategy where we have the source code for multiple services in one repository.
When looking into YAML build plans, it seems like it's limited to one spec pr repository, ref. https://confluence.atlassian.com/bamboo/tutorial-bamboo-specs-yaml-stored-in-bitbucket-server-941616819.html
It's important to save your Bamboo Specs YAML definition in the ${repo-home}/bamboo-specs/bamboo.yml or bamboo.yaml file under the repository root.
Ideally we would want to gather the bamboo.yaml and source code for the different services into different folders and then trigger builds only if there are any changes in that specific service's folder.
Is this doable? I couldn't seem to find any documentation/questions related to monorepo and YAML builds.
Hello @Lars Kristian, welcome to the community
The feature you are looking for will be released in the next version of Bamboo.
On Bamboo 6.9, you will be able to declare multiple plans and deployments projects, using one or more files. You can try and experiment with it now, with the EAP version of 6.9 (link).
If you want to share more details, give some feedback on your current usage (or future) of Bamboo Specs with YAML, feel free to send a message at vdebone@atlassian.com
Victor
Thanks for the quick reply @Victor Debone!
What I imagine is something like this
How would the build plans be visualized/organized in Bamboo 6.9? Given that the monorepo above is branched, would you still have one build plan based on the YAML project.plan.key, where the steps then might differ from branch to branch if changes are made to bamboo.yaml? Or would you have copies of the build plan per branch which might lead to overloading the build dashboard? (I'm hoping the former since one usually creates a branch to create or make changes on one service, and there would be no point in creating duplicates of all the build plans. The build dashboard might not even be navigatable.)
Any information on when the 6.9 version is scheduled for GA? I don't think there's a possibility of getting the EAP installed for now, unfortunately. (The "link" above is not a link at the moment btw.)
Great!
I will answer them in reversed order.
To make it clear, the EAP version is not for production My suggestion of EAP was only if you wanted to check the new YAML first-hand! And for the release date, we don't keep public facing dates for releases.
On the YAML part, plan branches differing will not be part of this release. Bamboo Specs on YAML (and will for 6.9) only accepts the master branch `bamboo.yml`. Definitely this is under our radar, it is high priority for us, and you can follow its progress on this suggestion.
For the organization of the repo, this is what will be possible:
Repository├── your-service-a│ ├── files│ └── ...├── your-service-b│ ├── files│ └── ...└── bamboo-specs ├── bamboo.yml ├── your-service-a.yml └── your-service-b.yml
Would that work for you? (Apart from the lack of differing branches configurations)
Thanks,
For the repository structure, would that mean the high-level bamboo.yml have some kind of mapping saying which path belongs to the different Bamboo yml-files? So if there are changes in the path, trigger pipeline X. (For instance there is no point in running builds for documentation changes, only application code.)
your-service-a/service-a-sourcecode => your-service-a.ymlyour-service-b/sourceCode => your-service-b.yml
You are saying that the YAML build plan will only accept the master branch's bamboo.yml. Does that mean we can't even duplicate the plan configuration to a new one where the branch is explicitly set to the feature branch if we need to work on the YAML build plan(s)? We are only allowed to do that directly in the master branch?
It looks like you're new here. Sign in or register to get started.