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
It is much better now, good job.
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...
You can purchase directly from the customers portal at https://customers.gitlab.com and apply them to your group.
Hope that helps!
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.
Getting that to work with GitHub is more painful (pain mostly related to automated webhook-management)
I can't compare to GitLab right now ;-)
For CI/CD I quite like Appveyor and Octopus Deploy. But if you are penny pinching, they may not be super appealing, but they are incredibly powerful!
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.
Lest you think it's just me, compare https://news.ycombinator.com/from?site=github.com to https://news.ycombinator.com/from?site=gitlab.com .. the first is packed with projects posted here on a daily basis. The latter? 13 project links in about 50 days.
- https://salsa.debian.org/ (AFAIK this is an ongoing migration)
Others are considering a migration:
- KDE: https://gitlab.com/gitlab-org/gitlab/issues/24900
- GNU Emacs: https://gitlab.com/gitlab-org/gitlab/issues/28152
Maybe someday we'll have federation to work around this: https://gitlab.com/gitlab-org/gitlab/issues/30672 :-)
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.
But everything seems to be done on their Gerrit for now.
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.
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 .
Because of this, we do offer our API and the ability for our community to contribute integrations directly to the codebase. We have a pretty rich set today, you can see at: https://docs.gitlab.com/ee/user/project/integrations/project...
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.
PAT granularity has indeed been a pain point, and we should be solving this soon by offering the ability to restrict them by groups/projects: https://gitlab.com/groups/gitlab-org/-/epics/182
Gitlab has many strengths, but integrations is by far the weakest one.
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.
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.
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:)
Quite a few open-source projects rely heavily on being findable, and often use their Github README as a sort of "marketing site" for developers.
Finding projects organically on Gitlab is a nightmare.
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.
This of course won't benefit Gitlab's SEO in the long run, but it does allow using Gitlab with less of the cons.
The file name search is pretty rapid though.
There's also a dedicated Search team being built at the moment to focus just on this.
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.
I've resorted to using google search and append site:github.com to my query.
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.
This seemingly simple action does not work on Gitlab.
To answer your question, I do the above often on Github. Probably found projects that way as recently as last week.
 - https://about.gitlab.com/solutions/open-source/program/
 - https://gitlab.com/gitlab-com/marketing/community-relations/...
 - https://news.ycombinator.com/item?id=18724015
> 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.
GitHub is the standard so pretty much everyone has a GitHub account, companies ask for GitHub accounts on applications, it's the hub currently.
GitLab is the superior product in all regards, but GitHub has the network.
I could agree on features, but not UX. Github is still the king.
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.
 - https://about.gitlab.com/handbook/engineering/ux/experience-...
 - https://about.gitlab.com/handbook/engineering/ux/pajamas-des...
Other than that it's really great software. I wouldn't want to miss running Gitlab CI.
I didn't finish filling out those applications.
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.
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.
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.
That said, I still find GitHub's UI and UX more appealing.
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.
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?
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.
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.
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.
My experience with GitLab is simple awesome. Keep up the great work you guys!
> 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...
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 think this is a different problem. But not something your customers should have to care about.
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.
> Per their own policy all they do is finding relevant tickets and send you there, from there on you are not their problem anymore.
I believe you're referring to: https://about.gitlab.com/support/#we-dont-keep-tickets-open-...
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.
We do consider this an ongoing discussion, and have a long running issue where a number of customers have provided some feedback:
Please do feel free to join the discussion.
TLDR; support team is great for customers coming to Gitlab, but not so great once initial onboarding is done
I can strongly recommend against doing that, GitLab almost seems to punish you if you rely on CE, just to force you to pay.
It was honestly the bane of deployments.
And I agree. If that happened to me, I would move, without a doubt.
Ideally your service provider helps you through accidents. Both sides benefit from that.
> GitHub has lost its way
I've been a very early adopter, and I do not have the same impression at all today.
Working with something else than GitHub is painful for me (& I'm using a number of other hosts for various clients).
Not sure how you come to that conclusion. Even _if_ that were true, that would probably be a good thing now that TravisCI is on life support.
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.
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.
Just some examples. Wouldn't say GitLab is the heaven on earth GitHub isn't. It just has it's own, different issues.
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.
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!
> 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.
Please highlight why and how GitLab support team is better than X with some examples. I really want to learn about real cases.
I appreciate you’re trying to be helpful but don’t really have any useful info.
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]
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.
They won't keep me as a customer much longer.
Not calling you out on this personally, just noting a general trend that's become really common the last few years.
I don’t see it from competitors nor do I see the long string of terrible complaints, handle your business in advance this doesn’t have to happen.
(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).
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 . 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.
 (in case you care at all about my job description lol) https://about.gitlab.com/handbook/marketing/community-relati...
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?
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.
Those features may fade as GitLab gets bigger and gets more customers.
Also being responsive to users may bloat product eventually.
So it's not black and white situation.
When did the support started being bad? (I never used their support)
Support is non-existent, clunky CI infrastructure, barebones all over. They seem to just be good at reacting in public threads.
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.
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-...
On the revenue side, Sid publicly shared an update recently: https://twitter.com/sytses/status/1156571842653478913?s=21
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.
>> part of a shadow program in which employees spend two weeks sitting in on their CEO’s meetings, feedback sessions and media or analyst calls
Does anyone know of companies that do this "internship" / shadowing / mentoring built into the company?
The program is outlined in our handbook if you want to find out more info: https://about.gitlab.com/handbook/ceo/shadow/
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?
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.
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.
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.
Merge Requests never felt right saying over Pull Requests, even though it's more descriptive of what's actually happening.
That would mean Apple did something to positively invest in their developer ecosystem which would certainly be very unusual.
I hope that scenario does not unfold, for anyone involved.
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.
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.
How GitLab can have this kind of high evaluation is beyond me when they sale only one part of what Atlassian( bitbucket) offers.
From my experience working with that, it's very nice. But there is always the anti-Microsoft bias around, so GitLab may do well for that reason alone.
MSFT integrated sales channel. LinkedIn data + Github data is pretty much everyone who buys any "IT"/"software" services.
Not sure what you mean exactly.
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.
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.
Edit: see https://docs.gitlab.com/runner/executors/docker_machine.html
Buildkite is an excellent CI tool.
--executor docker+machine \
--machine-machine-driver amazonec2 \
--machine-machine-options "amazonec2-request-spot-instance=true \
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!
Glad it’s working out for them.
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.
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’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.
sticking with v7.10.5 for now but i will probably switch to gogs or something similar soon.
One of the major projects the team is working on, is to switch from unicorn to puma: https://docs.gitlab.com/omnibus/settings/puma.html
We are also continuing our broader effort at improving performance each release, for example in 12.2 we had 58 MR's focused on performance improvements: https://about.gitlab.com/2019/08/22/gitlab-12-2-released/#pe...
Hopefully you will start to feel the impact of these investments soon.
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.
 - https://docs.gitlab.com/omnibus/settings/puma.html
 - https://about.gitlab.com/handbook/engineering/development/en...
 - https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=...
Every. Single. Release. For. The. Past. Two. Years.
At some point it seems clear that despite statements to the contrary the speed of the instance, and the resource consumption just cannot be a concern.
I'd rather the core was speedy and resource-appropriate than see additional half-working features bolted on non-stop, while bug reports languish.
 (same link as #2 above) https://about.gitlab.com/handbook/engineering/development/en...
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.
Enjoy your success! You’ve earned it.
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 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.
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
- 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
Really, is this new? I wasn't aware of it.
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.
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.
It's better than paying for 10 individual tools that don't work well together.
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.
This has been a huge influence in me doing more automatic testing on personal projects and using merge-based workflows more often.
It creates a new branch, with a smart name like 123-my-issue-title, and a new "pull request" for that issue and branch.
Handy for those situations where you started writing code before opening an MR.
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.
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.
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...
> when you look at the team list in Gitlab, it shows everyone who has access to the team
This has been an ongoing issue for a while, but a fix is
currently scheduled for 12.4: https://gitlab.com/gitlab-org/gitlab-foss/issues/44958
> server squashing commits
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.
The original issue around this: https://gitlab.com/gitlab-org/gitlab-foss/issues/47149
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.
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.
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.
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.