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

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

[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]

But back to our process. Basically, we are at this stage with Bamboo.

1. We need a build process to create a dev enviromment to automatically trigger on a branch creation (this now works with a plan branch-yipee! and thanks for the tip and making me work at understanding plan branches better, although, it shouldn't be that hard. Not sure it is me or the name or the way it is described).

2. Then, as changes are pushed to that specific branch in Stash (the dev or devs are pumping out code into the branch!), we need to automatically do tests on the new code. If they pass, update a dev environment (This is theoretically possible with a web hook and a separate "update" plan and a smart script on the dev environment server)

3. When all is done for a certain branch, the dev creates a pull request in Stash and the code is reviewed and the branch is merged on approval. Bamboo should automatically notice the branch is merged (removed, missing, gone, deleted), delete the plan branch and do further deployment steps like remove the dev environment.

We have steps 1 and 2 figured out, well sort of with the web hook.

Is step 3 possible somehow? Maybe even as a manually triggered stage, which should be part of the process of the pull request/ merge?

It seems the only choices are let Bamboo see there is no more activity and it deletes the plan branch itself with no action or an admin must delete the plan branch manually.

Scott

[cofarrell]

Hi Scott,

Apologies if I miss something.

1. "Changes" means that since the last time that Bamboo fetched a given branch is not pointing at the same commit. When it detects a change on a branch it will run the branch build.

Not sure about the poll times.

2. The task for a plan has to be the same for all the branches. So you have two options, you can either have one task that runs DoEverything.sh that detects what the branch is (by passing it in as a Bamboo variable) and acts accordingly. Alternatively you can have two plans, one that has a task that runs branches, and another plan that only runs develop.

I'm not quite sure I know you mean by fidelity in this context.

------

2. The tests can just run as part of the same task (or tasks) in the branch build. Otherwise normally you might decide to have dependant/child plans, but I have a funny feeling that won't play nicely with branch builds.

I believe Bamboo will cleanup the plans for deleted branches over time, but don't quote me on that. It would be easy enough to test.

You still need to detect that a branch is deleted somewhere else so you can remove the dev environment. I'm not sure Bamboo can help you here. You will have to keep track of all the branches yourself and respond to deleted ones somehow. Alternatively you could have a custom service that listens for its own webhook and goes from there. You do have options though - it _is_ possible.

Charles

[Scott Molinari]

For some reason your spambot is giving me trouble. Can you check the answer to this and change it to a comment please?

Scott

[Scott Molinari]

I am pulling my hair out. I could have sworn, when I create a plan branch, that the plan will run. Is this not correct? If it is correct, how do I get the plan to run, when a plan branch is created?

Scott

[cofarrell]

Hi Scott,

I think it depends on your plan triggers. What have you configured for that?

Charles

[Scott Molinari]

Hey Charles. Maybe you can be my lifesaver. :)

I don't have any triggers in the plan branch plan at all. And to be honest, I am not sure I really need plan branches. I just need a plan, that only happens, when a branch is created.

This is what I have.

1. a plan to create dev environments
   1. Create a plan branch, when a branch is created in Stash (this works).
   2. Run the main plan, when a branch in Stash is created i.e. when a plan branch is created (this doesn't work, but I though it did in my earlier testing and why I am loosing hair).
2. an update plan to update dev environments with changes and do testing.
   1. triggered by a web hook from Stash (works great)
   2. updates the development environment (works great)
   3. runs tests (haven't gotten this far, but I am sure it will work).

What do I need to do, to get 1.2 working? I don't believe a trigger is what I need, because I only need the plan to run, when a branch is created in Stash. Then it should be ignored after the branch is created.

Scott

[cofarrell]

Hi Scott,

I'll do my best, although Bamboo isn't really my area.

I'm not sure how your main plan will run when a branch is created. Normally each plan is tied to one branch, except for plan branches. I'm probably misunderstanding, but the plan branch is created, but not run? Triggers (like polling) are normally the things that kick-off the build.

Let me know if I'm mixed upl

Charles

[Scott Molinari]

"... except for plan branches."

Exactly what I thought too.

"I'm probably misunderstanding, but the plan branch is created, but not run?"

Nope. You are understanding.

I have one simple plan, which creates plan branches, with one single stage with one job to do things on a remote server to create the dev environment, but neither the stage nor the job run, when the plan branches are created.

I could have sworn this was working earlier and why I moved to the second and third parts of the development process, updating and clean-up of the dev environments.

But now, I have come back to the plan branches to do some more testing and what I thought was working isn't working anymore. If I am not going crazy, then I must simply be missing a stupid setting somewhere.

For instance, I found the setting for the polling of Stash for plan branches (which solves my rant earlier) and lowered it down to 1 minute and I never tested that change. I wonder if that is the cause for the issue. Hmm....

Or am I totally wrong in thinking the overall build plan should run, when a plan branch is created?

Scott

[cofarrell]

That's weird that they're being created but not run. Again, the plan needs to have a trigger, which is inherited by the branch, although when you say polling that's usually configured under triggers I thought.

I'm assuming the plan branch is enabled?

The overall build plan shouldn't run, unless the master branch (or whatever is configured) is modified.

Sorry, I'm not sure I can help. :(

[Scott Molinari]

Ah, if I manually run the dev environment creation plan (with plan branches), everything works like a charm. But, I don't want devs having to go to Bamboo to trigger the plan and it really shouldn't be necessary either.

The process should be.

1. Dev gets the task to work on a feature or a bug fix and creates a branch through a Jira ticket. (btw, in the areas where I work, we simply call them "Jiras", so as not to get them confused with "support tickets".)
2. The new branch is created through the Jira interface to Stash, which works great.
3. Bamboo should notice the new branch and run a plan, to create the dev enviroment on the dev server. (this is what isn't working).
4. The dev checks out the new Stash branch locally and starts working.
5. As the dev makes changes and pushes them to the branch in Stash, a second plan in Bamboo gets triggered from a web hook in Stash. Bamboo then launches a small script on the dev environment server, which pulls the changes from the branch, into that invironment. This happens within a second or two of the push. Perfect! Theoretically, I could have done this directly in Stash I know. But isn't that what Bamboo is made for? Because, we also want to incorporate unit testing later too.
6. Once the dev is finished, he makes a pull request in Stash to merge the branch he was working on into the develop branch.
7. The changes are reviewed and the branch is merged, when all is well.
8. Bamboo cleans up the plan branches (and we actually don't need the branches, but we need to run a plan, when a branch is created).
9. A small script on the server cleans up of the dev environments on the dev server once a day, by looking at Stash to see if branches are missing. If one is missing, the corresponding dev environment is also removed. (it would be cool if the clean-up process in Bamboo also had the ability to trigger external tasks too).

continued below...

[Scott Molinari]

This might be a totally new way of using Stash and Bamboo. But I can imagine web application vendors are wanting this kind of system, so that developers can test their work on a real cloud server environment. With cloud computing coming into the picture more and more and it being practically impossible to mock-up an application running on cloud infrastructure locally, there must be a way to program locally, but "push" the changes to a web server environment for direct testing.

Scott

[Scott Molinari]

The overall build plan shouldn't run, unless the master branch (or whatever is configured) is modified.

That is bad news. :(

Scott

[Scott Molinari]

Well, I've done some more testing and I guess I must have mixed things up. The plan plan branches are created in, don't run, when a new branch is created.

Our devs will have to manually run the plan branch as part of our process. Oh well...

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

[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