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.

Well, that is good to hear.

I'll actually be in Australia (Brisbane) the next week and a half, traveling there starting tomorrow. (I live in Germany.) I'll not be able to be online for a Skype meeting during the day though. I have to work in my real Job, which doesn't have anything to do with Atlassian products. These concerns come from my "hobby business". We can have a meeting in the evening (after 6 p.m.) though. Can I send you my Skype handle via email?

Scott

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