Can't help but feel that their focus on moving all operation insights into gitlab itself will not be as successful as they want it to be (as far as I read, their goal was to replace their operations and monitoring tools with gitlab itself[1]). I've worked with the ultimate edition for a year and the kubernetes integration is nowhere close to the insight you would get from google, amazon or azure in terms of insight and integration with ops-land. I wish all these hours were spent on improving the developer lifecycle instead.
I can understand how their huge success of "built-in CI" quickly leads to "built-in XYZ", but competing with github that lets other companies solve developer/ci problems via marketplace (and now CI via their new terraform actions) may lead to loosing market-leader [my take on their product] position for a code/test/review/merge ecosystem.
Hi jbergstroem. GitLab PM here. thanks for the feedback. Our vision is indeed ambitious and we recognize that not all of our categories are yet "complete" (more on our category maturity here https://about.gitlab.com/handbook/product/categories/maturit...). While we are aiming to make GitLab a first class application for operators, we continue to focus on the developer lifecycle at the same time. You can see what each of our groups is focusing on upcoming releases here https://about.gitlab.com/direction/configure/#upcoming-relea.... I'd love to learn what areas and level of insight you'd like to see in out application that would make you consider using it as your daily ops-land driver. Thanks.
GitLab has really come a long way in the past few years. The days of being a github-alike are long gone. Very happy to see them continue to find success.
Amen. Gitlab is to GitHub what AWS is to DigitalOcean. GitHub is great don't get me wrong, especially for open source general releases. But gitlab lets you actually build pipelines and fully integrate a bunch of services. They're the best CI/CD service around, honestly, and I think they've been playing to that strength. On top of that they have excellent project management, which makes them a lot more suitable than GitHub for company project's imo.
In case somebody from Gitlab team is reading, a lot of people want to have runner priorities in gitlab - the feature seems to be trivial, yet can save a lot of time and money for the user for you can use less ondemand runners or give more work for more powerful runners
It's amazing how good Gitlab is for a free product.
Interestingly, the fact that we need to host some of our repos internally means we have an on-site install, but because of that I much prefer to host our public / non-internal repos on gitlab.com rather than github, because I can use a single workflow / UI / system for all our projects. So steadily all my open source etc. is moving to gitlab.com because of this effect.
Thanks to the team at Gitlab who make all of this available for everyone to use!
Saying Gitea is better because it's lighter weight is like saying a moped is better then an SUV because it's lighter weight. Gitea / Gogs is great for personal projects and small teams that don't need all the CI/devops/scrum/etc features that GitLab provides, but they're not really in the same ballpark.
GitLab is definitely resource hungry, but we self-host it for under $100/mo on AWS. This includes the cost of the CI infrastructure as well - EC2 instances being spawned by the multi-runner with docker+executor for each unique pipeline running.
Management of the server has been as easy as logging into the GitLab server periodically and running a yum update... It's never gone down.
Gitlab didn't have those extra features at early stages either (Gitea does have CI API BTW, if not a built-in CI). And Gitea doesn't have Gitlab's financial resources.
But the point being made is orthogonal to the feature set: Gitlab (mostly written in Ruby) isn't using hardware resources (memory, CPU cycles, parallelism) as efficiently as Gitea (written in Go) does.
This is well reflected to the minimal system requirements, even when you aren't using any of those additional features:
https://docs.gitlab.com/ee/install/requirements.html whereas you can in principle use Gitea even on a Raspberry Pi Zero for a small group.
For example, disregarding parallelism and wasted CPU cycles and just looking at memory usage: I have a running instance and its using 30MBs of RAM at the moment (~10 users, ~100 repos). If I move all the repos, issues, PRs to a Gitlab instance, I would be looking at GBs according to their minimal requirements. This is related to the mindset in which memory and CPU are considered as infinite resources.
Hi! Thanks for the feedback. We'd love to be as lightweight as Gitea, but our end goal of being a single application for the entire DevOps lifecycle means that we are naturally more complicated. We are always working toward improving our resource usage though! You can see our issues around performance here: https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...
very true, running gitea myself for 2 years, easy to use, light-weight(one go binary to run, one minute painless upgrade with new releases), no memory/cpu pressure whatsoever(I host linux kernel tree myself, so yes large git is fine there too).
If you don't need what gitlab/github or for that matter Azure Devops, offers... using bare remote repos over SSH+FS might just be a better approach. All you need is an SSH server with file system access behind it.
Honestly, it's painless. Fire up a cloud server, run the omnibus installer and you're away. I can't remember having any serious issues in five years running it that way.
The decisions to include features based on price tier has seemed to grow increasingly petty IMO. We are on the Bronze tier, and won't upgrade because of a feature like this specifically. But each time I see that we don't get new features like this, I lose a little bit of that love I've had in GitLab as a user for over 4 years now.
While using the free tier, I honestly can't validate a a $19/user/mo ($228/user/annum) expense based solely on a single feature, let alone why I should move to the paid version at all if more and more features start to be gated beyond multiple levels (a la Windows 7).
I love using Gitlab as a part of development cycle, managing issues and handling pull/merge requests but per seat licensing is a bit steep for a single user, even more so for a team.
The norm for pricing products and services is more and more "just for a pint/coffee/sandwich a month" but when everyone wants their share of the cash, the end result is a mismash of services and products that don't work together well (if at all) and you get stuck without a pint/coffee/sandwich for the whole month now.
I'm sorry you feel that way. There is a lot of thought that goes into our pricing and what tier a feature should go in. At the end of the day though, we still need to make money as a company. If you're interested in how we determine which tier something goes in, you can read about it here: https://about.gitlab.com/handbook/ceo/pricing/#the-likely-ty...
A really simple way to improve the UI is to just add some margins on the right and left of the page. It's very off putting to have meaningful content butted up against the absolute edges. Not sure why this is, but I really hate interacting with gitlab because of it. Hope that helps.
We prefer 990px containers where possible, so if you're using gitlab on a browser smaller than that it'll usually butt up against the edges.
Couple of questions about your issue:
1. Any pages this is particularly bad for? Some dense pages (e.g. Pipelines or side-by-side diffs) need all the width they can get
2. what screen size do you normally use?
3. In Settings > Preferences > Behaviour, are you using Fixed layout or Fluid? Fixed should give you left/right margins if your window is >1280px
4. Do you collapse the left/right sidebars? I usually keep them both collapsed which helps reduce the crowding. But since they are expanded by default this is not an ideal solution
The main middle section is fine, your eye doesn't have to travel far to read the code files and the readme because it's in your primary viewing area.
But you know what's not in your primary viewing area? All of the buttons that do important things. They're shoved off to the side. If you want to do anything other than read the code files, you need to be looking at the exact leftmost edge of your screen and away from the main content. It's a disjointed viewing experience.
Ok, now the main content AND the most important buttons (navigation) are shoved to opposite sides of the screen. There is no max width on the main content, so your eye has to travel a veritable mile to read all of the content for each issue.
If I had to put my finger on the primary reason for this design, it's probably an over-focus on the idea that you should feature some "main content" for each page and kind of hide what you believe is "superfluous".
For example, "oh they clicked on an issue, so they really only care about the discussion that is taking place. Let's feature the discussion text but make all of the metadata shoved to the side and even collapsible." But the problem with this line of thinking is that the user _does_ care about more than just the "main content" of a page. The metadata, the navigation, it's all factored into a typical user experience. So when you are making the decision for the user about what they _should_ be looking at, you're forcing them to break your flow to do what they want. Now the user has to dart their eye from the far left to the far right just to see what they want.
I know I didn't answer your numbered questions directly, but I hope I'm conveying this correctly. I've never made a gitlab account, so I just use the default settings.
When GitLab starts to fully support automatic Let's Encrypt certificate generation with GitLab Pages — just like GitHub, I would strongly consider moving.
AFAIK it's in the pipeline to be added, but seems to not be a #1 priority[1]. Please let me know otherwise.
Out of literally bajillion features GitLab provides from DevOps lifecycle to project management and everything in between, Lets Encrypt certificates is what will make you switch? Are you serious?
Why would I not be? I see it as a feature that I would like to exist. And yes, they to have many features, but atm. I don't use them to the extend that I must switch at this second.
For future school project, I do see myself using GitLab. As you yourself said, they have many good features. (After been forced to used Bitbucket for a school project, I'm happy to use anything else.)
Hi! It is actively being worked on, but it didn't make it into this release. It is scheduled for the 11.11 release, and we don't foresee it being pushed back any further. Thanks for your feedback!
Readit News
I can understand how their huge success of "built-in CI" quickly leads to "built-in XYZ", but competing with github that lets other companies solve developer/ci problems via marketplace (and now CI via their new terraform actions) may lead to loosing market-leader [my take on their product] position for a code/test/review/merge ecosystem.
[1]: https://about.gitlab.com/2018/10/01/gitlab-product-vision/
https://gitlab.com/gitlab-org/gitlab-ce/issues/12715#note_11...
Interestingly, the fact that we need to host some of our repos internally means we have an on-site install, but because of that I much prefer to host our public / non-internal repos on gitlab.com rather than github, because I can use a single workflow / UI / system for all our projects. So steadily all my open source etc. is moving to gitlab.com because of this effect.
Thanks to the team at Gitlab who make all of this available for everyone to use!
GitLab is definitely resource hungry, but we self-host it for under $100/mo on AWS. This includes the cost of the CI infrastructure as well - EC2 instances being spawned by the multi-runner with docker+executor for each unique pipeline running.
Management of the server has been as easy as logging into the GitLab server periodically and running a yum update... It's never gone down.
But the point being made is orthogonal to the feature set: Gitlab (mostly written in Ruby) isn't using hardware resources (memory, CPU cycles, parallelism) as efficiently as Gitea (written in Go) does.
This is well reflected to the minimal system requirements, even when you aren't using any of those additional features: https://docs.gitlab.com/ee/install/requirements.html whereas you can in principle use Gitea even on a Raspberry Pi Zero for a small group.
For example, disregarding parallelism and wasted CPU cycles and just looking at memory usage: I have a running instance and its using 30MBs of RAM at the moment (~10 users, ~100 repos). If I move all the repos, issues, PRs to a Gitlab instance, I would be looking at GBs according to their minimal requirements. This is related to the mindset in which memory and CPU are considered as infinite resources.
Very different development style than Git, but for my personal projects I really like it.
I love using Gitlab as a part of development cycle, managing issues and handling pull/merge requests but per seat licensing is a bit steep for a single user, even more so for a team.
The norm for pricing products and services is more and more "just for a pint/coffee/sandwich a month" but when everyone wants their share of the cash, the end result is a mismash of services and products that don't work together well (if at all) and you get stuck without a pint/coffee/sandwich for the whole month now.
We prefer 990px containers where possible, so if you're using gitlab on a browser smaller than that it'll usually butt up against the edges.
Couple of questions about your issue:
1. Any pages this is particularly bad for? Some dense pages (e.g. Pipelines or side-by-side diffs) need all the width they can get
2. what screen size do you normally use?
3. In Settings > Preferences > Behaviour, are you using Fixed layout or Fluid? Fixed should give you left/right margins if your window is >1280px
4. Do you collapse the left/right sidebars? I usually keep them both collapsed which helps reduce the crowding. But since they are expanded by default this is not an ideal solution
The main middle section is fine, your eye doesn't have to travel far to read the code files and the readme because it's in your primary viewing area.
But you know what's not in your primary viewing area? All of the buttons that do important things. They're shoved off to the side. If you want to do anything other than read the code files, you need to be looking at the exact leftmost edge of your screen and away from the main content. It's a disjointed viewing experience.
But that's just about the navigation. Let's say that you find the Issues page and go there: https://gitlab.com/pwoolcoc/fedichat/issues
Ok, now the main content AND the most important buttons (navigation) are shoved to opposite sides of the screen. There is no max width on the main content, so your eye has to travel a veritable mile to read all of the content for each issue.
Even looking at the content for a specific issue has the same problem: https://gitlab.com/pwoolcoc/fedichat/issues/6
If I had to put my finger on the primary reason for this design, it's probably an over-focus on the idea that you should feature some "main content" for each page and kind of hide what you believe is "superfluous".
For example, "oh they clicked on an issue, so they really only care about the discussion that is taking place. Let's feature the discussion text but make all of the metadata shoved to the side and even collapsible." But the problem with this line of thinking is that the user _does_ care about more than just the "main content" of a page. The metadata, the navigation, it's all factored into a typical user experience. So when you are making the decision for the user about what they _should_ be looking at, you're forcing them to break your flow to do what they want. Now the user has to dart their eye from the far left to the far right just to see what they want.
I know I didn't answer your numbered questions directly, but I hope I'm conveying this correctly. I've never made a gitlab account, so I just use the default settings.
AFAIK it's in the pipeline to be added, but seems to not be a #1 priority[1]. Please let me know otherwise.
[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/28996#note_15...
For future school project, I do see myself using GitLab. As you yourself said, they have many good features. (After been forced to used Bitbucket for a school project, I'm happy to use anything else.)
Will be watching out for the new release via the blogs RSS. ;)
[1] https://www.netlify.com