There are hooks, services, and OAuth2 support, as well as the API, which internally we leverage to extend GitLab or integrate with other products, kind of the way GitLab CI did before it was merged.
Come to think of it, services like Travis CI could integrate with gitlab.com easily (if they wanted to do so).
Re:GitLab Master Plan
by jobvandervoort on Tuesday September 13, 2016 @10:19AM
(#12488437)
Our goal is to ship a single tool that will work for (almost) everyone. We believe that this will be a better experience and allow for deeper integration, besides cost, setup and maintenance advantages.
That said, we don't expect to be able to replace every single tool one might use -such as internal tools-, therefore we make it possible to integrate with GitLab easily and have an API that covers everything.
Examples of this are plenty. For instance, we build our commit status API to support our own CI system, but immediately also published the public API that allows any other CI to make use of this and offer similar integration in GitLab (in that case, you'll still have to switch between apps, which we believe can be better - hence our goal).
If that's your intent then my statement is not operative, great. But your other public statements imply (to my reading) the opposite of what you say in your comment. For example, from the announcement:
> We prefer to offer an integrated set of tools instead of a network of services or offering plugins for the following reasons:
and some comments from your colleague theunquietone: > We believe in a single solution from idea to production.
and when someone commented "Makes for a tough pitch at an established shop" he replied: "We hope to create tools and resources to make that pitch and migration easier."
It's early days so you have time to clarify/refine your story.