GitLab is envisioned as a platform for the full SDLC - from idea to production [1][2].
If you don't want to use the CI, it shouldn't get in your way. We'd love to hear any specific suggestions you might have, since we're always looking to improve. You can open an issue about them in [3] if you want.
As GitLab user, I think the concern for me is split focus. For everywhere there's a tightly integrated built-in tool (issues, CI, container registry, etc), there also needs to be a separate, parallel effort to create, maintain, and document a sufficiently rich plugin interface that a third party can create a similarly tightly integrated experience when plugging in something external.
Basically, they build the hooks but aren't dogfooding any of it, since their own integrations don't have to.
And speaking from the perspective of someone using GitLab with Jira and Jenkins, it just isn't the same. Is that necessarily because of problems with the interface or is it just those specific plugins? I don't actually know.
GitLab CI started as a separate project, but team saw more benefits from integrating into a single product as it's much easier to provide tightly integration without the overhead of communication and APIs. There are places in the workflow that can't just support a hook for an external integration.
While CI is integrated, it does not force you to use it, and there are ways to integrate with external solutions.
While CI is part of the same product, you don't run the tests in the same machine, so you still need to provide the workers in additional ones or use the autoscalling mechanisms and have it bootstrap machines in the cloud as needed.
So what I mean here is that while it is part of the product, it's mostly the "frontend" and the "APIs", the heavyload part of running it is totally optional.
Sure, and I get all that— it definitely makes things easier for the creators and maintainers of the software, and it's easier to deploy it too, so it's a win for small shops who aren't yet committed to a lot of other tools, or are fine with being committed to an "omakase" experience where everything is okay and nothing is best-of-breed.
But there are definitely some customers who are sidelined by this approach. Atlassian is pretty committed to tools that talk to each other with documented APIs (Jira, Confluence, Bamboo, Bitbucket/Stash), and for large organizations, that's often a better fit.
It serves different business purposes. Atlassian make money by selling each individual product license. Also there is a reason why they are not part of a single unified platform, some of then were aquisitions, etc.
There are many players doing "unix" application, and very few trying to build a suite. You need to pick your fights.
I would prefer different tools for different stages in the software lifecycle that can be changed independently from each other because they only talk in simple protocols. Everything-Included tools converge to IBM or SAP products that do nothing really well and trap you into their solution because the integration is too tight.
Basically, they build the hooks but aren't dogfooding any of it, since their own integrations don't have to.
And speaking from the perspective of someone using GitLab with Jira and Jenkins, it just isn't the same. Is that necessarily because of problems with the interface or is it just those specific plugins? I don't actually know.