6 ms·

I really like the core of gitlab. It's a really good git hosting system that is easy to maintain and work with. My self hosted instance has broken only twice in

I really like the core of gitlab. It's a really good git hosting system that is easy to maintain and work with. My self hosted instance has broken only twice in the last 1.5 years and it was always because of an upgrade and it was always easily fixed. But now i have to say i'm afraid gitlab is getting bloated. Why not keep the core product as a seperate thing from things like CI? a simple plugin style system would be enough for it to not feel like bloat but feel like extra options.

cmatija 9y ago
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. [1] - https://about.gitlab.com/handbook/product/i2p-demo/ https://about.gitlab.com/handbook/product/i2p-demo/ [2] - https://about.gitlab.com/direction/#scope https://about.gitlab.com/direction/#scope [3] - https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues
- mikepurvis 9y ago
  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.
  - brodock 9y ago
    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.
    - mikepurvis 9y ago
      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.
      - brodock 9y ago
        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.
- adrianN 9y ago
  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.
green7ea 9y ago
I also really like Gitlab but the self-hosted instance I manage broke twice in the last month due to faulty updates :-/. First, the automatic notification e-mails stopped working until I did another upgrade. A later update broke issue merging: merging one merge request closed all work requests (event the ones with WIP). If you also consider the sudden removal of the backlog from the issue board a while ago (they added it back since), I'm now afraid to update our Gitlab instance. This is very unfortunate because Gitlab is a very nice and useful tool but if QA doesn't improve, it will be very difficult to prevent a migration. These problems are show stoppers for us.
- Outpox 9y ago
  My Gitlab instance broke 3 times in 5 months, and my questions/issues haven't been answered. I had to manage to backup my data, fully uninstall Gitlab and reinstall it. I then hosted it on a dedicated server using docker and it has been running much better since then.
  - green7ea 9y ago
    We run Gitlab in an LXD container with an Omnibus install. Everything works pretty well but those issues were caused by regressions in updates. There were new updates fixing those regressions within a few days but it still caused us quite a few headaches.
roblabla 9y ago
I just updated the NixOS gitlab package from 8 to 9[0]. It was a nightmarish experience. There are 5 microservices : - gitlab (the core) - gitlab-sidekiq (a work queue) - gitlab-workhorse (provides the frontend) - gitaly (a git wrapper that caches stuff) - gitlab-shell (a shell spawned when doing your git clone) Those are written in either go or ruby. Sometimes mixing the two in the same repository. In the main gitlab repo, there is also some unvendored js dependencies for the frontend, necessitating to jump through some more hoops. Gitlab has a bunch of hardcoded paths to logfiles and config files. Some config files are toml, others are yaml. Different services need different configs, sometimes duplicating the config entries in a different format. I love gitlab as a product. But as a sysadmin, it's one of the worst thing I've ever had to deploy. [0]: Well, it's not pulled there, but it's at https://github.com/NixOS/nixpkgs/pull/27159 https://github.com/NixOS/nixpkgs/pull/27159 if you're interested.
- FTA 9y ago
  This was my same experience. I spent three solid work days trying to install it from source since it's on a server with other services and their default nginx etc. setup couldn't work. All the different microservices made installing from source very difficult. I ended up finally giving up and using the black box omnibus installation and fiddling with the configuration file for a while. It works now but I can't hack the source to make custom improvements, so it ends up not being as open source as I would have hoped. There's one particular issue in trying to push that results from being on a URL subpath (http://.../gitlab http://.../gitlab). I can't fix it myself because of that. Don't get me wrong--it's a good program and has worked for the team I support. But click and deploy is not useful for people who don't have bare bones servers they can spin up and instead have to work with shared servers.
  - dijit 9y ago
    I gave up and ran a docker container with reverse nginx vhost proxy to the docker port.
- sytse 9y ago
  Please use the official Omnibus packages to ensure that upgrades are less likely to break. I think we use toml for the Runner since it is written in Go and should be deployed on another server. The rest is mostly in yml files although we trying to move as much as possible to the UI to make it more user friendly.
sytse 9y ago
We hear your concern about GitLab getting bloated. We first made GitLab CI as a separate application. When Kamil (CI lead) proposed to Dmitriy (co-founder CTO) to add CI to GitLab itself he said that was a bad idea, we need sharp tools. After Dmitriy became convinced and when they proposed it to me (CEO) I had the same response: http://redmonk.com/jgovernor/2017/06/21/how-gitlab-abandoned-the-unix-philosophy/ http://redmonk.com/jgovernor/2017/06/21/how-gitlab-abandoned... But when we integrated it the sum was more than the parts. The benefit of deep integration and not having to switch applications are becoming more apparent to us. It is hard to articulate why the same can't be done with plugins, the video in the article is maybe a good start. Review Apps, changes metrics in the merge request, the container registry being aware of your permissions. All this can be done with plugins. But having it in one applications is so much easier to set up, upgrade, and use day to day.

cmatija 9y ago

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. [1] - https://about.gitlab.com/handbook/product/i2p-demo/ https://about.gitlab.com/handbook/product/i2p-demo/ [2] - https://about.gitlab.com/direction/#scope https://about.gitlab.com/direction/#scope [3] - https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues

mikepurvis 9y ago
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.
- brodock 9y ago
  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.
  - mikepurvis 9y ago
    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.
    - brodock 9y ago
      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.
adrianN 9y ago
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.

green7ea 9y ago

I also really like Gitlab but the self-hosted instance I manage broke twice in the last month due to faulty updates :-/. First, the automatic notification e-mails stopped working until I did another upgrade. A later update broke issue merging: merging one merge request closed all work requests (event the ones with WIP). If you also consider the sudden removal of the backlog from the issue board a while ago (they added it back since), I'm now afraid to update our Gitlab instance. This is very unfortunate because Gitlab is a very nice and useful tool but if QA doesn't improve, it will be very difficult to prevent a migration. These problems are show stoppers for us.

Outpox 9y ago
My Gitlab instance broke 3 times in 5 months, and my questions/issues haven't been answered. I had to manage to backup my data, fully uninstall Gitlab and reinstall it. I then hosted it on a dedicated server using docker and it has been running much better since then.
- green7ea 9y ago
  We run Gitlab in an LXD container with an Omnibus install. Everything works pretty well but those issues were caused by regressions in updates. There were new updates fixing those regressions within a few days but it still caused us quite a few headaches.

roblabla 9y ago

I just updated the NixOS gitlab package from 8 to 9[0]. It was a nightmarish experience. There are 5 microservices : - gitlab (the core) - gitlab-sidekiq (a work queue) - gitlab-workhorse (provides the frontend) - gitaly (a git wrapper that caches stuff) - gitlab-shell (a shell spawned when doing your git clone) Those are written in either go or ruby. Sometimes mixing the two in the same repository. In the main gitlab repo, there is also some unvendored js dependencies for the frontend, necessitating to jump through some more hoops. Gitlab has a bunch of hardcoded paths to logfiles and config files. Some config files are toml, others are yaml. Different services need different configs, sometimes duplicating the config entries in a different format. I love gitlab as a product. But as a sysadmin, it's one of the worst thing I've ever had to deploy. [0]: Well, it's not pulled there, but it's at https://github.com/NixOS/nixpkgs/pull/27159 https://github.com/NixOS/nixpkgs/pull/27159 if you're interested.

FTA 9y ago
This was my same experience. I spent three solid work days trying to install it from source since it's on a server with other services and their default nginx etc. setup couldn't work. All the different microservices made installing from source very difficult. I ended up finally giving up and using the black box omnibus installation and fiddling with the configuration file for a while. It works now but I can't hack the source to make custom improvements, so it ends up not being as open source as I would have hoped. There's one particular issue in trying to push that results from being on a URL subpath (http://.../gitlab http://.../gitlab). I can't fix it myself because of that. Don't get me wrong--it's a good program and has worked for the team I support. But click and deploy is not useful for people who don't have bare bones servers they can spin up and instead have to work with shared servers.
- dijit 9y ago
  I gave up and ran a docker container with reverse nginx vhost proxy to the docker port.
sytse 9y ago
Please use the official Omnibus packages to ensure that upgrades are less likely to break. I think we use toml for the Runner since it is written in Go and should be deployed on another server. The rest is mostly in yml files although we trying to move as much as possible to the UI to make it more user friendly.

sytse 9y ago

We hear your concern about GitLab getting bloated. We first made GitLab CI as a separate application. When Kamil (CI lead) proposed to Dmitriy (co-founder CTO) to add CI to GitLab itself he said that was a bad idea, we need sharp tools. After Dmitriy became convinced and when they proposed it to me (CEO) I had the same response: http://redmonk.com/jgovernor/2017/06/21/how-gitlab-abandoned-the-unix-philosophy/ http://redmonk.com/jgovernor/2017/06/21/how-gitlab-abandoned... But when we integrated it the sum was more than the parts. The benefit of deep integration and not having to switch applications are becoming more apparent to us. It is hard to articulate why the same can't be done with plugins, the video in the article is maybe a good start. Review Apps, changes metrics in the merge request, the container registry being aware of your permissions. All this can be done with plugins. But having it in one applications is so much easier to set up, upgrade, and use day to day.