641–650 of 716 posts
Isn't that 3 contributor limit just a virtual limit. Assume there are 5 contributors (A, B, C, D, E) for a project. The organization could do this: 1. Create two private copies of that repository 2. A, B, C contribute to the first repository 3. C, D, E contribute to the second repository. 4. C will maintain the synchronization 5. One could write scripts for performing synchronization.
Earlier quoted context omitted.
This is great news. I'm looking forward to seeing what you come up with. I'm not sure how relevant it is to you, but I hope you take some inspiration from https://platform.sh/ – it's the PaaS I've had the most luck with. While it isn't perfect, it's the closest thing I've found so far. Their "almost everything is in git" and instant environment cloning are fantastic features.
Thanks, the instant environment cloning looks nice. Does that also clone the database and redis?
While I think this is a great move, don't forget that private repos also means no more free Travis CI. Gitlab CI however offers 2,000 build minutes a month with their integrated CI service. Even if your whole set up takes 10 minutes to build on CI, that's 200 builds a month which is plenty for an individual project that's on a private repo. In other words, I think Gitlab's free private repos + CI is still a better ch…
I am a happy user of Gitlab for 3 years now, I have been using it for all of my private stuff and using it actively for around 10 projects at the moment, and I have seen the product change over time both visually and functionally. There are multiple things that I don't like about it, such as the way it handles registry images, but overall my experience for these 3 years has been terrific.
First and foremost, Gitlab CI is the best experience I have ever had, and I can compare it with Travis and Codeship; Gitlab is way ahead of every platform in terms of convenience and its free-tier limits. They have their own shared runners, which means you can run as many parallel jobs as there are runners available at the moment, so no concurrency limit there. They also allow you to run the free stuff for 2000 minutes per month, which is more then enough for most of the side projects. Also, you can use your own runners with the free tier as well, which means just pick a 5$ VM from DO, install the gitlab-runner using the package manager of the OS, such as apt or yum, and register its address on Gitlab UI. The whole runner stuff takes around 10-15 minutes to setup, and you are good to go. You can have as many runners as you like and you can run as many jobs as you like on them as well. There are also options to setup gitlab-runner in such way that it spans new VMs for jobs, which means you don't even need to have full-time runners, they can be created on demand. Also, CI is completely configured via a `.gitlab-ci.yml` file, which is version controlled and has a clear syntax, I have found it the easiest to use among the other options. It syncs with issues, merge requests and the project tree, which means you can reach to the corresponding pipeline from the MR; it also allows you to generate artifacts and store them for a certain amount of time available for download. Overall, I am a huge fan of Gitlab CI, I couldn't have imagined it would be this convenient to use the same product for Git-hosting and continuous integration, it is a real pleasure.
They also have their own Docker registry, which is pretty convenient to use with CI builds. I use it to push my images with commit hashes as tags to this registry from CI. Unfortunately, there is a lot of room for improvement for registry interface, currently it is pretty basic, meaning it only lists the image tags. If you are pushing the images per commit basis, you are gonna have a lot of images and cleaning up the repository is impossible from the interface, which is sad. I really hope they improve the registry integration. They also have some Kubernetes and monitoring integration which allows you to monitor your cluster and deployments from Gitlab interface directly, but I haven't used it yet, so no comments there.
Apart from the feature set, the most important reason I choose Gitlab over Github is clear communication they maintain. Downtimes happen, engineering teams can have bad times, but they are always open about these problems. They inform everyone from a Twitter account, they are responsive to everyone, and you can see them being very clear and direct about the problems they are having. I expect downtimes to happen, Git-hosting is not a crucial system for me that I cannot live with an hour of downtime, maybe it is because of the scale of the projects I am working with, but having an open conversation about issues like this is the actual value for me. As long as they keep this level of communication, I am fine with occasional downtimes. Not that they have downtimes all the time, but it is true that I have seen more downtimes on Gitlab than on Github.
Overall, the reason I'd not migrate my private projects to Github is not Gitlab having free private repositories, but their huge feature set and level of communication. I see Github as a giant corporation, and Gitlab as some guys like myself, I feel closer to them and I'll be their user & customer as longs as I feel that way. I have no association with Gitlab at all, I am just a happy user and I wanted to explain why I like Gitlab, I think a lot of people would choose Gitlab over Github if publicity is not a concern.
Earlier quoted context omitted.
When GitHub's financials got leaked in 2016, GitHub's personal accounts accounted for 12.5% of their revenue. GitHub Enterprise was 50%, their organization (= business) accounts were the remaining 37.5% [1]. It's fair to say that the personal accounts are irrelevant from a revenue perspective. [1] https://medium.com/@moritzplassnig/github-is-doing-much-bett... (disclaimer: I wrote the article but the data is by Bloom…
> It's fair to say that the personal accounts are irrelevant from a revenue perspective. Your assertion can only make sense if you also believe that a 12% paycut is irrelevant to your income.
One of the best uses of GitHub is being able to search for some obscure framework method name or enum constant, and find examples of working code that uses it. This has saved my life many times when trying to figure out how to configure Java frameworks to interact with each other. When searching for this kind of code, you have to wade through an awful lot of repos containing half-baked personal projects, experiments,…
Earlier quoted context omitted.
This came at the right time. I was looking into LambCI but it only supports github. I was using bitbucket for private repos. Checkout: https://github.com/lambci/lambci/blob/master/README.md It only supports github. For my hobby projects i can't afford to host gitlab CI/Jenkins or pay for premium CI services. Now, i can run my tests on Lambda,yay!
But beware and read the pricing sheet --- GitHub created a dumbed-down repo type for these new free private repos.
A lot of people are concerned about the “what if they make me the product since I’m no longer paying.” A few reasons I don’t think that will happen: - private, single contributor repos tend to be pretty small. it costs Github very little to service a single account. - Github is a growing social network for developers. Getting young engineers on the platform for free will pay off handsomely when they join a team and a…
I'm confused about this definition of social network. GitHub is a place where we work. I have thousand of commits and 1 actual friend. Am I the only one or are we changing the meaning of social?
My feeling is that this is more a move to fight competitors.
Earlier quoted context omitted.
I actually switched back to GitHub yesterday, because it‘s still better integrated in the overal tool landscape (eg Heroku). So I just pulled the trigger on a $7 subscription for private repos. And today the good news of free private repos arrived :) Edit: typo
I'm sorry to hear you left GitLab. We're working on making sure GitLab offers a great PaaS experience https://gitlab.com/groups/gitlab-org/-/epics/111 (I posted in there 3 days ago, hopefully indicating this is important to us)