Gitlab 10.0 released(about.gitlab.com)
about.gitlab.com
Gitlab 10.0 released
https://about.gitlab.com/2017/09/22/gitlab-10-0-released/
126 comments
> Featurewise, I haven't noticed anything that I can't use Gitlab for that I wanted to do.
I've only noticed one: the ability to do less. Along with its excellent improvements over the years, it also gained some staggering RAM usage.
It used to be really nice for self-hosting your own private GitHub alternative on a little VPS or RasPi, but those days are apparently behind us.
I've only noticed one: the ability to do less. Along with its excellent improvements over the years, it also gained some staggering RAM usage.
It used to be really nice for self-hosting your own private GitHub alternative on a little VPS or RasPi, but those days are apparently behind us.
GitLab's RAM requirements have increased considerably and we now recommend 4GB. It still runs on a RasPi2 but it is not a great experience. We would love help running GitLab with Puma so that it is still fast if you have little memory https://gitlab.com/gitlab-org/gitlab-ce/issues/3592
Out of curiosity, how much of a difference would Puma make in terms of memory usage once available (specifically at the low end, i.e. for teams of less than 5 members)? And would you happen to have a rough idea of which features are the biggest contributors to the high memory usage of GitLab?
Being able to comfortably host a limited version of GitLab for a small team on the lowest tier of Digital Ocean or EC2 instances (<512MB) would be a game changer in terms of the accessibility of GitLab as a product. It would give you access to the long tail of potential privacy-conscious users who would like to avoid hosting their code on a SaaS service (and thus wouldn't be already captured by the market leader, GitHub), but might be put off by the high operational costs involved with self-hosting a GitLab instance compared to some of the lighter weight alternatives.
Being able to comfortably host a limited version of GitLab for a small team on the lowest tier of Digital Ocean or EC2 instances (<512MB) would be a game changer in terms of the accessibility of GitLab as a product. It would give you access to the long tail of potential privacy-conscious users who would like to avoid hosting their code on a SaaS service (and thus wouldn't be already captured by the market leader, GitHub), but might be put off by the high operational costs involved with self-hosting a GitLab instance compared to some of the lighter weight alternatives.
This depends on the amount of memory a Puma setup would use vs an equivalent Unicorn setup. Say you have determined you need e.g 10 Unicorn workers, each taking 300 MB. If you could handle the same traffic using 1 Puma process with 10 threads that means you just saved yourself ~2.7 GB of RAM.
It's entirely possible that a single Puma process may end up using more memory than a single Unicorn process, so the only way to know for certain is to measure the difference.
It's entirely possible that a single Puma process may end up using more memory than a single Unicorn process, so the only way to know for certain is to measure the difference.
There are people at GitLab that know more, but my take is that it would make it more practical to run with 1GB.
As listed in https://docs.gitlab.com/ce/install/requirements.html the minimum is 1GB "1GB RAM + 3GB of swap is the absolute minimum but we strongly advise against this amount of memory. See the unicorn worker section below for more advice."
Most of the memory for the configuration of 4GB we recommend is to run extra unicorn workers https://docs.gitlab.com/ce/install/requirements.html#unicorn... You would save this memory because you can multithread one worker.
As listed in https://docs.gitlab.com/ce/install/requirements.html the minimum is 1GB "1GB RAM + 3GB of swap is the absolute minimum but we strongly advise against this amount of memory. See the unicorn worker section below for more advice."
Most of the memory for the configuration of 4GB we recommend is to run extra unicorn workers https://docs.gitlab.com/ce/install/requirements.html#unicorn... You would save this memory because you can multithread one worker.
You should look at gitea ! It's much simpler than gitlab, but is also much more lightweight in terms of resource usage. Used it succesfully to host my startup's git.
If all you need is a server to host a bunch of git repos, there is also gitolite. http://gitolite.com/gitolite/
It doesn't have a pretty interface, but it works, and its requirements are minimal. I've had good success using it to host student repos in my classes for about 4 years.
It doesn't have a pretty interface, but it works, and its requirements are minimal. I've had good success using it to host student repos in my classes for about 4 years.
[deleted]
[deleted]
Yeah, they’ve added more features which end up using more memory. For the small version you’re talking about you might look at gogs.io. Haven’t used it, but I hear good things.
Just for the record, I believe most of the community has moved from Gogs to Gitea (a fork) because of management issues in the original project.
Huh?
Gogs is fine.
People, for whatever reason, think devs have to continue adding more and more features otherwise they see the project as "dead". It's not.
In my opinion the Gitea folks are creating a bloated version of Gogs. YMMV.
Gogs is fine.
People, for whatever reason, think devs have to continue adding more and more features otherwise they see the project as "dead". It's not.
In my opinion the Gitea folks are creating a bloated version of Gogs. YMMV.
My understanding was that the maintainer of Gogs had stopped replying to any issues/PRs for a period of a few weeks and refused to add any other maintainers to the project, so people wanted to fork and ensure that it'd always have an active maintainer.
https://blog.gitea.io/2016/12/welcome-to-gitea/
https://blog.gitea.io/2016/12/welcome-to-gitea/
He did have some periods of inactivity. He didn't want to add other maintainers because he wanted to keep the code quality as good he wanted as far as I know and that's also why he didn't accept pr's, because the code quality wasn't good enough for him.
He was also totally ok with the fork to gitea.
Gitea exists so that more features can be added faster, not necessarily keeping the code quality ideal.
He was also totally ok with the fork to gitea.
Gitea exists so that more features can be added faster, not necessarily keeping the code quality ideal.
I prefer gogs. Better documentation. Original author.
For many more features I use gitlab. With gogs I'm looking for simplicity.
For many more features I use gitlab. With gogs I'm looking for simplicity.
It may or may not help with the requirements, but when I was using it 6mo - 1yr ago you could definitely disable "extras" like wiki, issue management, etc. It was nice to simplify things for users and keep them from splitting info between that and your company's solutions for things like issue management.
Yes, you can disable what you don't need. For example you can even disable the repository and have just an issue tracker.
Just wanted to add to this and point out that Gitter is already completely open-source and available at https://gitlab.com/gitlab-org/gitter/
To me, Gitlab's UI is a hybrid of Github and Bitbucket. Best of both worlds. IMO it's just a matter of time until it surpasses Github in terms of usability.
Now, you raise a good point noting that Github's been operating on losses. How will Github make enough money to sustain growth as it becomes THE go-to place for developers of all kinds and levels?
We have an open core model where some features are only available in the proprietary version. We make 90% of our money selling subscriptions for https://about.gitlab.com/products/
GitLab.com subscriptions https://about.gitlab.com/gitlab-com/ are more recent but this is growing rapidly.
GitLab.com subscriptions https://about.gitlab.com/gitlab-com/ are more recent but this is growing rapidly.
Any plans to go back to selling subscriptions for managed instances?
I'm leeching on gitlab.com today, but not enthused about it, if only because I've become disillusioned with GitLab itself.
I pay for email, and I'd be willing to pay for code hosting, too, on the following conditions:
- it's running something like Gogs/Gitea instead of GitLab
- whatever software's on the backend, my subscription needs to allow me to choose the community edition, not some enterprise version
- priced at XX/yr instead of X/mo
I'm leeching on gitlab.com today, but not enthused about it, if only because I've become disillusioned with GitLab itself.
I pay for email, and I'd be willing to pay for code hosting, too, on the following conditions:
- it's running something like Gogs/Gitea instead of GitLab
- whatever software's on the backend, my subscription needs to allow me to choose the community edition, not some enterprise version
- priced at XX/yr instead of X/mo
We don't have plans to sell subscriptions for managed instances. We found that it was not a great experience for customers unless we would do lots of development to make it work better. And then still you always have spend time making modifications that a customers request.
You're asking GitLab people for a subscription to a code hosting service on the condition it's not GitLab. Did I miss something?
You may have missed the fact that GitLab had an employee working on Gogs/Gitea full time.
Even ignoring that, telling someone their product isn't what you want and to please offer a different product isn't an outlandish thing to say.
Even ignoring that, telling someone their product isn't what you want and to please offer a different product isn't an outlandish thing to say.
> priced at XX/yr instead of X/mo
I understand I risk looking like an idiot but did you mean X per user per month? If not, what's the difference?
I understand I risk looking like an idiot but did you mean X per user per month? If not, what's the difference?
No.
The difference between XX/yr and X/mo is that the latter is a tactic that relies on perceptual psychology to downplay the cost, same as when you see something priced at $3.99 instead of $4. It might be important to clarify that when I say XX/yr what I mean by XX is ~50USD. That's a reasonable price for a small instance (especially since the current going rate for something comparable is $0). Something priced at $8–9/mo, however, costs twice as much, even though the monthly pricing scheme helps to hide it. If you're buying hosting for your code, you don't really need the flexibility of monthly pricing. (What're you gonna do, spin up some short-lived instances for as long as you need them and then shut them down when you're "done" with them? No. The expected user model for code hosting is one that's cumulative.)
Side note: charging per user per month for a hosted instance would be pretty arbitrary, anyway. Put a cap on instance size, workload, number of simultaneous requests, and daily or hourly data in and data out, not on number of users. Charging by the user for a hosted instance is very nearly unashamed rent-seeking. The only reason it makes sense for GitLab EE is because it's on-prem.
The difference between XX/yr and X/mo is that the latter is a tactic that relies on perceptual psychology to downplay the cost, same as when you see something priced at $3.99 instead of $4. It might be important to clarify that when I say XX/yr what I mean by XX is ~50USD. That's a reasonable price for a small instance (especially since the current going rate for something comparable is $0). Something priced at $8–9/mo, however, costs twice as much, even though the monthly pricing scheme helps to hide it. If you're buying hosting for your code, you don't really need the flexibility of monthly pricing. (What're you gonna do, spin up some short-lived instances for as long as you need them and then shut them down when you're "done" with them? No. The expected user model for code hosting is one that's cumulative.)
Side note: charging per user per month for a hosted instance would be pretty arbitrary, anyway. Put a cap on instance size, workload, number of simultaneous requests, and daily or hourly data in and data out, not on number of users. Charging by the user for a hosted instance is very nearly unashamed rent-seeking. The only reason it makes sense for GitLab EE is because it's on-prem.
Thank you for explaining it to me. It totally makes sense.
I can't help but think of the old "what are you trying to optimize for?" question though. Gitlab.com is OK for me because I don't make money writing code so I'm OK just getting free private repositories and any ci stuff I get is just gravy. I used to think "how will they ever make money?" and this makes sense.
I read this other story about how a DNS service was getting rid of its free tier because the free tier users can't convert. I think gitlab and github have found a good opportunity by giving away free service to free and open source software which means people will have experience using the service and might just keep using it at work (haven't checked but I'm sure github enterprise is not cheap).
I can't help but think of the old "what are you trying to optimize for?" question though. Gitlab.com is OK for me because I don't make money writing code so I'm OK just getting free private repositories and any ci stuff I get is just gravy. I used to think "how will they ever make money?" and this makes sense.
I read this other story about how a DNS service was getting rid of its free tier because the free tier users can't convert. I think gitlab and github have found a good opportunity by giving away free service to free and open source software which means people will have experience using the service and might just keep using it at work (haven't checked but I'm sure github enterprise is not cheap).
GitLab is priced at XX per user per month. It can be paid annually. See https://about.gitlab.com/products/
I am a GitLab reseller and offer a 10% discount to HN users.
I am a GitLab reseller and offer a 10% discount to HN users.
I use their community edition and barring few hiccups while deleting auto-merged branches, the whole product is beyond terrific. Highly recommended to host it yourself and have your source on it
Thanks for the kind words. BTW we fixed the hiccup you speak about. When you now create a merge request we added an option to set the state of 'delete branch on merge' on the merge request. You can set this to give a suggestion to the person merging, and it is off by default.
Given that git has such a distributed nature, couldn't you simply move over your code to Gitlab if and when Github actually is on the verge of shutting down?
I'm glad that Gitlab exists, however the lazy person in me sees no immediate need to use it. Even if all Github datacenters are destroyed by an asteroid, copies of repos I care about will still be around in enough people's computers to be able to recover.
I'm glad that Gitlab exists, however the lazy person in me sees no immediate need to use it. Even if all Github datacenters are destroyed by an asteroid, copies of repos I care about will still be around in enough people's computers to be able to recover.
What about issues, wiki and other non-git data?
(Nit: The GitHub wikis are also git repositories. https://help.github.com/articles/adding-and-editing-wiki-pag...)
But anyway, the same argument could be made of an asteroid hitting your own datacenter with self-hosted GitLab instead.
But anyway, the same argument could be made of an asteroid hitting your own datacenter with self-hosted GitLab instead.
Those can be extracted. Way more relevant imo: Links to your repo. For a mildly successful project a key part are external links pointing to your project. Those will point to a wrong location and you won't have control.
IIRC GitLab can import GitHub issues straight from the UI.
Also PRs will be imported, milestones, labels and more: https://docs.gitlab.com/ce/user/project/import/github.html#o...
> You can self host it which is cool and means that if the company's funds dry up and they stops development (hopefully never), you can continue using the product.
You still have a git repo on both github and bitbucket, even if they stop development you will be able to download your code and host it anywhere you want. No?
You still have a git repo on both github and bitbucket, even if they stop development you will be able to download your code and host it anywhere you want. No?
Code yes. Issue tracker and other features? Not so easy.
It's web UI used to be way slower than GitHub. Has this improved?
We're really committed to improving the overall performance of GitLab.
You can take a look at some ongoing performance-related issues at https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf... as well as some already completed improvements at https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...
There's also a plethora of ongoing efforts on making our hosted instance GitLab.com even faster. Lots of issues to look over at https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...
You can take a look at some ongoing performance-related issues at https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf... as well as some already completed improvements at https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...
There's also a plethora of ongoing efforts on making our hosted instance GitLab.com even faster. Lots of issues to look over at https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...
Rights now our issue speed is much improved. Finally GitLab.com http://stats.pingdom.com/81vpf8jyr1h9/1902794 is faster than GitHub.com http://stats.pingdom.com/81vpf8jyr1h9/1902795 in one aspect. Still lots of work to do.
Yep, I would say so. In the past month or so, merging an MR has become as fast as github some times.
Their real-time updates like the pipeline completion signalling still has some lag. But I think the plan to improve real-time updates is on the roadmap for a big overhaul.
Their real-time updates like the pipeline completion signalling still has some lag. But I think the plan to improve real-time updates is on the roadmap for a big overhaul.
Searching is still slow but otherwise Gitlab is excellent, I'm using it every day.
It will get better when we enable Elasticsearch for the search feature. I don't think we have a canary issue but this may be useful: https://gitlab.com/gitlab-org/gitlab-ee/issues/3492
Something that I find missing is the ability to embed code snippets into other websites
I would love to see that too. Issue is at https://gitlab.com/gitlab-org/gitlab-ce/issues/8088
"New, newer, newest User Experience"
https://about.gitlab.com/2012/01/13/design-changes/
https://about.gitlab.com/2017/07/17/redesigning-gitlabs-navi...
https://about.gitlab.com/2016/06/06/navigation-redesign/
https://about.gitlab.com/2017/09/13/unveiling-gitlabs-new-na...
https://about.gitlab.com/2012/01/13/design-changes/
https://about.gitlab.com/2017/07/17/redesigning-gitlabs-navi...
https://about.gitlab.com/2016/06/06/navigation-redesign/
https://about.gitlab.com/2017/09/13/unveiling-gitlabs-new-na...
There's nothing wrong with iterating user interface design for better UX, especially when you've made reasoned decisions, based on feedback and user research, as to why the new designs will be helpful to your user base. Read through the links you've listed, and you'll notice that the latest changes are all based on usability testing and direct user feedback.
In my opinion, they're doing everything right here. They're not changing designs because some designer disliked the color or popup animations. They're arranging their functional components to align with what they're finding (experimentally) is most usable for their user base.
In my opinion, they're doing everything right here. They're not changing designs because some designer disliked the color or popup animations. They're arranging their functional components to align with what they're finding (experimentally) is most usable for their user base.
Thanks, Andrew, this is exactly what I was going to point to. We are making sure to base our UX changes on actual user feedback and research. I would also say that GitLab's UX has to evolve in pace with the product. As we add features to support 'idea to production', we need to make them easy to find and intuitive to use.
I followed the issue on iterating for the redesign. I wouldn't say they followed any experimental methods very closely for this release. It very much came off as something where they picked a release date ahead of time and decided that's when they'd ship. New iterations didn't follow a continuous plan-do-check loop; everything was handled more like do something, get feedback, figure out something that you feel addresses that feedback, and then consider it done.
I don't know whether this comes off like I'm complaining. That's not what it's supposed to be. (I actually liked the [original] redesign announced over the summer.) I'm just here to explain what I saw.
I don't know whether this comes off like I'm complaining. That's not what it's supposed to be. (I actually liked the [original] redesign announced over the summer.) I'm just here to explain what I saw.
"New iterations didn't follow a continuous plan-do-check loop; everything was handled more like do something, get feedback, figure out something that you feel addresses that feedback, and then consider it done."
We are never done. We will always be iterating and improving. Much of the feedback we received confirmed assumptions we already had but wanted to test, such as collapsing the navigation, improving breadcrumbs, etc. Other feedback was new and we were challenged to solve those. Everything that was added to this release will undergo a round of user testing and be subject to iteration.
It does not sound like a complaint at all @carussell, thanks for the feedback.
We are never done. We will always be iterating and improving. Much of the feedback we received confirmed assumptions we already had but wanted to test, such as collapsing the navigation, improving breadcrumbs, etc. Other feedback was new and we were challenged to solve those. Everything that was added to this release will undergo a round of user testing and be subject to iteration.
It does not sound like a complaint at all @carussell, thanks for the feedback.
Some decisions feel very arbitrary - how many times has the default state of "Delete source branch" changed (which is visible when you create a merge request)?
Cool set of links to pull together. Nice UI evolution case study for designers to look through. Thanks!
Edit: Do the images in the earliest post display for others? I see image missing placeholder icons.
Edit: Do the images in the earliest post display for others? I see image missing placeholder icons.
They don't load for me either, most likely a problem from when we rewrote most of the about.gitlab.com website last year. I'll look into it, I'm also interested to see what it looked like in 2012 :D
EDIT: It looks like the images are attempting to load from an old Wordpress blog which is no longer around, with a quick search I couldn't seem to find anything with similar file names in the current website repository :(
EDIT: It looks like the images are attempting to load from an old Wordpress blog which is no longer around, with a quick search I couldn't seem to find anything with similar file names in the current website repository :(
Agree, they really heading to the right way. Btw. can't load images from the first link too!
The biggest joke of this is we've all (their loyal users) been clamoring for months and months on end for Group level issue boards and now we get a slap in the face because they released it for EEP only meaning thousands of paying customers apparently are not paying enough to be able to link issues from two projects to one board like we've been able to do in Jira for months - it honestly makes me want to just switch to Github Enterprise and Waffle.io out of spite
Thanks for the feedback. Our goal of 10.0 was to release a version of group boards that serves the needs of large organizations. So we built the feature with multiple group boards in mind. We are considering bringing a version of group boards to CE as many of our users are telling us it makes sense for smaller organizations as well.
Please see below the ongoing discussion:
https://gitlab.com/gitlab-org/gitlab-ee/issues/928#note_4132...
https://gitlab.com/gitlab-org/gitlab-ce/issues/38337
Please see below the ongoing discussion:
https://gitlab.com/gitlab-org/gitlab-ee/issues/928#note_4132...
https://gitlab.com/gitlab-org/gitlab-ce/issues/38337
i was hoping someone would mention this. we have about 40 people using gitlab ee at work, we are a microservice heavy shop and we were really looking forward to group level boards.
this should absolutely be a feature in EES. i can't justify the $7,200/yr for just that feature, i'm sure my two product guys could, but the rest of the team is indifferent. apparently only organizations with 500 or more users can benefit from this feature.
this should absolutely be a feature in EES. i can't justify the $7,200/yr for just that feature, i'm sure my two product guys could, but the rest of the team is indifferent. apparently only organizations with 500 or more users can benefit from this feature.
FWIW I am working on a multi-group issue board for CE (I guess it will work for EE too).
Are you planning on offering that outside of the Gitlab CE codebase, or are you trying to get a MR approved into CE?
I've wondered a lot about whether they would accept MRs into CE which implement a feature that they ship in one of the EEs
I've wondered a lot about whether they would accept MRs into CE which implement a feature that they ship in one of the EEs
Gitlab is great when you self host it, but not so much using their service, you can take a look at https://twitter.com/gitlabstatus see how often they have breaking problems. Not to say this cannot happen, but they have considerably higher compared to others. But, for feature wise they are also great, but I do not see how this deep integration with Kubernetes will work out, making the core product more complicated and focused on single target. Not that you cannot write your own CI, but marketing it Auto DevOps when it does only K8s does not seem right to me.
Thanks. GitLab.com is indeed not as available as it should be. We're making progress but not as fast as we planned. Making GitLab.com more usable of a big part of our goals https://about.gitlab.com/okrs/
We think Kubernetes is the future operating system and we'll continue to add features specific to it. But we realize that only a few organizations are using it today. If you don't have Kubernetes you can still use parts of Auto DevOps, such as the Auto Code Quality.
We think Kubernetes is the future operating system and we'll continue to add features specific to it. But we realize that only a few organizations are using it today. If you don't have Kubernetes you can still use parts of Auto DevOps, such as the Auto Code Quality.
Yeah, we've been committed to improving performance and uptime on GitLab.com for over a year now, we've heard this feedback a lot and take it to heart. It's definitely been steadily improving, and we're working on getting downtime-less deploys as soon as possible.
You can see some of the issues tracked in our GitLab.com infrastructure issue tracker here: https://gitlab.com/gitlab-com/infrastructure/issues (for security reasons not everything is visible to outside users)
You can see some of the issues tracked in our GitLab.com infrastructure issue tracker here: https://gitlab.com/gitlab-com/infrastructure/issues (for security reasons not everything is visible to outside users)
The most important feature to me is that gitlab allows to setup unlimited number of private repos.
As is bitbucket.
True. But AFAIK gitlab.com doesn't limit number of members for a project.
Correct, our free plans offers unlimited private projects and collaborators and 2,000 CI pipeline minutes per month on our shared runners https://about.gitlab.com/gitlab-com/
Just to let you know, I'm teaching intro programming classes, and using your service heavily because of this. Thanks !!!
Awesome! We're working on a Cloud IDE to make your life your life even easier. Less setup for your students.
I gotta say--I love gitlab. We use a self-hosted version of it and it's fantastic. I think the best thing about it is the extra features don't bog down the interfaces. With tools like JIRA, or even github, it seems that to "use more" of it, you kinda nuke the new user experience by making interactions unnecessarily complicated. GitLab seems to generally work and keep simple while adding a whole lot--they balance it well.
Recently, I added a webhook that takes all our GitLab pushes and parses out JIRA information and automatically handles that sort of business-level logic (issue handling, visibility, etc.), which means I spend less time boring myself to death in JIRA. It's just one facet of what I appreciate about GitLab.
Recently, I added a webhook that takes all our GitLab pushes and parses out JIRA information and automatically handles that sort of business-level logic (issue handling, visibility, etc.), which means I spend less time boring myself to death in JIRA. It's just one facet of what I appreciate about GitLab.
> Recently, I added a webhook that takes all our GitLab pushes and parses out JIRA information and automatically handles that sort of business-level logic
Have you found a good solution for auto-linking to JIRA tickets from GitLab comments/commits/etc without turning on the the included JIRA Integration? I want to continue using Gitlab's native issues, and the included JIRA integration replaces the native Gitlab issues with JIRA tickets, which is such a colossally boneheaded idea.
Have you found a good solution for auto-linking to JIRA tickets from GitLab comments/commits/etc without turning on the the included JIRA Integration? I want to continue using Gitlab's native issues, and the included JIRA integration replaces the native Gitlab issues with JIRA tickets, which is such a colossally boneheaded idea.
Thank you for the feedback.
As of GitLab 9.4, you are able to use both JIRA integration together with native GitLab issues. If JIRA integration is configured inside your GitLab project, the issues menu item in the navigation still goes to native GitLab issues, and you can use GitLab issues as usual.
As of GitLab 9.4, you are able to use both JIRA integration together with native GitLab issues. If JIRA integration is configured inside your GitLab project, the issues menu item in the navigation still goes to native GitLab issues, and you can use GitLab issues as usual.
I think I must be in the test group or something, because I saw no change from my current GitLab instance (cloud hosted).
I've been a fan of GitLab for a while, and I like how they continue to iterate and improve it. As far as being a full suite for software development, GitHub and BitBucket can't match it. GitLab seems to be charging ahead faster than the others, and for that, I salute them.
I've been a fan of GitLab for a while, and I like how they continue to iterate and improve it. As far as being a full suite for software development, GitHub and BitBucket can't match it. GitLab seems to be charging ahead faster than the others, and for that, I salute them.
Is the Gitlab team looking at TruffleRuby , especially after the release of Java 9? It could mean a much higher performance and better packaging in general.
Right now the next step would be enabling multithreading with Puma. Throughput is acceptable, packaging with Omnibus is working well. So the problem to solve is memory usage. We hope multithreading can help there.
Been using gitlab for a while, I love it -- but the new look in 10.0 is bleghghgh,
They say you can change the theme but why not make the default grey or white instead of that awful indigo? And they do not allow a default theme from the admin section (that i could find).
Im also slightly concerned about the feature creep here, I love that they try out new devops and CI tools but I wish you could get just a stripped down interface and turn the features you want on and off. The UI is becoming cluttered and the RAM usage is climbing because of it - not everyone is running hot-rod servers and a huge dev team!
Besides that good work and thanks for having a community edition, it keeps small teams like mine alive!
They say you can change the theme but why not make the default grey or white instead of that awful indigo? And they do not allow a default theme from the admin section (that i could find).
Im also slightly concerned about the feature creep here, I love that they try out new devops and CI tools but I wish you could get just a stripped down interface and turn the features you want on and off. The UI is becoming cluttered and the RAM usage is climbing because of it - not everyone is running hot-rod servers and a huge dev team!
Besides that good work and thanks for having a community edition, it keeps small teams like mine alive!
It's their brand coloring.
In a windows environment, any reason to use Gitlab over TFS?
CI in Gitlab is one YAML file you check into source control with each project. CI in TFS is navigation through a bunch of menus.
Gitlab can be fully installed as one Docker container, plus a second container if you want a CI runner (although, to be fair, it took me a while to make them talk to each other). Upgrading Gitlab is just starting a container for the new version with the old one's data. TFS is... not as straightforward.
Also, cost.
Gitlab can be fully installed as one Docker container, plus a second container if you want a CI runner (although, to be fair, it took me a while to make them talk to each other). Upgrading Gitlab is just starting a container for the new version with the old one's data. TFS is... not as straightforward.
Also, cost.
The amount of bugs my old company ran into with TFS was just astounding. Sometimes a bug would pop up that would prevent all devs from committing, and instead of patching it Microsoft would just give us a 6 page work around cheatsheet.
Also we couldn't push enough performance out of it, even on it's own VPS. Once you have 50+ devs pushing to TFS it just gets slow as dirt. Some 5kb commits would take 3-5 minutes.
From my own experience, I don't suggest it as I don't believe it is a well polished or reliable product.
Also we couldn't push enough performance out of it, even on it's own VPS. Once you have 50+ devs pushing to TFS it just gets slow as dirt. Some 5kb commits would take 3-5 minutes.
From my own experience, I don't suggest it as I don't believe it is a well polished or reliable product.
The CI and WebUI is eons better, not to mention just having git's diff-ing and conflict resolution (assuming you were referring to TFS proper and not git in TFS 2013+).
We switched a large Nodejs project from TFS to GitLab and it's been night-and-day on our productivity.
We switched a large Nodejs project from TFS to GitLab and it's been night-and-day on our productivity.
I am not sure what do you mean by TFS proper vs TFS 2013+
I meant TFS + Git , the lastest TFS is TFS 2017
I meant TFS + Git , the lastest TFS is TFS 2017
I've only used VSTS, not TFS on premises, but my experience is that all the "cool" VSTS features(complex work items, custom queries, kanban boards, etc) I just don't find much of a use for. These features are focused on heavy management requirements for very large teams. I can get most of what I want from work items via github/gitlab label tagging, the custom queries are only useful if you actually use the complex features of the work items, and so on.
Meanwhile, the critical feature for me is a easy-to-write and easy-to-read history of discussion on a work item. This is nascent in VSTS. The description and discussion blocks don't even support markdown; The description box has its own WYSIWYG editor, the discussion block barely supports linking to work items(but http links aren't recognized, which makes it awkward to link to e.g. the code or the wiki). File attachments go in a separate tab, so it's difficult to contextualize what part of the discussion they are for.
Speaking of the wiki, it was just introduced and it's pretty basic. For some reason you can only place attachments in a single special directory, which makes editing it through the repo annoying - I want to colocate my pages and their images/attached files, like you would do normally...
I also have some minor quibbles like the stupid iteration workflow(add iteration to project, go to team, select project iterations for team...talk about optimizing for the edge case).
I think VSTS should really replicate the github/gitlab/etc issue description and discussion page. Past that, they seem to be pretty good at keeping feature parity(the pull requests are nice, the CI is okay).
Meanwhile, the critical feature for me is a easy-to-write and easy-to-read history of discussion on a work item. This is nascent in VSTS. The description and discussion blocks don't even support markdown; The description box has its own WYSIWYG editor, the discussion block barely supports linking to work items(but http links aren't recognized, which makes it awkward to link to e.g. the code or the wiki). File attachments go in a separate tab, so it's difficult to contextualize what part of the discussion they are for.
Speaking of the wiki, it was just introduced and it's pretty basic. For some reason you can only place attachments in a single special directory, which makes editing it through the repo annoying - I want to colocate my pages and their images/attached files, like you would do normally...
I also have some minor quibbles like the stupid iteration workflow(add iteration to project, go to team, select project iterations for team...talk about optimizing for the edge case).
I think VSTS should really replicate the github/gitlab/etc issue description and discussion page. Past that, they seem to be pretty good at keeping feature parity(the pull requests are nice, the CI is okay).
Ok, you didn't specifically mention git in TFS so I assumed you meant TFVC.
TFS (even Team Services) is lacking behind just a little bit as far as features go. Specifically, No user interface for forking repos (though I think Team Services is getting this soon).
I don't know, do you find any reason to use Apache over IIS?
I wish Gitlab supports Mercurial
We have no plans to support Mercurial, unfortunately.
Hglab doesn't have quite the same ring to it.
Gitlab is great. We've got it setup on a HPC cluster and use CI to automate Ansible configuration for the whole cluster (mostly.. not the VNX). We also use it to automate testing of new algorithms on clinical datasets, something we could not do with anything else and so little effort.
Great to hear that. Thanks for posting.
I hope they didn't change the UI too often, even if they change the UI I hope only small part.
After last change, can't remember which version since it already few month ago, I leave for gitea.
Too many times my co-worker asking for location of x in menu. Where is X, where is Y
After last change, can't remember which version since it already few month ago, I leave for gitea.
Too many times my co-worker asking for location of x in menu. Where is X, where is Y
So how is Gitlab compared to GitHub?
It has some features over GitHub like integrated CI and integrated Docker registry. I think the UI design is better. Merge (pull) requests and issues have some extra fancy stuff like multiple assignees and discussions on code that can be marked as competed or not.
It lacks in user base (which might not matter for internal use) and performance and reliability. It can be slow and it goes down occasionally. It hasn’t been enough of a problem for my company to move back to GitHub.
These observations only apply to the hosted GitLab.com, as I don’t self host I don’t know the differences there. I have both public and private personal projects as well as private company projects on it.
It lacks in user base (which might not matter for internal use) and performance and reliability. It can be slow and it goes down occasionally. It hasn’t been enough of a problem for my company to move back to GitHub.
These observations only apply to the hosted GitLab.com, as I don’t self host I don’t know the differences there. I have both public and private personal projects as well as private company projects on it.
Enterprise Gitlab is miles beyond enterprise Github IMHO, if for nothing else just the integrated CI/CD. Trying to set up a third party enterprise CI/CD and then getting it to play with enterprise Github is a pain in the ass.
With Gitlab you set up a runner instance with their CLI and you're good to go.
With Gitlab you set up a runner instance with their CLI and you're good to go.
Yeah I was really surprised how easy their CI runner was to set up (I didn’t want to use the public ones for my company’s projects). Like you say it’s pretty much “install from apt, run this command”. Wonderful.
From a UI POV, even enterprise Bitbucket (formerly Stash) is way ahead of Github Enterprise.
> Merge (pull) requests and issues have some extra fancy stuff like multiple assignees and discussions on code that can be marked as competed or not.
Perhaps that's unclear, but as of 9.5.x you can assign an issue to multiple users, but you can only assign a merge-request to one user.
Being able to assign a merge-request to multiple users would be very useful..
Perhaps that's unclear, but as of 9.5.x you can assign an issue to multiple users, but you can only assign a merge-request to one user.
Being able to assign a merge-request to multiple users would be very useful..
We have an issue for that here https://gitlab.com/gitlab-org/gitlab-ee/issues/2004, the UX team is pushing hard to get it scheduled asap. Give the issue a thumbs up!
It's getting better all the time. Gitlab has several large advantages over github, the major one for me is that it allows you to self-host and for companies that are conscious of their IP value and access this may sway their decision.
It's not quite as polished as github yet but with their recent funding round I would expect gitlab to pick up steam and close the gap even further. For day to day use I'd say they are now at 95% feature parity or even better, and in some cases it is actually ahead.
It's not quite as polished as github yet but with their recent funding round I would expect gitlab to pick up steam and close the gap even further. For day to day use I'd say they are now at 95% feature parity or even better, and in some cases it is actually ahead.
GitHub has an on-premises offering as well though there's no free tier.
One should also be cognizant that their on-prem lags behind the cloud offering, so don't expect to launch GitHub Enterprise and get the same features as .com
I run and maintain a massive GitHub Enterprise installation. Features that make their appearance on .com end up in Enterprise about 3-4 months later. In an enterprise environment, I'm totally fine with GitHub testing those new features on their 15 million .com users first.
Compares very favorably IMO, but you'll probably want to read their marketing pages or try it yourself.
I like it for the free private repos and the built-in CI that's pretty easy to use. At one point I was using Trello to manage my plans, but GitLab's issue board works just as well to my surprise!
I still switch between Hub and Lab, but seeing GitLab's growth makes me smile.
I still switch between Hub and Lab, but seeing GitLab's growth makes me smile.
Glad to hear that our issue boards are a complete alternative, that was our intention when we launched them a little more than a year ago. They've evolved significantly since then https://about.gitlab.com/2017/08/23/issue-boards-anniversary...
Some of that discussion revolves around whether one wishes to be able to audit, and possibly update, these very core services in use. Comparing apples to apples may produce one outcome, comparing the liberty of eating them may produce another.
I personally think GitLab is hungrier, and have some really great features, but I haven't had any contact with their support to know if something goes wrong that one can get unstuck quickly
I personally think GitLab is hungrier, and have some really great features, but I haven't had any contact with their support to know if something goes wrong that one can get unstuck quickly
Over here one of the definitive advantages of GitLab is that since we're a Ruby shop we can self-support things in case of emergency, either via gitlab-rails or gitlab-psql commands or patch right into the code to get things unstuck ASAP or even do some unsupported stuff.
I use git mostly for solo projects, are there advantages to hosting on gitlab versus GitHub versus bitbucket ?
The big one is that github doesn't provide free private projects (it is nice to be able to have some private repos if/when you need them).
Other than that, for casual use, they are all excellent products
Other than that, for casual use, they are all excellent products
You can self host it which is cool and means that if the company's funds dry up and they stops development (hopefully never), you can continue using the product. With Google Code shut down and Github losing 66 million in 9 months in 2016, it's an important question to ask about where you keep your source code.
Featurewise, I haven't noticed anything that I can't use Gitlab for that I wanted to do. The interface is still less familiar to me than Github, but that seems to be a function of it being changed relatively often as well as the time spent looking at it.
I also like how much Gitlab embraces open source. They recently acquired Gitter and will open source it. Even though I mainly just use it as an alternative to the still more popular Github, I'm considering picking up one of the Enterprise plans to help ensure the development pace continues like this!