I see Stash 3.1 was release today but I don't see this mentioned in the changelog.
Also is there an ETA on when this will be released for bamboo?
We are waiting for this feature before we complete our trial of bamboo.

The different components, Jira, Confluence, Stash, Bamboo (the ones I work with), even though the UI's are fairly standardized, they still have idiosyncrasies, which make them feel very much "unalike", for a lack of a better word.

Thats because we started off very much as different products. The way we view things today is as one experience and its going to take time for us to moved the products in that direction. Its a lot of work but we will eventually get there. That includes the few of the issues you've flagged such as UI discrepancies, Application Links and the directory management experience.

But for sure, it seems like between the applications/ components, there is still a "throw it over the wall to the other side (another component/ application) and hope it sticks" kind of connectivity/ feeling and that needs deep thought and change, before I can say I really love Atlassian's products.

Absolutely! We've got a team formed here in the Developer Tools group called Fusion thats working hard on this exact problem. Could we organise a time to meet on Skype to collect your thoughts in more detail? cc mcook

Not different really. It's just asking for even more fidelity in the communication between Stash and Bamboo, so that actions triggered in Bamboo can be very specific.

I realise Atlassian has made a very component based system and not all components started out at the same time with the same engineers and same thinking/ concepts and one realizes this, when one uses them in depth (for instance the differing depths of look and feel point and click customization). The different components, Jira, Confluence, Stash, Bamboo (the ones I work with), even though the UI's are fairly standardized, they still have idiosyncrasies, which make them feel very much "unalike", for a lack of a better word. Atlassian needs to really concentrate on this overall issue. This improvement is just one small example. To me, the components are still much too segregated. When I worked with the user directory between the components for instance, I was never certain what the heck was going on. Why do I have to even choose or work with this stuff? (and I've locked myself out of Stash because of it!!!) Or making "application links". Why do I need this? I have the components/ applications, from Atlassian, they should just.....link up themselves. Leave me out of it please! Sorry, getting ranty.... I apologize.:-D

But for sure, it seems like between the applications/ components, there is still a "throw it over the wall to the other side (another component/ application) and hope it sticks" kind of connectivity/ feeling and that needs deep thought and change, before I can say I really love Atlassian's products.

Sorry again for going off on a tangent and slight rant, but the above feeling is always in the back of my head, when I work with the software.

I am glad this suggestion got attention. There is still a lot more work to do in the exact same direction.

Scott

Ok, commits are good. But does the broadcast of the commit also let Bamboo trigger a plan based on the branch the commit was made on and not just the repo?

Yes, Bamboo is aware of branches when triggering builds via this mechanism.

I'd actually like to see a level of deeper control. For instance, the dev could add a commit comment like "No Testing" to his commit, and unit testing be bypassed (another plan ran in Bamboo) based on that little marker.

Sounds like you want something different that what this issue intended. Feel free to raise a new feature request if this is important to you and we can discuss it there

Ok, commits are good. But does the broadcast of the commit also let Bamboo trigger a plan based on the branch the commit was made on and not just the repo?

For instance, we could have 2 devs working on two different feature branches from the same repo. These two branches are also located on two different dev environments (cloud based). Dev A commits a change to feature branch B and the dev environment C gets modified and tests are run through Bamboo. On the other hand, the other dev commits a change to feature branch X and environment server Y gets modified and tests are run through Bamboo.

I'd actually like to see a level of deeper control. For instance, the dev could add a commit comment like "No Testing" to his commit, and unit testing be bypassed (another plan ran in Bamboo) based on that little marker.

What we are trying to avoid is the dev herself ever working directly on any dev server (via FTP/ SSH or the like). All she sees is her IDE and a Git repo, which she uses to commit and push her programming to constantly, continually, all the time.

Scott

I'm not sure what you mean but Ill try to clarify. The work we've done is a broadcast. If there are any commits pushed to a repo in Stash those events are passed to Bamboo. Bamboo then decides what should build.

So, this improvement is still only at repository level? In other words, a successful pull on a certain branch still won't trigger a certain build/ plan?

Scott

Hi there,

We have completed this work and it is due in the Bamboo 5.6 and Stash 3.1 releases.

This work is configuration-less: if you are using the Stash repository type, have a remote trigger configured for the plan, Stash >= 3.1 and Bamboo >= 5.6 it should all work out of the box.

Any Bamboo build that uses the Stash repository type will automatically be notified by Stash of new commits.

Stash will also tell Bamboo when branches have been:

• Created - plan branches are automatically created for any corresponding plan
• Deleted - any corresponding plan branch will be disabled.

Branches that are deleted then recreated will have their plan branches reenabled or recreated (if previously deleted or expired).

Thanks,
James Dumay
Product Manager

Stash is also missing the ability to trigger a Bamboo build of a pull request, especially when that pull request is coming from a branch in a fork. With Github+Jenkins it's easy. Atlassian, however, has yet to live up to their claim, "Stash integrates seamlessly with build automation tools like Bamboo."

Post recieve web hooks are only repo specific and not branch specific. In other words, you can only trigger a plan (not just a build, which is actually better) based on action to the whole repo.

Creating the web hooks is a manual process and there is no way to automate them or rather use them dynamically (i.e. add a variable to pull the key from a branch name to trigger a plan with the same key. The "key" concept isn't really permeated throughout all three applications, which is a shame.)

So basically, if you want to have an automated process between Jira, Stash and Bamboo, with a lot of automatic activity based on branch changes, you must use the polling from Bamboo , which also has its limitations.

In general, it is sold in videos about Stash that a best practice for developers is to "branch for everything", yet triggering plans on specific branch activity like merging, pushing etc.is so limited. I find that quite strange.

Scott

I still believe that this process needs to become simpler, but at this point there is a relatively simple method to enable stash commits to trigger a build. In stash you must install the post commit hook plugin (from atlassian marketplace). Then you can have a commit to a specific branch query a bamboo uri for your build, which will trigger bamboo to query stash for changes and begin a new build.

I am going to jump on the bandwagon here. I agree, there needs to be a better integration between what happens in Stash and triggering plans in Bamboo.

Scott

@James
that explains a bit
thanks i hope the integration part will be fixed soon so we can use it.

ramon.makkelie hooks only send notifications on push and not for other events such as a pull request being merged, etc. The Bamboo integration will be more intelligent than that.

We've started on a native Stash repository type that will be released by the end of the year (BAM-11409). After we have delivered it, we will look at working on this issue.

+1

It is a bit shocking that you don't have a commit build trigger method for your own product. please prioritize this.

this is really BAD!
there is a hook for jenkins but not for bamboo?

Voting for this issue. While I found the plugin skeleton here:
https://developer.atlassian.com/stash/docs/2.3.0/how-tos/repo-hook-examples/async-post-receive-config.html

It would be grand to not have this "Hack" in place to get the repositories to trigger.