What got us initially was the free private repos before github had that.
We are now a paying customer.
Their integrated CICD is amazing. It works perfectly for all our needs and integrates really easily with AWS and GCP.
Also their customer service is really damn good. If I ever have an issue, it’s dealt with so fast and with so much detail. Honestly one of the best customer service I’ve experienced.
Their product is feature rich, priced right and is easy.
GitLab employee here. Thanks so much for the kind words - I shared it on our internal Slack as a #thanks [1] to the whole team (and specifically our support engineering group who I agree are AMAZING).
My experience is quite different. I am experiencing a 500 error on every push to the container registry in my project, I contacted GitLab support over two weeks ago, and the person has clearly no idea how to debug this (and seems very unfamiliar with GitLab, for example couldn't find the web page for my container registry from my Docker image name, e.g. registry.gitlab.com/my/project -> gitlab.com/my/project/container_registry). Very disappointed.
My company switched to BitBucket in order to pinch pennies, and now I weep when I have to get Jenkins and BitBucket to play nice with each other or to do something. GitLab CI just works, is easily horizontally scalable without paying exorbitant prices for more "agents", etc... I miss GitLab...
My company is currently considering switching away from GitLab CI/CD as well as we've found no way to increase the number of available minutes (2000 on our tier I believe, doesn't last very long) without upgrading many tiers before we can even scale it at all. Can I ask what plan you're on? I'm assuming since your company wants to pinch pennies you're also fairly small?
> Can I ask what plan you're on? I'm assuming since your company wants to pinch pennies you're also fairly small?
We are small compared to FAANG, but not "small" small (~4000 employees total).
We run our own self-hosted GitLab EE instance, so we have "infinite" CI minutes in that the runners are on all our own hardware. So CI is "free" (but we pay for and maintain our own hardware/VMs so I'm not sure how much that costs).
Might be useful for you depending on how long your builds take. I haven't personally used it but I it's one of the things on my todo list for next month.
And setting up your own runners is quick and super easy. You can have the administration thing and the build jobs run in their own docker containers, so you have no tough dependencies what distro to run on your CI machine. The only detail I find confusing is the terminology. The administration thing runs in a container called gitlab-runner. The build jobs run in something called runner executor IIRC. These are several containers per job, each with a machine generated name. Partly readable, but can still be confusing if you have lots of them and you need to debug something. On the other hand I assume you cannot debug in the cloud at all (have never tried) so the comparison is still "can be a bit painful" against "impossible" in favor of your own docker-based runners.
Are you using any of the paid Jenkins plugins in the Atlassian Marketplace? Does BitBucket show CI build status on PRs? Can you retry builds from BitBucket or do you have to visit Jenkins dashboard to retry a build? (Just curious, we recently switched, and I'm finding Jenkins to have a much steeper learning curve than GitLab CI had)
Using all free plugins in our place.
There is a free bitbucket status notifier that will update the CI build status on a branch / PR.
You have to retry via the Jenkins dashboard.
My company was using GitHub and then we were purchased by a company using BitBucket and had to switch over. We don't even use the CI/CD features but IMO the BitBucket experience is just horrible overall.
Concur, trying to get my company to switch. It's the best solution to all modern ci/cd and devops problems: deployment figured out, easy to configure stages, integrate with docker and run integration tests out of the box.
Does anyone know why GitLab hasn't taken off so much amongst open source projects?
I have no horse in the race (indeed, I'd love for there to be more variety in this space) but one of my jobs is to link to open source repos and I've just checked.. and the last one I linked to was in December 2018. In the niches I cover, almost no-one seems to actually using GitLab for their open source repos.
We have over 700 users on https://lab.civicrm.org (a FOSS CRM for non-profits). While bits of the project still rely on Jenkins and Github, having most of our community on Gitlab really changes the dynamics of the project.
At first people were worried about losing contributors because "everyone is on Github", but increasingly it's the other way around. We have a lot of accidental techies who start issue tracking, testing patches, etc, and so it's nice to have a clear project structure.
It's the network effect. GitHub was first-to-market. Almost all open source contributors have a GitHub account these days. Many older projects started there long before GitLab was a viable competitor.
Now assume you're starting a new open source project. Most of the other open source projects you've seen are hosted on GitHub. Most of the other developers you interact with have GitHub accounts. GitLab has all the same features and is slowly growing, but still isn't nearly as popular as GitHub is. Which platform do you choose for hosting your project?
GitLab is certainly a worthy competitor, but unless there arises a strongly compelling reason to switch I can't really see it overcoming that barrier and becoming the new de-facto standard for open source projects for quite some time.
I disagree that signing up for an account at gitlab.com is a barrier. Anyone willing and capable to make contributions won't be stymied by that step. There's even a "Sign in with GitHub" button..!
I think the biggest thing is the context switching between different projects. I have open source projects that I wouldn't be able to move to GitLab as I would have to coordinate the move with all the other collaborators and make sure the users of the repository are aware that the new code will be in GitLab.
Gitlab doesn't have even basic notification centre, people been asking it for years.
Github API integration is stellar, API token permissions can be configured granularly, Github apps marketplace is awesome way to start using third party services.
First class integration experience is opposite from Gitlab goals, they try to be everything and capture every single usecase and it shows .
Hi, we do believe in the single application offering the best long term user experience and outcomes, but do understand that all of our features may not work for everyone. This is happens for a variety of reasons (completeness, migrations, specific project requirements, etc.)
We're also working to further improve our integration options, with a dedicated team: https://about.gitlab.com/direction/ecosystem/. This team will be responsible for our broader API, an upcoming SDK, as well as continuing to improve our existing integrations like JIRA and Jenkins. This team is just getting under way, but I wanted note our investments here.
> Github API integration is stellar, API token permissions can be configured granularly, Github apps marketplace is awesome way to start using third party services.
Integrations go both ways. While Gitlab debates how to strip down Junit XML test result processing or represent arbitrary artifacts , Github has Checks API https://developer.github.com/apps/quickstart-guides/creating... where any third party system can provide feedback on a pull request and even veto it's merge.
Gitlab has many strengths, but integrations is by far the weakest one.
It's a barrier not just because of the sign up process which might only take a minute or less.
It's the ongoing thoughts that go through your mind like using github 99% of the time but having to context switch to a completely different app / UI for that 1 other project that uses gitlab. Unless that 1 project is incredibly useful then most of the time you'll talk yourself out of signing up or even browsing the repo (let alone contribute to it).
It's almost like people who use mailing lists for bug reports. It's such an out of place / cumbersome thing to sign up for vs filling out a github issue that you've done a 100 times already.
The power of familiarity is real. It takes astronomically sized benefits to get people to switch and from what I've seen gitlab has not done that (not because they are bad, it just hasn't happened yet) and the proof is in the results. If they did offer a massively better service than github then people would have already switched for open source projects.
You might be right but it sounds pretty thin. Are developers really roaming the internet aimlessly in search of something to develop on, and decide based on whether it's hosted on github or gitlab? That's not consistent with my experience, I use gitlab, bitbucket, github, gnu savannah, etc, due to various scattered projects and I don't find that the git hosting platform even registers as a consideration when finding projects to contribute to.
On switching -- from GitHub, yes you might need some compelling reasons to go through all that resetup work. Migrating to GitLab from some ageing bespoke system is a much easier choice.
Or prefer open source software. If all fails we can read the source or even patch it.
That said I must say it has worked well enough for us, that the occasional swearing that it does not do what we want has been the more comfortable solution than really patching it:)
A related note is that Github repos have much better SEO than gitlab repos. It is probably a combination of Github being weighted more heavily by search algorithms, but also because Github has a far better network effect. I've tried searching for a repo that is hosted on Gitlab, that is an extremely well written Pytorch library with hosted HTML documentation, etc, and it wouldn't even show up on the first page of Google search results. Meanwhile, a couple of repos on Github with the same or similar names (of far lower quality) were in the top-5 results. The only way I could reliably find the repo is by adding "Gitlab" to the search terms.
I'm also convinced that the repo would be quite popular were it posted on Github because many related Pytorch repos on Github with far poorer code quality and documentation have 1000+ stars. As much as I love Gitlab, it is very hard for me to use anything but Github when working on an Open Source Project that I want to get lots of eyeballs on and hopefully the satisfaction of having other users use my code.
Search in general in Gitlab is painful. Searches seem to require 3 or more characters, but if you put two you just don't see any results. No warning saying add more. Pretty intuitive.
Gitlab is one of the few products where I look forward to each release. You guys are doing a great job at keeping interest high and your communication is great.
Not sure what counts as organic, but if I find a project that impresses me on github I often click through to their repos and scroll through to look for other gems. I found bottle.js that way a week ago.
I also cross reference people from Twitter if they seem smart. And I click back and forth between NPM pages and GitHub pages to see people’s work.
Some of that is pretty doable if they switched to Gitlab... except the Twitter cross reference, just because I would have to remember to search both gitlab and GitHub.
We are offering our top tiers (Ultimate or Gold) for free to open source projects [1]. You can see the complete list in our repo [2]. Some of the most recent projects that received our free license are Arch Linux, the Tor Project, edX (currently migrating). Just to add a few more: Drupal, Haskell, VLC, Kali Linux, Lineage OS, and more on this comment [3].
Part of the application for open source projects here requires you specify how many "seats" you need.
> The number of seats is the number of different users that will use this license in the next year.
This seems counter to how many open source projects work where contributors come out of nowhere to make a contribution and may or may not stick around. How does this work when you have hundreds or thousands of unique contributors a year, and you have no good way of predicting?
IIRC seats are calculated based on monthly active users, and are a soft cap: we've outgrown our license, so we will have to retroactively buy the missing seats on our next license renewal.
I expect this is no different from a OS license, except that that OS project doesn't pay for the license.
I'd like to share more data on the UX front. There are two efforts underway to establish the experience baselines [1] as well as a common design system [2]
Hopefully these efforts allow us to look at our UX holistically, and to focus on making high-quality components that are used throughout the product.
One thing that bugs me really hard about gitlab.com (and gitlab ce) is the broken flow when I come about an interesting repo and want to star it. I'm logged out, click on "Star", log in and I'm at my profile. I have to navigate back to the repository in question and click "Star" again.
Other than that it's really great software. I wouldn't want to miss running Gitlab CI.
The github pull request UI is severely lacking. Even something as simple as being able to see changes that address PR comments is surprisingly difficult.
When I was applying for jobs recently, a few of them had explicit GitHub link fields, sometimes even regex validated to ensure ONLY GitHub links got posted.
Echoing that. I was looking for several jobs as a senior dev. 15 years of work experience in corp. environments do not necessarily result in much GitHub activity -- I discarded every opening that required linking your private repo.
I'm guessing GitLab will slowly gain more and more traction in the OSS community. It hasn't been around for nearly as long as GitHub, and has several compelling reasons to be used over GitHub specifically for open source projects.
> Does anyone know why GitLab hasn't taken off so much amongst open source projects?
The marketing is pretty bad for one. Go to gitlab.com and you see a site that is mostly extolling the virtues of their commercial product and pricing. There is a "try gitlab for free" but it is aimed very much as a try-before-you-buy for businesses. That's all good and fine, but it is the polar opposite of how github went about acquiring their network. github was marketed heavily as a social site, their marketing was viral.
I don't think it is wrong, but if gitlab is trying to convey messaging that they are "social coding" platform or even an open-source project host, and not just b2b, they are doing a pretty poor job of it.
I recently started to ship around for hosting solutions and this showed me how much github is leeching off the openly visible projects. Everything is focussed on making projwcts and users as visible as possible. Site wide search, directories of hosted projects, free user account to get started as a contributor...
Extreme SEO for hosted public projects aerves as a marketing trojan hirse for their commercial offers. At the same time, the networking effect forces everybody to stay on github or massively lose visibility. The frustrating part is that most other hosters don't get that - especially none that support some actual VCSes instead of
a glorified patch database manager.
If I could stomach writing all the web frontend and plumbing stuff for a hosting service and doing all the marketing, I'd try to start my own. I have harder and more interesting problems to solve, though.
I work on git hosts integration, we aim to support Github, Bitbucket and Gitlab. I don't understand Gitlab api just like I don't understand their UI. It's confusing. For example while the others call Repo as Repo, Gitlab call Repo as Project, and call Tree as Repo.
SEO and the website isn't as friendly to navigate as Github is. Github makes your project look like a first class citizen while Gitlab has too much going on.
The pricing for GitHub Enterprise is "Contact Sales", which as a smallish yet privacy focused company we don't even bother with anymore. That uncertainty plus the keyword "Enterprise" have always amounted to "ridiculously expensive".
Honestly for me it's mostly because I started using GitHub first. The products aren't that different to me, mostly because I'm not a power user trying to squeeze the most of every last feature.
To overcome an entrenched competitor with network effects, the upstart has to be significantly and obviously better for a new project to adopt. To maintain market and mindshare, GitHub doesn't have to become/stay better than GitLab; they just have to be good enough, or at least appear to be.
Kudos to the team. While my current workspace is tied to GitHub, I will most certainly switch to Gitlab given the option to. Why? Only one reason: GitHub support is fucking horrible. It’s insanely bad, even for paying enterprise customers. Open a support ticket, you will get some superficial pointers to documentation, and then be completely ignored.
Their Product team is the absolute worst too. There are so many things that can make life easier for users (better configurability for CODEOWNERS notification?) and they will flat out ignore you.
Gitlab on the other hand seem much more responsive to users... their actions speak volumes. They recognized the need for integrated CI/CD with code and instead of stealing TravisCIs ideas (cough GitHub Actions Cough), they built one years ago.
I really do hope they grow to be the tool of choice for devs. GitHub has lost its way: from being the place that devs loved, to a corporate soul sucking behemoth made of a seemingly insensitive product team.
Gitlab on the other hand, release new features, have better support, give interesting talks etc. Very excited to see where they go and I wish them the very best.
That's interesting, my experience with GH support is the polar opposite – they've been stellar. Particularly their enterprise support went above and beyond when we had issues and never did I feel I got either a canned response or even had to wait particularly long to receive an answer. At one point we had an issue with a flaky load balancer sometimes dropping connections, but the folks maintaining the load balancer were adamant that it was a fault with GHE. Even though I was certain it was the load balancer, I reached out to GH for support and they not only responded with helpful tips to determine whether the GHE instance had a problem, but also helped me build my case that it was in fact the load balancer that was at fault. Turns out the issue was a broken NIC on the load balancer, and GH support were instrumental in helping us figure this out, even though a perfectly acceptable response from them would've been "not our product – good luck; have fun" or something to that effect.
Really surprised to hear about your experience with their support, mine's really been nothing but positive. To be fair, I haven't interacted with them for well over a year now since I'm no longer involved in maintaining GHE. Did support take a hit after the Microsoft takeover?
I've only been a free user on GitHub, but I've also been impressed with their support. I once had a question about how they handle a very particular situation with forking workflows and private groups.
The rep was very knowledgable and took the time to explain exactly what would happen.
This was years ago, but I appreciated the support at the time, and as a Support Manager at GitLab would still point to it as an example of a quality response.
We are Gitlab customers since 2017 and I can tell you that your expectations for what support can do for you are very unrealistic.
Per their own policy all they do is finding relevant tickets and send you there, from there on you are not their problem anymore. You as customers is also not a developer/product manager problem either, they do their planning and priotization using their own ideas and unless ticket is in the next milestone you won't even get response to your comments or suggestions for months.
There is literally nobody, who has your interests as part of their day to day agenda. Except for sales at the time of your license renewal of course :)
This time we are likely not going to renew and be switching to CE version after our current license expires.
Hi. GitLab PM here. I'm really sorry that this is your experience. Can you point me to this policy? I would like to propose a change to it given that's not reflective of how most teams do planning and prioritization.
We care very much about support issues, regularly prioritize a large portion of each release to addressing them, and can not do it effectively without ongoing involvement and feedback from the wider community.
I will say that it is sometimes hard to separate the signal from the noise, given my team currently has 3k+ open issues. Please ping me (@gweaver) on issues that are relevant to you and I'll do my best to provide a status update / more information or bring in the relevant PM who can.
> Any assistance with modifications to GitLab, including new functionality, bug-fixes, issues with alpha features or other code changes should go through the GitLab issue tracker, triage, and release cycle.
And it matches our experience as customer. We are power users and almost every single support issue we opened is a bugreport or a feature request. Support team can bring values to customers who don't read docs and have questions like "how do we do X", but for seasoned users of Gitlab you can't do much.
It was discussed at length in support tickets as well as public issues tracker, that support team refuses to be single point of contact for paying customers, instead "we are open company, here is the issue , feel free to track it [ and best of luck convincing PM to priotise it sooner]", then support ticket get closed.
This is like if you have missed delivery from Amazon, you call them, they give you driver's number, you call him, he says Police blocked roads and give local policy dept number, you call them next and they say that there is a manifestation on streets going out of control and give you leaders phone number, you call them, they tell you that energy crisis need to be solved urgently and so on... All you wanted is a replacement pair of socks, because they sent you wrong size earlier. By the way , here is a fulfilment manager phone number,ask him how come such and obvious picking error occured...
If you do end up moving to another provider, I'd be interested to see if you get a better experience. Once of the things that puzzles me, especially for an open core solution, is that companies really don't want to do custom development. Or possibly they don't want to have the difficult discussion about cost.
I'm always harping on about this, but I don't really see open source companies trying to build value the way Cygnus did. Instead of saying, "Pay us $x per seat and you get whatever we give you", say "Have as many seats as you want and pay us $x to make it do what you want". Cygnus actually did both with GCC and were quite successful at it.
It's not just Gitlabs either. I can't think of a software provider with an open core model that primarily sells software development services (Hmmm... Possibly Code Weavers now that I think about it). I remember asking this to Gitlabs ages ago and they said that they tried this model before they took VC money but that they just couldn't get it to work. It still baffles me as to why that's the case.
I can understand why your work is difficult, but still want you to deliver me great service. Bad service is bad service, regardless of the reasons.
Can you imagine sitting in a call queue and hearing, “We are sorry, but you will have to wait while we help the 2300 people in front of you.” Any sane person would think that maybe they wouldn’t have this issue if they’d hired more agents.
That obviously doesn’t map 1 to 1 on dev, but it’s the scenario thst immediately popped in my head when reading the original message.
I think it's a bit more nuanced than that, although I can certainly understand your reading. If your support ticket does end up as revealing a fault in the product or a feature request, we will close out the ticket and prefer further communication on the resulting issue. This is in keeping with our Transparency value. We want to make sure that others who are affected can also chime in, and that the resulting issue is the single source of truth.
For issues with configuration, up-time or other support-related things that aren't feature requests or bugs, we would be handling those directly.
On those cases that do result in bug reports or feature requests, it's certainly true that sometimes they aren't prioritized, don't get attention, or have milestones slip.
Again though, that happens transparently where you can interact directly with the PMs in question.
Ultimately, it is a _different_ support experience, but we believe that it's better to have our community as close to our development process as possible.
See my response to gabeweaver above. I provided feedback on our support experience on multiple occasions both privately and publically, I have nothing more to add. Gitlab is important, but not central part of my day to day duties as a DevOps lead of a small (30 Gitlab seats) start-up , I did what I can to get heard.
TLDR; support team is great for customers coming to Gitlab, but not so great once initial onboarding is done
It's not that bad. If you only use GitLab for the git repo management purpose and already had other tools for CI (e.g. Jenkins, CircleCI) and project management (e.g. JIRA) then GitLab CE works perfectly fine. The only thing that I wish would be in the CE version is the ability to approve merge requests.
6 years ago I was trying to setup GitLab CI. From memory, it was a bad experience since there were missing or incorrect pieces of crucial information. At the end they were figured out but if the status quo is still the same I believe it would not be easy to automate a rebuild.
Hello, GitLab employee. I definitely hope we've matured a lot since 6 years ago! In early 2015 there were still only 9 employees [1] compared to almost 900 now.
I can totally relate to that. In flood of notifications I missed information about expiring CC. Instead of somehow soft-locking the account they just downgraded it and all my integrations, hooks and god knows what just blowed. I managed to fix the CC in 5 minutes, but many months after I am still recovering from that disaster. Support replied that they did send warning so I should just FO.
IMO at that point since you have to rebuild everything anyway, just rebuild it with a different vendor. No reason to stay with a company that treats you like that.
That's a terrible process. As you say, a "soft lock" of some kind is the obvious fix. They are basically encouraging you to jump ship because at that point, it's a similar effort to move to another vendor.
Oh that's odd. We've been running into CC issues on our team and we were "disabled". So we had no access to our production repos but AFAIK nothing was downgraded.
That sentence seemed particularly strange considering GitHub Actions is pretty openly based on Azure DevOps, which makes sense considering GitHub's owner. Actions bears little resemblance to Travis.
They fired many of their developers and key operations folks, and service has been flaky for months. It was already poor, but is now substantially worse than almost all of the competition.
They were purchased by a private equity company. Which does not usually mean any continued development. At it's best, it means keep the thing running well and continue to wring revenue out of it. But few and far between are the private equity purchases that are at their best. It also almost always means significant cost cutting.
It's not just any private equity company, but one that is known for purchasing companies with a big subscriber base and then getting as much money out of them with the least effort.
In my experience CircleCI feels like an excellent alternative for the first few weeks/month, until you realise all the missing features, unreliability, and issues, at which point you contact support and find their support is very poor and mostly just ask you to go and "vote" for which bugfixes you want to see on their community site, where product ideas go to die.
We use them for continuous delivery, but there is no way to serialise a deployment. This is pretty critical to not shipping the wrong code at the wrong time – like shipping code that uses new database fields before the database migration to add them.
There is a third party orb that attempts to do this, but it costs significant numbers of build credits to run as it implements queueing of builds as busy-waiting, plus we've got evidence that there are bugs in it as we have seen out of order deployments.
It's very difficult or near impossible to build edge-triggered features based on build states. We want to be able to notify when the build goes red, notify for every red build, and notify when it goes green again, and just for the master/deployed branch. This is not possible (you either get all builds or no builds).
There is again a third party orb that implements some of this, but it's pretty inflexible.
We've had them remove features we were sold on. Not huge features, but we were told their billing worked one way, budgeted for it, and then they changed that because they couldn't get it to work correctly. They didn't tell us about this, except for just failing our builds as we were under provisioned on users.
Their support takes on average around 2 working days to respond, and often requires chasing to get a response. Once they do respond it's typically a fairly shallow response without much information, or that has misunderstood the issue, and so queries often take multiple rounds to get help on.
They sell a premium support package, but that is pitched as more about helping you to use the service better and I have an objection to paying for support in getting the service to work in the way it should.
Agree that support is hard, especially when dealing with a very technical product, with very technical users. As far as fixes/enhancements go: every company has to prioritize somewhere. That means not everything gets done. Limited time, limited resources.
I completely understand the limited time and resources, I can really empathise with that. However I think there are 2 ways in which they could handle this issue better:
1) It's a feature that is fundamental to continuous delivery that is missing, yet CircleCI market themselves as a CI and CD product. I think they need to be more realistic in conversations with customers, in their documentation, in their marketing material, etc, and give significant time in their documentation to workarounds and discussion of the issue.
2) They need to seriously work on their customer communication about the prioritisation system they use. Being constantly told to vote on "ideas" (when they are essentially bug fixes) is quite insulting, and as a customer makes me feel like my input is trivial, it's "nice to haves", rather than being something that genuinely matters to me. They need to have some empathy! Communicating more about the roadmap would be great. Maybe even communicating about all the things from the community site that they are doing each month would be an improvement. Right now it feels like being told our input doesn't matter.
Not sure what exact experience you made with the GitLab support but I can tell you our experience is different. It took over two months to resolve a license request we made to their support (or sales team) with multiple pushes from our side, every week. There are bugs with the CI system like an issue with the cache retrieval when multiple jobs run in different pipelines parallel to each other, that is actually blocking us from using the cache to it's meant extend and that was issued in 2016. You will find a dozens of those tickets.
Just some examples. Wouldn't say GitLab is the heaven on earth GitHub isn't. It just has it's own, different issues.
Hi - I'm sorry for the experience you had. I'm the PM for our Runner team, and we're focusing our next milestone purely on fixing some high priority outstanding bugs, that have been open for longer than they should have.
Is this the issue you are referring to about the cache issues? https://gitlab.com/gitlab-org/gitlab/issues/21409 If so, it seems like it got lost in our triage system, I've set appropriate labels so now it should get the appropriate visibility.
The one your referencing is related or the same issue. The very first mention of the problem I found with my initial search probably a year ago was the following issue from 2016, which is the one I'm watching:
> There are so many things that can make life easier for users (better configurability for CODEOWNERS notification?)
Can you please elaborate on this? What type of configurability are you looking for? What other things do you think would make life easier for users? Please feel free to email me!
Hi! GitLab employee here. While someone else from the community provides the feedback, I'd like to highlight what our support team can provide.
> GitLab offers a variety of support options for all customers and users on both paid and free tiers. You should be able to find help using the resources linked below, regardless of how you use GitLab.
I am sorry if it sounds like that, as my intention was just to provide some more data while waiting for the real case feedback. Hopefully, some users will provide their personal experiences.
Hi! I'm on Djorde's team, just in case anyone stumbles across this and thinks you're literally talking to a bot (not saying you are OP, just preventative), he is a non-native English speaker but definitely a real person. You're talking to this guy :) https://about.gitlab.com/company/team/#sumenkovic
I think the point they were making (in a mean way) is that it sounded like robotic PR speak, the thing any PR person would say. The support page doesn't say much about the quality of support, so the message was received poorly.
Sometimes the very friendly PR tone is considered out of place and obviously forced. Especially on a developer forum.
[PR for devs must be so much "fun" - you have my sympathies]
Hi, yeah I figured that was the point they were making, I kinda wanted to provide the info (in a round-about way lol) that he specifically is a non-native English speaker, so that's why it comes off as a bit forced-friendly and PR-ish. I do appreciate this feedback from both of you, I will mentor them a bit better about this!
I was hoping for a bot actually. I’m a decent user of GitLab (and GH) and really find the insight from employees commenting on HN helpful in understanding the product roadmap and philosophy of the company.
I was pleasantly amused at the possibility of GL having a chatbot loose on HN but figured you were just a person trying to be helpful.
Comically, your response still could be generated, but I trust you enough that you don’t have to post additional proof you are human. Spend that resource on accurately counting the pets in the office.
It's awesome that you're willing to help out, but increasingly these kind of interactions leave me with a bad impression -- I don't want to have to complain in a public forum to get some kind of meaningful response.
Not calling you out on this personally, just noting a general trend that's become really common the last few years.
There are actually quite a few complaints on here about GitHub support, the difference is that Gitlab employees are replying to the complaints against their company. Seems like a lot of Gitlab employees follow Hacker News and want to help out.
(It appears that Gitlab actually pays some of them to do this as part of their job, whereas for others it is not in their job description).
Hi yes! Someone who gets paid to do this here :P just wanted to give some background on my team (not that you asked for it OP, I just like to talk about myself apparently).
But yeah my team (of 3 members lol) was spun up primarily because Sid our CEO wants to make sure that everyone in the company is plugged into what users are saying about us, and he cares about hackernews specifically since GitLab was founded here [1]. So my team mainly just triages mentions about us so devs/managers/etc don't miss feedback but can still focus on their jobs. I do see first-hand that everyone in the company really does care about what people are experiencing.
I really appreciate / admire the care you all have for devs by being a part of the conversation on HN. Support is _hard work_. I am a dev at a similar startup (Sourcegraph) and always try to take a page out of your book by being responsive and caring online in a similar manner.
Ah sorry to hear that was your take-away, I'm not on support it's just my job to triage feedback [1]. We do have a Slack channel for support managers where I passed along your experience though, so hopefully we can improve!
Thanks for responding! It's one of those things for me that is positive in individual cases, ie your response here, but negative in aggregate. So, no worries!
Well I'm glad to hear this was positive for you at least! Our support managers are very receptive of feedback (and I know they're watching this thread too, hi friends), so I do really appreciate your constructive criticism. Hopefully we can improve on this, no one wants to be a pain-point :P
I don't know of anyone who uses Gitlab. We use Github at work, and I know several people who use Github at work. In terms of features, I can't think of anything that Github doesn't support. If something is missing, you can always find tools/services that integrate with Github.
That said, I am quite surprized that Gitlab is growing so fast. I would be curious to know what is the source of most of their revenue. Are they targeting a specific cohort of users, which Github is not able to?
That's the problem with these monocultures. People just assume that "well, everyone uses it, so it must be the best/have all the features".
As for what Gitlab has that Gitlab doesn't:
* Built-in CI/CD that's actually pretty decent (easy to configure, you can restart subtasks, you can use your own runners)
* An issue tracker that supports estimates & time tracking. There are "solutions" for github that work with external services, but they cost money, and have strange workflows.
* The ability to self-host without huge piles of money.
* A lot of features that I'm not currently interested in, but others would be, like k8s and serverless support.
One feature that probably doesn't get enough praise is the groups. You can create groups, and nested sub groups within. This helps us a lot to separate projects into smaller groups. Sub groups inherit access and keys from their parent and ancestors.
They seem to have achieved golden child status on HN, and from my experiences its hard to see why. Glad there's a non-Microsoft option, but I wish it were another whole setup.
Support is non-existent, clunky CI infrastructure, barebones all over. They seem to just be good at reacting in public threads.
The excitement for gitlab on HN has always been a combination of “open source enthusiasm” and astroturfing. From personal experience, HN is filled with tire-kickers who will hug the crap out of any halfway-usable product that they can “migrate to” for free (and abandon said product as soon as a payment form appears). It’s a misleading signal.
Even on this thread, you can count on one hand the number of commenters who actually say they pay to use the product. The trick is to use that noise to leverage yourself into markets where people actually pay money for things.
Someone should make a website of failed technologies and companies HN positively adored complete with gushing comment quotes about how awesome and disruptive said thing will be.
The breakdown is probably close to the percentage of paying versus open source customers that we have.
We are working to better educate our users on the value that our paid version can offer, but it is very important for us to be good stewards of the open source community that has grown around the project. You can read more about our pricing strategy and stewardship here: https://about.gitlab.com/company/stewardship/#what-features-...
Sorry if you find this spammy! It's huge news for us and we all (of course lol) have a vested interest in making sure the company succeeds. Since we don't have Microsoft funding to enable us to throw resources at everything in our backlog, we rely heavily on user experience to help us prioritize. Which just so happens to come up much more organically on sites where devs are more empowered to voice their opinions freely :)
Nonsense. You have hundreds of employees and a multi-billion dollar valuation, and you keep making the same excuses.
I have been watching you folks spam threads, over and over again, for years, with the same things: “we’re fixing performance!”, “making the UI better is a priority!”
The user complaints never change.
Instead of spamming threads with guerilla marketing, make your software better. What was cute when the company was four guys and a computer now just appears calculated and manipulative.
You are eligible to apply for the program if you have accepted an offer at GitLab as a:
Director or up, Distinguished engineer or up, or Senior product manager or up.
Manager or Staff engineer, if there is 1 consideration.
Individual Contributor, if there are 2 considerations.
I was thinking more like olden times where you work your way up from the delivery boy spot or something and this was a chance to do it. Maybe I misunderstood?
We are nowhere near as valuable or successful as Gitlab but we also practice radical transparency, which means that all of our material conversations happen out in the open. This saves a lot of time and makes it much easier to stay on top of what is happening. Because many of our co-workers are remote we publish a once-per-month update that goes into substantial detail about the state of the business.
I'm a firm believe that companies should be run like that but many other founders like to play their cards much closer to their chests.
I am a huge fan of gitlab. We are in the process of moving our github org over. We love!! the gitlab ci tools. We use them extensively for mobile cicd. The gitlab ci runner is super easy to get running and coordinates well with a host and vm setup. We run it on a mac min sitting on my desk and have never had any issues with it.
My only nitpick is the regex matching they do to mask protected environment variables from ci logs is not sufficient. It won't match + scrub aws secret keys in the logs, which seems like a pretty glaring problem in a cicd setup.
> masked so they are hidden in job logs, though they must match certain regexp requirements to do so
We've been able to work around it, but it did make that particular automation more difficult.
Hey, CI/CD PM here. I'd love to learn more about how you're using GitLab for mobile, if you're up for it ping me at @jlenny on gitlab.com. It's an area of focus for us, and it's always great to get to know another person who is using that use case.
We use it with Fastlane to automate our entire build and delivery pipeline. We set it up for our mobile clients, too, and it saves us a lot of time getting code shipped quickly.
We have a Mojave VM configured with Xcode, Fastlane, and the gitlab runner.
We automate uploads to Appetize.io for every feature branch so that QA and clients can test out new features in a simulator running in the browser.
We automate builds and uploads to Apple test flight and Google playstore alpha tracks on our develop branch.
The gitlab runner is by far the most reliable and easiest to setup part of the whole deal with the worst being maybe cocoapods or npm for the projects that rely on them (react-native).
I'll ping you on gitlab. Happy to go into more detail!
We've recently run into an issue with building react-native on Gitlab-CI, where apparently the build process spins up a file watcher in the background which quickly exhausts the open file descriptors.
Have you experienced anything like this? We are using stock react-native and not customizing anything.
Haven't had this issue, no. Are you running into the same problem if you build the app without the runner? The file watcher (do you mean metro?) shouldn't be running during a production build since the files aren't changing, right?
At my last job Gitlab was in the stack and I had never used it before so I was expecting it to be a real pain. It was actually a perfectly pleasant experience. I don't think it'll make me leave Github but I put them at the same level now.
Merge Requests never felt right saying over Pull Requests, even though it's more descriptive of what's actually happening.
I'm being pedantic here, but the reason I prefer pull is because it feels more general than a "merge," which to me precludes a fetch/rebase. I guess you could consider it a merge -ff-only, but in a mergeless-master workflow, "merge request" felt awkward.
As I understand they won't give up 'Merge Request'. But couldn't they at least make it configurable? 'Pull Request' was first and, as I suppose, is the preferred terminology by many.
I am curious how the Gitlab is so valuable. I've never used the service, but HN posts keep me informed superficially. Could someone explain the valuation?
They've positioned themselves as an all-in-one package for every tool you'd need to implement a devops software development workflow - source control, continuous integration/deployment, etc. Existing enterprises pay different vendors to implement all of these things; new and growing companies (in theory) just need to buy a GitLab license.
Because Microsoft paid for GitHub -- since GitLab is well positioned to compete with GitHub, cash rich companies like Apple or Google could be interested purely to keep up the Jones's.
Not a dig at you because I understand that you're using Apple simply as an example of a big company, but Apple hypothetically buying GitLab sounds soo ridiculous.
Thanks. Do you have any insight into MSFT's strategy for GitHub? I assume it helps make it seem developer friendly, data-mining, identifying projects/new ideas of value and validation, and is part of their becoming more of a cloud company strategy.
> Do you have any insight into MSFT's strategy for GitHub?
Developers, developers, developers.
They are deeply integrating GitHub into Azure and Tfs, and integrating that with Visual Studio, creating a top-notch devops platform for you to develop for Windows or Azure.
And now with their move into Linux, they are creating an image just like the old Borland.
> Do you have any insight into MSFT's strategy for GitHub?
Between LinkedIn and GitHub they probably have the best data for identifying great devs/engineers as well as encouraging future devs to use their products. Soft power.
This is very interesting, as means of finding talent before its larger competitors do. The discussion about how Google has a “deep bench” to deal with shifting and departures seems to apply here conceptually.
GitHub should help azure compete with amazon's aws offerings as well as Google's. GitHub is also where MS hosts many of their open source projects so brining that "in house" was probably a large part of the acquisition strategy.
How GitLab can have this kind of high evaluation is beyond me when they sale only one part of what Atlassian( bitbucket) offers.
GitLab is far more than just source control like Github or Bitbucket. Servicing the entire software pipeline from planning to delivery has been their entire mission.
Yeah, but if Github goes down the developer world basically comes to a standstill, while if Gitlab goes down, most developers will only read about this on hacker news.
Wouldn't that put them at 40% of github's value. Giving that github's brand is more valuable this is pie-in-the-sky vc math. Ready to be ipoed and written down to a 1/10 of the value in 2 years.
I think both valuations are too high but there it is. Enterprise is hot right now and some people are anti-MS. Also, Gitlab allows on prem which is a huge issue for some orgs. Also, it seems that Gitlab's all remote teams have a much lower cost structure and will allow for easier profitability. I guess we'll see.
> I am curious how the Gitlab is so valuable. I've never used the service, but HN posts keep me informed superficially. Could someone explain the valuation?
FOMO from the VCs. It will implode.
The only company that could potentially be the one to pay the money already bought the valedictorian of the class.
The ones that are left are Google, Apple and Amazon. Google does not buy those kind of companies. Apple is not in that business and Amazon is... well... Amazon.
Related question. Is it possible to use Gitlab CI with a runner running on your own hardware to get unlimited CI time? I'd like to take a machine at my home and use it to run automated tests/etc, especially because some of the integration tests can be quite long (ie, chewing up CI minutes).
I thought this was possible, but after searching I was often confused. I imagine I'm using poor terms during my search. Thoughts?
Yes - if you bring your own runner to GitLab.com you can run unlimited build minutes on it - the build minutes we count are only those on our shared compute (2000 minutes for free, etc.).
The other huge benefit is that you can put that runner behind your firewall without poking any holes - itbjust needs access to GitLab.com and it can run your builds.
Yep, we do this on GitLab.com - it’s one of the most well thought through systems I’ve worked with tbh. We use autoscaling EC2 spot instances for almost everything, incredibly cost efficient and unlimited.
Just curious how this works out for you? When I tried this, even when the spot bid was way above current price, it would often be stuck in a pending state since spot instances don't get created immediately. Do you get spot instances to be created immediately on demand somehow?
Yep we see spot instances immediately created - there's no noticeable delay (compared to build times) against having permanent EC2 instances running. For our runners we want to use spot instances, the important part of the gitlab-runner register command are:
That last one means our bid defaults to the current on-demand price, which seems to get fulfilled immediately. FWIW we're using m4.large instances in eu-west-1a and according to the AWS UI the spot price has been perfectly consistent (at about 1/3 of on-demand) for at least the last 3 months so maybe that consistency is why it works so well for us.
Thanks, I'll try this out! Has it ever happened that it doesn't get created immediately for whatever reason? And if that happens, will it automatically cancel the request and/or pipeline within X minutes, so that it doesn't randomly get fulfilled like a month later?
It absolutely is. That's what we do at company I work for. We use free gitlab mintues and when it runs out we use runner running on one of our own local machines.
While my org uses perforce extensively; we also have a gitlab premium license (with far too many seats than we have users due to a fuck-up deploying mattermost org wide then promptly disbanding the effort after the damage was done) which we use enjoyably.
Despite the fact the people who host our gitlab internal do not update it often or support it well I do think it’s a great product at the enterprise level.
So much so that I host one myself for my IRC community to use!
Microsoft came and gave us teams “for free”. And since we’d tied mattermost to gitlab, every mattermost user (non-developer) was (is) costing us money. :/
I just want to address 'valuation' quickly for people who may not be familiar with how this is made up.
Lets say I have a peanut cart, and in my sack I have 10,000 peanuts. Some sucker comes along and invests in the peanut cart, and I sell him 1 peanut's worth of the cart for $1.00. By the usual rules of 'valuation', the valuation of my sack of peanuts is now $10,000.00.
Valuation just means what someone somewhere estimates the value to be, it doesn't have to be credible. It becomes more significant when investments are made, since if an investor puts in money at a valuation of X, they are betting that the company will find liquidity at some point in the future with a valuation greater than X, or the investor will lose money (even this is not true, since they will likely have liquidation preference or other backstops to protect themselves at the expense of founders and employees).
The short version is, valuation is not what the company is actually worth, or even an impartial estimate or appraisal. It is purely the amount invested divided by the fraction of the company that investment purchased (even if the fraction is small), and it ignores things like liquidation preference that let investors hedge risk when they invest money at valuations that make no sense.
Yes. All of that said, if you're an insider with equity you'll have access to a 409A valuation, which does take all of that into account when coming up with the number. It's closer to what the market will pay for common stock in a theoretical IPO at the time of valuation. It's definitely not in any way what the market will actually pay in a real IPO.
Silly question: What are "CI pipeline minutes"? I read their FAQ which just says it's minutes used on their "runners", which only changes the question to "What are runners, and where do they fit in?"
I figured out CI means Continuous Integration, which is something I don't use, nor want to. I'm mainly just interested to know if this comes in to play if I just want to use GitLab to publicly share code like on Github.
I assume, not an expert here, that GitLab’s runners spin up when you make a push that triggers a build.
I’ve set up my own pipeline with Jenkins, Docker Registry, and Gitea and when I push a change to Gitea, a hook is called in Jenkins which starts executing relatively simple bash scripts for building images, pushing them into the Docker Registry, fetching them on my server, and restarting them.
Runners are almost certainly the equivalent of Jenkins here. A hook is called, and Gitlab’s runner starts executing some script to build images and assets, and deploys them for you.
If you add in tests things can probably get pricey.
But I bet you can have multiple runners building different parts of your system in parallel which is why their by the minute charging scheme makes sense (as opposed to number of runners required per build or something).
And it seems fair to charge you a combined total of ten minutes of processing time for two parallel runners, one of which started at the 0th second and ran for one minute and one which started and ran for 9 minutes.
If you don’t use it now, it can be a lot of initial work to set up, but watching your CI/CD pipeline chug along and deploy your work can be really really satisfying.
Was definitely overkill for my personal home page but really enjoyable to build and have it come together.
The runner is the piece of software that executes pipelines. You can install it on any machine and connect that to a gitlab instance. On hosted gitlab, they provide the runners, but limit how long you can these runners execute, which they measure in minutes.
Just an assumption, but maybe the time each stage/step takes? Maybe there are improvements that can be made to Gitlab to speed them up, or something to that affect. (I don't know the specifics so this is completely a guess)
For anything I'd put on Git*b, it's largely unnecessary, as they'd just be tiny pet projects that only I would ever update. I'm surprised when I even get someone looking at my repos, let alone contributing to them.
Is it related to Atlassian’s huge price increase (40% to 320%) for Server licenses? They try to push everyone to the cloud, almost by force. It made the stock (NASDAQ:TEAM) lose about 16% in 20 days.
kind of wish they had kept it a little more lightweight. been running v7.10.5 as a personal repo on a small-ish sized vps. went to upgrade/migrate to a newer version the other day and the recent versions crash out on the same host configuration. i eventually got it up and running but it was sluggish and nearly unusable.
sticking with v7.10.5 for now but i will probably switch to gogs or something similar soon.
Hi - thanks for the feedback, we aren't where we want to be with performance. We are working hard to improve responsiveness and memory consumption, and have a recently started a team focused on just these aspects to accelerate the improvements. You can read more about the rationale here, including stories like yours: https://about.gitlab.com/2019/09/13/why-we-created-the-gitla...
Thanks for the feedback. We are working hard to improve performance and memory consumption of GitLab. We have two major projects underway, switching to Puma [1] as well as reducing the overall memory consumption of GitLab [2].
You can follow along on some of the progress we are making in each release post in the "Performance Improvements" section. For 12.2 you can see we had 58 MR's related to performance.
Hello! We haven't been at the capacity employee-wise to have teams dedicated to improve much in these areas, but we tripled our employee count this year and have since spun up a memory team [1] and are able to dedicate more people to performance [2]. So hopefully we won't be saying this for much longer!
I'm spinning up a new architecture for my homelab and personal stuff and that slowness is why I'm installing Gitea for repos and Drone for CI/CD. The combo seems to give me everything I want without taking a huge share of my limited server space.
Congrats, GitLab team. Way to build an impressive business.
When anybody tells you there are rules to venture capital — like it’s impossible to take on massive incumbents that have network effects — ignore them. The GitLab team is doing something phenomenal here.
Thank you! GitHub is unchallenged in open source but it turns out you can change all the people in one company to a new tool without much of a problem, especially if you can replace 10 other tools.
We switched to Zulip because of a bad experience with Slack holding our message history hostage. At the same time we switched to GitLab because we didn't want a similar issue to arise with our issue tracker.
It was non-trivial to get the issues out of GitHub, and we lost metadata in the process. But now we're on a platform that has an "Export Everything" button, and in the worst case we can self-host our own data.
Although that's why we moved, and we didn't know about it at the time, "Service Desk" became a killer feature. That lets users file issues directly into our GitLab issue tracker by sending an email -- no account setup necessary. The majority of our users are non-technical and this has made it much easier for them to communicate with us.
- Pricing structure made much more sense than Github's at the time. I would've been willing to pay for Github, but their pricing for private repos (now unlimited on the free plan) scaled steeply for any reasonable number.
- In addition to private repos, their free plan still offers many features that Github's free plan lacks, and their paid plans have many more features again than Github (Github focuses on polish, while Gitlab bundles the kitchen sink). While they may lack polish, some of these features are genuinely useful. Particularly around CI. Github's Actions API is an embarassingly recent addition.
- Gitlab Sites: their answer to Github Sites is an underadvertised and wickedly powerful feature. Github Sites really pales in comparison.
Reasons for staying:
- Responsive / active / communicative support team. Getting talking to Gitlab staff is incredibly easy.
- Proactively/playfully innovative culture, evident on tickets and MRs throughout their projects. I also really liked their approach to GithubLab: https://hub.gitlab.com/
- Transparent process. Finding out what's cooking in Github is frustratingly impossible, and why Github holds off supporting seemingly obvious things for eternity is just odd.
- The warm fuzzy feeling of storing my code on an open-source stack.
Reasons for wanting to leave:
- Stability and site performance have always been and continue to be abysmal. This seems to be a result of a reasonably good team being lost in a sea of complexity in a platform on which new features are prioritised over a simplified architecture. They do seem to spend a lot of time working on polish and performance, but never actually managing to achieve either of these things.
I was going to comment, but this sums up my thoughts as well. Agreed on pretty much every front, including the stability/performance concerns.
I will add that, while this is subjective, I also think that Gitlab has a nicer interface and is better organized. On top of everything parent mentions, there's a lot of subtle stuff like this that makes me stay.
Note: I haven't yet looked into Github Actions in depth, so if there's GH Pages integration there, some of the below may no longer be true.
Github's is tightly coupled to Jekyll, and—more specifically—to this single Gem https://github.com/github/pages-gem Also, this might have changed, but last time I interacted with it, it lacked any real control over your source repo structure: there's some arcane rules about either giving it a certain name under a certain GH org, or using a specifically named branch (`gh-pages`).
Github were also pretty lax about adding HTTPS support to custom domains their Pages service.
In comparison, GL pages allows:
- using any SSG[0]
- writing your own custom SSG (even integrated/including in your repo itself)
- automatic LetsEncrypt renewal for custom domains
- out-of-repo secrets management for any tasks within your SSG build/deploy steps
Thanks for the response! Reading through their docs it looks really nicely integrated with all the CI stuff there, a good example of them taking advantage of all the flexibility and power that has. Nice!
Same here, though I can’t say I’ve seen the same issues with performance as others. Maybe because I’m not reading through several thousand line files, but loading the site and files is pretty snappy over here. It’s not like a static site, but I’m never twiddling my thumbs. The GitLab site itself is a bit slow, but self hosted never seen wait times.
We use GitLab because you can self-host it. GitHub is not an option for us, because we must maintain control of our data and source code. So GitHub was never really an option.
But we'd likely be using GitLab even if we didn't have this limitation. There's a bunch of features that make GitLab better for our specific team / situation. From my personal experience, GitLab CI is better than CI options available on GitHub. We use gitflow (ie. feature branches in the same repo), rather than pull requests. And it seems like GitLab supports this flow well.
I also tend to like GitLab issues much better than GitHub. The time tracking feature in EE is really useful (not sure if GitHub uses this). And issue boards across projects is also a very popular thing where I'm at, because we have lots of repos, rather than fewer big ones.
We also heavily use the deployment / environment features and built-in prometheus.
So you (like 95% of the commenters here) prefer Gitlab be cause it’s cheap.
Bodes well for the business model. Commodity pricing only works when the market gets bigger as the price goes down. Otherwise, it’s just a race to the bottom.
I want to say it's the freedom to self-host, but really it's the CI.
Throwing a .gitlab-ci.yml file into my repo is by far the easiest way to get CI/CD incorporated into a product. The configuration of test runners (or lack thereof) is both a breeze and extremely powerful.
I'm not even talking about the auto-devops thing that I haven't tried; writing your own gitlab-ci file worked in frictionless ways that CircleCI, Travis, and (especially) Jenkins didn't.
PM for CI/CD here, thanks so much for your feedback! As much as I'm excited about how much you love the product, we can always do better and I'd love to hear your thoughts. Ping me any time (@jlenny) on any issues that are important to you that would make things better.
Agreed. The big thing is that when I'm starting a Node project, Gitlab's CI setup is like 5 lines in a text file and takes me literally about 30 seconds to set up. It's stupidly easy.
This has been a huge influence in me doing more automatic testing on personal projects and using merge-based workflows more often.
A neat hidden feature (AFAIK, maybe it's buried in documentation) is that if you branch locally and name it [issue number]-branch-name, pushing that branch and opening an MR from it will automatically tie it to [issue number] for the same workflow.
Handy for those situations where you started writing code before opening an MR.
I love that you highlighted this! This is basically a mandatory part of the data team's workflow. Once the MR is open we then spin up a clone of our data warehouse tied to that git branch where all the CI jobs run. I like that it will automatically close the issue too once the MR is merged.
Agree. This is indeed a nice tidy workflow. I usually just create a bunch of issues to have a visual representation of what is missing in a project, sort them in a board and then work through them.
Issues are good place for asking input and feedback, and also help in keeping feature branches focused and short lived. Definitely my favorite git workflow.
I'm not currently using Gitlab anymore, but in the past, it was their CI that won me over. I was always felt left wanting more though because there wasn't a true sense of community/explore.
If there's one thing I value most about Github today it's the ability to easily discover new projects and human beings; and Github helps tremendously with that whereas Gitlab I feel like you end up fighting the system to discover new and interesting things and people.
Heh, in a way. But I do give a lot of credit to Github for exposing me to some really cool and interesting projects. It does a decent job of knowing what I consider relevant, and surfacing projects/humans that fit the bill.
Our devops team loves Gitlab pipelines and pushed the decision through. If you're looking for a "killer feature" on Gitlab, pipelines is probably it.
As a developer I don't think there's a huge difference, especially since we don't use the issue tracking or wiki stuff (we're all in Jira/Confluence). My main complaint about Gitlab is that there are a lot of places where the UI is rough around the edges (lots of pages lack or have very minimal search/sort options) or has outright bad UX, as well as lacking some features that feel pretty basic to me.
My main complaints about Gitlab at the moment:
* Lack of search/sort, as mentioned above
* We created teams in Gitlab to mirror our scrum teams... when you look at the team list in Gitlab, it shows everyone who has access to the team, which is our whole damned Gitlab account. The only way to find the actual team members is to scroll down the list looking for users with a delete icon by their name (which removes them from the team).
* If you want to set a required number of approvals on merge requests, you also have to set the list of reviewers. I wanted to set two required approvers but let the devs assign who (normally their team)... no can do.
* Poor support for making merge requests build the result the merge (instead of just the branch). We've tried setting it up a couple of times, but usually end up with MR's hung because Gitlab doesn't firing the right builds and end up having to turn it off.
* If you have the server squash commits when closing a MR there's no way to set the commit message in advance; you have to type in the message just before you click the merge button. This wouldn't be an issue if it defaulted to using the MR description as the commit message, but it doesn't do that either...
You don't have to provide a custom squash message, and the default behavior will be either (a) taken from the first multi-line commit message in the merge, or (b) the merge request’s title if no multi-line commit message is found.
Re squash commits: as a MR author what I want is the ability to set the commit message in advance (even if it's just a check box to say "use the MR title and description". Using a commit message is a sane default behavior, but not extremely helpful most of the time (IMO). If I'm going to rely on it for the message in my squashed commit I'm going to have to remember to check my branch history, and most of the time I'll probably have to do an interactive rebase to clean things up and ensure Gitlab grabs the correct commit message. It also negates the value of "squash on the server" - if I need to do an interactive rebase anyway, it only requires about 30 seconds extra to just do the squash myself.
Ahh gotcha, you seem to have pretty much the same feedback as this comment: https://gitlab.com/gitlab-org/gitlab-foss/issues/47149#note_.... Commenting on this issue (and tagging @ntepluhina, one of the owners of the issue) with your feedback would be the best way for someone to see it! I can pass on the info too, but issue comments take precedence when we're prioritizing.
Basically, corporate people are allergic to paid managed services and are afraid of proprietary lock-ins (unless a VP heard it was what all the other VPs were doing). If the open source software has support contracts, and is cheaper, they leap on it. We're actually moving off GitLab onto Github, because it's just... better. Not only because managing it internally sucks, but also Github is just more polished. Still won't pay for GitHub Enterprise though, because we're cheap.
Can self-host behind an enterprise firewall and get all the benefits of open-source software model within the company without exposing proprietary software projects to the whole world.
True but being able to test it a bit on a small team is a big help. Migration from CE to EE is relatively easy and demonstrating CE to management helps a lot.
I'll admit that I mostly switched because of the MS buyout of Github.
The issue wasn't specifically because I have any particular issues with MS, but more due to the fact that Github can be bought. I felt like the epicenter of open-source software should be built on something open-source, especially when that open-source thing has nearly 1-to-1 feature parity.
I know Gitlab has a fair amount of proprietary stuff, but at least I can build my own Gitlab server for free on my own hardware if I decide that I really hate their free hosting.
My employer uses gitlab for most internal projects because of ITAR and other legal restrictions (aerospace). No external hosted services allowed, except obviously for released open source code.
If it's open source then necessarily it's been approved by export control. Anything open-sourced obviously can't contain ballistic information which would violate ITAR. But by default, all internal software and documents/documentation related to spacecraft/aircraft are assumed to be sensitive until they've gone through the export control process.
At work: our campus has a local instance running, likely for code security issues, and so it integrates with our login service. Integrates nicely with JIRA and TeamCity as well.
Personally: I leverage both GitHub and GitLab. GitHub has the greater community, but GitLab Pages is far easier to use. So my workflow process is to have GitLab mirror GitHub repos.
Free private repos was a feature of GitLab, but once GitHub implemented that it just resulted in me dropping the paid tier I was on.
So I guess GitLab Pages is the feature I use it for the most.
Built in CI that you can run on your own servers trivially, free (private) docker image repo, great support for "teams", even free ones, which allows me to offer my CI boxes to my friends for their side projects.
I've had a few vague uptime issues whenever they get a big spike in popularity, but otherwise no complaints.
After using it, it just had a better vibe. Features seem similar enough for me, but it seems like Gitlab just lined up with what I want more than Github.
An example of this is the default page when I log in. On Github I'm given my activity feed -- which 90% of the time is absolute noise. Gitlab presents me with a list of repos, which is typically what I want.
Possibly SEC rules and/or advice from lawyers to only say anything when needed - they are at or getting to a critical point in the journey. The PR/support staff can run the comments for now.
Well maybe they will either backport or accept community implementation of merge request approval functionality now [1]. With all kudos to the GitLab team, absence of this feature while all other major players free tiers have it is quite a nonsense.
Anyway, GitLab is really solid platform with pleasant OOBE. Always recommend it to anyone.
Confirming I have used GitLab across 10 different domains/entities/projects & have had zero issues. IMO... both GH + GL are here to stay. Here's how I evaluate how to use for each one.
=> GitHub = OSS street cred. [You might want to get hired or want to showcase your skills]
=> GitLab = Business/Enterprise related. [You might want to earn $/make a living... you know.. following your countries' compliancy]
FWIW...My two cents...Both great products, however, different use cases.
Totally agree with this, I think a lot of it stems from Github getting open source code in early and Gitlab having free private repos. I use Gitlab because of that. All of the open source work I did is done through Github.
Ultimately, I'm glad they both exist, my go to is Gitlab though. And I'll be looking closely at their IPO to be an investor.
its annualized revenue is growing at a rate of 143% year-to-year, with net retention of customer spending at 153%.
Net dollar retention is the metric anyone judging a SAAS business should be looking at. 153% is nearly the best I've ever seen - Twilio was 155%, Slack 140% at IPO[1], Sendgrid 115%, Mulesoft 117%[2]
Honest question from someone that knows nothing about valuations, does this seem kind of ridiculous? Aside from investors basically making this stuff up, is there any actual validity to a billion dollar valuation anymore? What would I look at (aside from %s) that would show me, someone that knows nothing about finance, that this company is this valuable? What is their actual revenue? I’m mostly curious to see how reality stacks up against hope and what the actual financial outcome of this would be outside of seeming like these companies are being dumped on the market for a big payout.
I honestly hate gitlab compared to github. So many broken features and half implemented things. It's got all the same problems Jira has (as compared to GitHub which is amazing to use).
Hi, GitLab employee here. Sorry to hear that! This funding should enable us to throw more resources at maturing some of our features (e.g. we tripled our employee count this year). We spun up this product maturity page to make this a little more transparent: https://about.gitlab.com/direction/maturity/
Can you please fix in-line commenting? I should be able to click and drag several lines and leave a comment on those several lines specifically. This is something everything from reviewboard to github have had for ages but gitlab still doesn't have. Additionally, gitlab defaults to lots of files not showing their contents in the diff which is extremely frustrating as I need to go click several times to enable the diff.
Gitlab is great! Most major downside from my perspective is that the diffing functionality is much worse than Github's. Super slow + resource intensive.
Please give gitlab some more money so they can enhance development. My experience with gitlab has not been the best. https://news.ycombinator.com/item?id=20923559 But congrats to the team too. It's good to see another startup succeeding for delivering real value.
How does this even work? Like, does one plainly submit a form to the govt saying "yeah just double it" or what? I never actually got the hang of how this things are defined; can anyone ELI5?
It occurs as part of a fundraising process in which an investor invests money at a valuation that's double the previous one. As part of that there are forms filed that effectively say: "yeah just double it" but you don't file this forms outside of a fundraising process.
I am a huge fan of gitlab. We are in the process of moving our github org over. We love!! the gitlab ci tools. We use them extensively for mobile cicd. The gitlab ci runner is super easy to get running and coordinates well with a host and vm setup. We run it on a mac min sitting on my desk and have never had any issues with it.
My only nitpick is the regex matching they do to mask protected environment variables from ci logs is not sufficient. It won't match + scrub aws secret keys in the logs, which seems like a pretty glaring problem in a cicd setup.
I mean, with GitHub's price being 7.5 billion, it's not outrageous as one of their leading competitors. I also was feeling like a Google acquisition wasn't impossible, they did move their entire platform to Google Cloud recently.
Microsoft and Google seem on pretty good terms lately, but right now, a lot of Google's public projects are posted on a Microsoft code hosting platform. I could see a day where Google says they need their own, buys GitLab, and moves over everything.
I'd love for Gitlab to stay independent. Of course that is risky and who am I to deny the founders a billion dollar windfall but I feel that such critical resources should not be acquired by the likes of Google, Amazon or Microsoft who already have much more power than they should have.
Hi! GitLab employee, our plan is to go public by 2020 [1][2]. I trust Sid our CEO to stay transparent about this (worked with him personally, this isn't just blind company loyalty lol), and he does a company-wide AMA very frequently where he talks about going public. So I think we will stay independent, or at least won't get acquired easily.
Hi Emily, I've been following the Gitlab saga from reasonably close by (I'm Dutch), if and when you go public you can count on me buying a substantial number of shares just to put my Euros where my mouth is. Best of luck to all of you.
Google Code wasn't modern/competitive, seemingly had nobody working on it internally, didn't have a business model of any kind, etc.
Why launch a new messaging service after shuttering... like ten of them? Just because a company shuts down a product doesn't mean they'll never want to have a product in that category again. Especially a company known for regularly having multiple overlapping products.
Oh it'll get acquired eventually, the question is when, and at what price, and by whom? How valuable is a Github competitor if nobody's leaving Github to use it? I don't see Google being interested; they know it won't make any money but from corporate users, and corporate users don't take Google Cloud seriously. Someone like Atlassian might be interested if they didn't already have 5 CI/CD solutions.
What got us initially was the free private repos before github had that.
We are now a paying customer.
Their integrated CICD is amazing. It works perfectly for all our needs and integrates really easily with AWS and GCP.
Also their customer service is really damn good. If I ever have an issue, it’s dealt with so fast and with so much detail. Honestly one of the best customer service I’ve experienced.
Their product is feature rich, priced right and is easy.
I’m amazed at how the operate. Kudos to the team