The unique and intuitive way we can interact with it. It is a complete platform that's also very simple to use, so simple that setting up any new pipeline usually takes ten minutes tops. At our company, we use multiple Buddy actions, such as: File transferring (SFTP), performing Status Checks for CR, building and pushing Docker images, establishing containerized environment for tests and setting up K8s deployment images. And we are pretty happy with our overall experience with Buddy.

Price, maybe? IIRC, it's a little more expensive than alternatives but I think it's worth it in the end.

It just works. With very little setup and maintenance the solution just works. Features are intuitive, controls are plenty, and the UI is beautiful. I started with the free self-hosted version, and have continued with both the cloud and self-hosted on various teams. The various price points are great for getting the entire Git workflow organized for your team.

- The filesystem access to debug builds and their artifacts - The Dockerized containers for each action that share the filesystem - The many ready to go actions that can be added to any pipeline - The ability to have multiple pipelines running on a given project - The ability to tag and organize repositories into folders

- Requires a lot of memory for the self-hosted variant - Inability to use slashes to group repositories under namespaces

I

* very easy to use * new pipeline config is very simple * multiple integrations * on-premise plan * options for pipelines discribed in yaml files or we can just click it one after another * after registration its ready to work

* complicated build are failing randomly (with multiple additional serwices) without logs - cannot investigate why. It occurs as on machine on 20G memory as also on 60G (guys are working on that) * no integrations for output parsing (ex. junit is not parsed) only raw output * limit of 4 additional services (ex. mysql) per pipeline action (I've already reached the limit and I need add some more services in near future) * if using yaml config, its extremely easy to unintentionaly break pipeline for example having conflicts with merge on feature branch. Would be great if we could have an option for securing pipelines to read only from concrete branches (for ex. master and pipeline-dev),

This is a good tool for devops but requires few flexibility of using multiple code repo urls in a project, able to create pipeline automatedly selected branches. Plugins for Liquibase, soanrqube servers etc

The feature of defining actions and customize the actions based on the requirement. Switching on and off of the actions of a pipeline. When error occurred, correcting the issues and continue to run the pipeline.Parameter action and custom actions help to achieve what we want. Integration with third party tools like ACR, Synk- etc

Selecting only one code repo for a project.