nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Hooking Stash into Bamboo with some fidelity

Scott Molinari

Hi,

We have a use case, where we want to create/ build web development environments on the creation of different branches on a repo in Stash (through branching in Jira!!!). However, from what I can see currently and with my limited knowledge of Stash and Bamboo, we can only trigger one certain build plan in Bamboo per post-recieved activity on our repo. In other words, no matter what we do with our repo in Stash, it will only mean "Do only the builds in plan X" to Bamboo.

Is there any way to get more fidelity out of Stash to make Bamboo work certain build plans at will?

Scott

Accepted answers

All comments

Scott Molinari

Also a note. We are working towards a completely cloud based system, which means our devs won't be able to have local dev environments set up. So, to fit our needs, we'd also even need to determine the difference between a push/ pull and branching and merging.

Branching = build the dev environment
Merging = kill/ clean up environment
Push to origin/ Stash = do testing, if good, update environment with new code (this is all I have working currently!)

What we don't want is to have to merge to move every change/ additional work the dev does, because he is using his own environment to test his own work (this is very, very important!!!). He should just push to his branch on the origin, Bamboo does any testing, if tests pass, the development environment "in the cloud" gets updated with the changes and the dev sees them in his browser for his environment.

If he is satisfied with his work, he would then create a pull request for his branch. The work would be reviewed, in his dev environment. If the reviewers give a go, the merge is completed. The branch is removed along with the dev environment.

Is this too far fetched an idea to get done with Stash and Bamboo?

Scott

Scott Molinari

Hmm....I don't know why, but the Fork button just popped into my face. Is there a way to fork instead of branch in Jira? Is there a way to automate forking to also hook into Bamboo? That could get us the fidelity we need. The better solution would be simply to be able to define hooks per action in Stash....

I must be missing something, because I can imagine other dev processes would need much more fidelity between the two systems. At any rate. I hope you can help us.

Scott

cofarrell

Hi Scott,

Sounds like an interesting setup.

Can you setup Bamboo to create a plan with auto branching (plus a webhook if you want)? That will then run a script that can detect the branch and act accordingly.

Regarding Forks, personally I don't think they will help. Or at least, it's much harder to detect them from within Bamboo (or any CI system). You would have to fire and listen for custom fork events from Stash in Bamboo, otherwise you have no easy way to tell when they are created. In many cases you may not even have permissions to view them. Using branches is much easier because it's all controlled centrally in one repository.

Does that help?

Charles

Scott Molinari

I think I've read over that plan branching page about 5 times and just never could really visualize how Jira, Stash and Bamboo play together in order to fit our needs.

If I half-way understand, this would be the workflow.

1. A branch would be created in Jira off of the develop branch (we are following the Gitflow system). Bamboo notices the branch (within 300 seconds, or faster, should we change the inverval) to start a plan branch plan off of the develop branch. With the plan branch, we could also create the dev environments for each branch (? unsure about this and how it could be set up).

2. The dev or devs would then get to work and be pushing changes to their new branch and the web hook would call a separate project/plan to carry out any testing and to update the dev environments with any pushed changes. (We'll have to assume at first, this won't raise any conflicts.) Still it would be nice to get some fidelity in the hooks here too.

3. Once the dev or devs are finished, they'd start a pull request to merge their work back into the develop branch. The reviews and any additional testing get carried out and the merge takes place, when all is well. Bamboo notices the merge and carries out any clean-up work including removing the dev environment (? unsure about this too and how it could be set up).

Is this a correct understanding of what is possible? If it is, cool. Then I think we can try this and see what happens.

Scott

cofarrell

Scott,

That's basically right.

1. Be a little careful about changing the interval to be too frequent. The biggest performance problems we notice are with CI servers polling Stash, which is where the webhook comes in.

Having a wehook means you should be able to keep the default polling setting, as the webhook will include created/deleted branches. The plan branch would then have to deleted if this is the first time it has run, and then create the dev environment. How this works will really depend on the infrastructure you're using.

2. Not sure what you mean by conflicts? The plans will never get any conflicts as they will always just take the latest change that is on the branch. You only time you get conflicts is when you try to merge between your dev branches and "develop", which will need to be manually fixed by someone.

3. This might be the slighly tricky part. As fair as I know Bamboo will "disable" any branch builds once it detects the branch has been deleted, and I can't think of anything else it could do under the circumstances. You will probably need to have a special buil/script for the"develop" branch that detects this and removes the associated environment. It is definitely possible though.

You should absolutely give it a go. Let us know if you get stuck on the integration, but most of the more complicated aspects will be in your build/scripts themselves.

Charles

Scott Molinari

Ok. (this got long winded, bear with me please.:))

Step 1 is somewhat clearer now. I've set up a plan branch for the develop branch of the repo. When it branches, for like when a feature branch or a bug fix branch is created through Jira, a plan branch is created. Good to go and I can create the dev environment from there with one or more Jobs/ SSH scripts.

Is there anyway to lower the 5 minute poll time to create a plan branch?

And there are some things I am still not clear on with the processes possible with a plan branch, once it is created (or is it even possible?)

1. Bamboo itself writes on the empty History page of a plan and plan branch:

Bamboo builds everything whenever source code repository changes.

What does "changes" mean exactly? What does it look for or consider as a change? Does Bamboo look for changes only on the branch noted in the , or the whole repo? This is not clear and my testing hasn't made it any clearer. Pushes are changes but don't seem to get noticed by Bamboo. I've notice the check out task is always added to

2. Can I overide the plan tasks/ stages with a certain plan branch, when things change only for the branch? I think I am back to my fidelity issue again. It isn't so important though, as I think I've figured out a way to do this with a second plan and a web hook.

What I seem to be missing is how Bamboo can be completely dynamic following any actions taken in Stash on a particular branch. I just don't see any real connection and reading all of the Questions put up for better web hooking, it looks like this fidelity is really a problem.

Scott

Scott Molinari

I would have posted as a comment, but the spambo says it is spam. Holy cow....

To 1. So a detected change is a new commit on the branch in Stash, but only since the last fetch? When are fetches carried out? Does that have to do with the default fetch task that is always in a newly created job? Because, that is the first thing I delete, when I create a new job.....I am confused.:)

Too bad with the poll time for plan branches. I guess the general rule will be, plan to go get a coffee, when you want start a new branch. LOL!:-D Strange that polling for a new plan branch can only be done every five minutes, but polling for changes can be set at will (but are only noticed, if there was a fetch).

You said polling and the server load is an issue with a good number of customers. It might be, because of the missing fidelity I am talking about? Basically, anyone should be able to "connect" an action in Stash to fire off an explicit plan in Bamboo. This simply isn't possible in an automated way other than by lowering the polling time. It is funny too. I read something about selecting the "let the repo trigger Bamboo" to lower the load on the system. But, it just isn't possible to create a web hook automatically or even without intimate git knowledge or knowing there is a plug-in for this, nor is it possible to differentiate between actions in the repo on which a web hook should fire on. It simply fires for all changes. It would be cool, if at least the web hook could fire for actions only on a certain branch. Best wish would be, it can fire off for certain git actions.

I've also noticed a good number of questions about triggering. Just search for the words bamboo, trigger and stash. I'd venture to say, this is an area, where work needs to be done on the integration between Stash and Bamboo.:-)

Actually, I just did some searching and started found two interesting suggestions.

https://jira.atlassian.com/browse/STASH-3885

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

The last one is exactly my to issues here. Polling and missing fidelity in Stash to control Bamboo.

My open two questions are.

When are fetches carried out in Bamboo? Does that have to do with the default fetch task that is always in a newly created job?

Scott

James Dumay

Hi Scott,

If you need to lower the detection time of branches within Bamboo, take a look at the documentation here. There is a section in the administration that can allow you to do this.

When a Plan Branch is create for a branch, it automatically uses all the build configuration for the plan that it was created for.

The Bamboo team is working on a new Stash repository type that will be released shortly. While it doesn't have any ability for the repository to trigger the build out of the box today (and have all the hooks registered on the Stash side), we will be adding something like that in the future.

I hope this information helps and let me know if you have any more questions.

Thanks

James

Scott Molinari

Actually, I've started a new question.

https://answers.atlassian.com/questions/254012/when-does-bamboo-do-fetches-in-plan-branches#

Scott

Scott Molinari

My issue isn't with the polling time of already created plan branches, but rather the polling time for creating plan branches themselves. It is fixed at 5 minutes! It says this right in Bamboo

Automatically manage branches

Bamboo will automatically create plan branches when it detects new branches in your version control system And automatically remove plan branches from Bamboo after a specified period of inactivity. Detection of new branches runs every 5 minutes.

and this is also mentioned in the bug I linked to above as a problem.

It does mean, "start a branch and go get a coffee". Not really a great idea for developers wanting to get into the thick of things quickly and not really an impression I want to give my devs either. I don't really want people taking their time and I definitely don't want systems making them do that.

The detection time for changes on the branch itself is customizable, yes. But still this is not satisfactory enough. Because the whole plan is bound to every branch. What if we want branch specific testing? I have to create a whole new project?

It is nice Atlassian is seeing this as a pain point. Can't wait to see the improvements.

Though, my question about when fetches happen in Bamboo still isn't answered. I need to understand this, to also understand, when Bamboo will actually run the plan linked to the plan branch.

Scott

p.s. I am going to write this at the bottom of the other comments. The comment system here with it's heirarchy, is a bit confusing.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bitbucket-server

bamboo

bitbucket-administration

trigger