I implemented the HTTPS-only Pages feature in this release.
I just wanted to say that GitLab is a great project to contribute to, with a very friendly and professional community! Definitely recommend to anybody interested in contributing to a project themselves.
Quick note, the existing Let's Encrypt integration does not support Pages. We are working on it, but it's worth noting Pages has multiple modes it can run in.
One is by setting up wildcard domains at the server level, like we have on GitLab.com with gitlab.io. We have an issue open for this, but the primary challenge is that Let's Encrypt requires DNS-01 validation for wildcard certificates, with a new challenge each renewal. That is difficult to automate through our Omnibus package. The issue tracking this work is here: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3342
> I just wanted to say that GitLab is a great project to contribute to, with a very friendly and professional community!
I'd like to second this. My experience getting a (minor, admittedly) contribution merged was painless, prompt, efficient, and dignified. If I ever run into something funny with GitLab again, it'll comfort me to know that a patch can be running on the live global site in less than a day.
We switched over to Gitlab from Stash about 9 months ago and it's been fantastic. There are so many amazing features, and the CI/CD integration has been smooth. I highly recommend it.
I, for one, am very impressed by the capability of this (mostly-remote, IIRC) team to ship so many releases, so fast. We have now one release per month!
We host most VideoLAN projects on our own instance, and the updates are now very smooth, especially compared to the beginning.
Of course, there are features that we care about a lot and are not implemented, because they don't consider them important (or maybe not worth their time, which I understand) but it's a very solid software. I hope it can replace our wiki and bugtracker soon...
> And we do want to make sure that all the features you really need are there.
So far, everything is great, but we would love to have:
- Custom Fields, in order to leave trac (such a pain, this service is);
- A way to fork/MR across Gitlab/Github instances: we don't want our instance to become yet another forge, people should use gitlab.com/GH. We would like that people can fork our projects on gitlab.com/github.com and then send PR our way. I understand this is über-hard, but that would be very nice;
- Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions).
(Btw, we currently use jenkins and we will move to gitlab-ci.)
> - A way to fork/MR across Gitlab/Github instances: we don't want our instance to become yet another forge, people should use gitlab.com/GH. We would like that people can fork our projects on gitlab.com/github.com and then send PR our way. I understand this is über-hard, but that would be very nice;
We actually have an issue open about it - https://gitlab.com/gitlab-org/gitlab-ce/issues/4013. As the issue label suggests, it's definitely a moonshot, but completely achievable in small steps / iterations.
> - Custom Fields, in order to leave trac (such a pain, this service is);
> - Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions).
Could you rephrase this? I think I'm missing the point. You can update a MR with a regular push. You can also browse through different versions of a MR diff (https://docs.gitlab.com/ee/user/project/merge_requests/versi...). A force push "is required" only if your local history doesn't match the remote history.
I think ActivityPub would be a good fit for federation across GitLab instances and would have a real chance to displace Github for open-source projects, if implemented right.
Hell, git-ssb is already working! ActivityPub would be great for GNU Social or Mastodon (or, of course, Pleroma), but I still have a soft spot for Scuttlebutt.
>- Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions).
Although not identical, it's worth noting that GitLab tracks all versions of MRs throughout the life of an MR. So, if you force push, you can compare the MR before and after the force push, via the "Changes" tab. I could be wrong, but I believe this is actually a leg up on what GitHub provides.
I wish I could understand the value add of yet another IDE. The whole reason for tech to exist is to improve things around the world, and yet brilliant minds are still spending years building one IDE after another.
"Switching branch and remembering branch names..." is a simple git status. On vim, you can get a file browser on the left by using nerdtree plugin, and to write commit messages on the right side you simply just have another tmux window open for git or other unix commands. Building a new IDE is solving a very marginal problem that could potentially create new problems. Why not spend the same amount of time creating educational videos instead on how to use existing tooling that is already readily available?
Other than this rant, I really like gitlab product (we self host at our coding camp) and deploy tokens is a pretty big value add for us for our CI flow.
Edit: Here's a good usecase for the webIDE:
If you see a typo in a comment, for example, you click the pencil icon on that line, which pops open an editor with your cursor on that line, fix the typo, and can create and submit for review a pull request right there. Less than a minute. https://news.ycombinator.com/item?id=16212234
I'm actually super happy with this feature. I don't actively develop on our product, but I do have small changes every now and then. Typically small bits of polish, but they often require a commit in multiple files. And I'd like to keep those atomic, even if they're put in a merge request afterwards. Now I can do this simply from the web interface. Less friction, more fun, better development :) so sytse, goed werk! :)
I've used it a couple of times now not to develop, but to incorporate review discussions and minor other fixes. But from my perspective the true value is for non developers, or when you're starting with Git. No need to worry about remotes and what you did or didn't sync. Or if the branch is even there and you need to set the upstream. Concepts one need to get now are branches and commits. No cloning, fetching, pulling or pushing. When starting, branches and commits are hard enough.
Than, when the new user is comfortable they can work their way up.
Yep, it is also really nice to contribute to a repo that you didn't work on before and probably won't work on after. No need to wait for a clone anymore. Our mission is everyone can contribute and we hope this will make that even easier.
I agree that as an industry we should spend more time on impactful things. That is why we based our IDE on the awesome Monaco editor of Vs code that was open sourced by Microsoft.
> I wish I could understand the value add of yet another IDE.
I was in the same boat as you, when Atom and VS Code was gaining a lot of popularity. For the life of me, I couldn't understand why GitHub and Microsoft was throwing SO MUCH money at their FREE editor. If you look at the contributors for both Atom and VS Code:
And search for @microsoft.com (use ctrl+f, if you are in windows and search for @microsoft.com), you can see that there are 27 matches. And if you search for @github.com, you can see that there are 41 matches.
This is a lot of expensive developer time for a free editor, but this appears to be the current strategy to gain developer mine share. For me personally, I'm completely happy with just using Vim, but I think my way of thinking is no longer the norm.
What GitLab is doing makes sense, and I think it's a requirement, to ensure they don't find themselves with their pants down. I would have to imagine, Microsoft and GitHub, has enough data to back such a huge commitment and it only makes sense that GitLab follows suit. I also think it's kind of interesting how GitLab is approaching this.
By integrating it into their Git hosting solution (GitLab), they are able to provide a unique workflow for developers, that Microsoft and GitHub, currently cannot. Worst case scenario for GitLab, is they detach the IDE from GitLab. Best case scenario, is they create a competitive edge, by integrating the IDE so tightly with GitLab.
Most of our contributors at my workplace are non-developers making small edits.
The GitHub web editor is good for not having to have a local git setup, but I this looks much better, we have a few issues with the GitHub editor and white space, find replace, etc.
> The whole reason for tech to exist is to improve things around the world
Thats a pretty bold claim. Do you think this is true of all "tech" or just software? Do you think it similarly wasteful when a car manufacturer spends resources building yet-another-car?
> ... yet brilliant minds are still spending years building one IDE after another.
Who do you think _should_ get to decide what brilliant minds should spend their time doing?
The tl;dr seems to be that in certain environments there's a big benefit to having the ability to browse a codebase and make a quick and simple edit without having to deal with the overhead of git.
It's great for readmes. For code, unless ( probably even if ) it has obscenely high quality functional, integration and unit tests it's not great. I've seen people commit, and code reviewers allow, broken code.
I know its not as sexy as new features, but I really wish gitlab took a look at performance. Currently its sitting at 9GiB of Memory on my dedicated server box for basically no users. I tried it on smaller instances but it was so painfully slow I ended up getting a cheap dedicated server from Hetzner.
Which is why I personally use Gitea, which is super light and performs very well. But it only has a fraction of the features of GitLab so it's not an apples to apples comparison, but my personal projects and my friends it works just fine. I combine it with Drone for testing and it totally suits my needs, and I host everything myself on a $5 VPS.
same here, gitea works for probably 90% of the users IMO, I use it to host everything these days. tried gitlab a couple of times in the past, not impressed by the performance yet.
Thanks Scott for linking to that. We're very much trying to improve the performance of GitLab.
I do think that most of our performance improvements are to improve the end-user experience. So I totally understand dijit's request to reduce memory. Today we recommend 4GB of memory to run GitLab https://docs.gitlab.com/ee/install/requirements.html#memory
It might be worth mentioning that they use jemalloc which greedily allocates memory. I "found out" while running into an issue and disabled it[1] which shaved a fair amount of memory from allocation. At the end of the day I guess it didn't matter - for me - seeing how I didn't need that memory for anything else.
Also, the cookbook for setting up postgres also takes your total ram into account.
jemalloc does not greedily allocate memory, and it's not clear to me how you would think so from reading that gitlab issue discussion. I can well imagine jemalloc not behaving as desired under certain conditions, but if so it's surely more involved than wanton naivete.
I explained poorly. I ran into issues with updating jemalloc as part of a software update. While debugging the issue I disabled jemalloc (unsetting the ld_preload) and noticied a sharp difference in how much memory ruby had allocated. I guess _pre_allocating is incorrect and a better explanation is _not releasing it_. Thanks for rebutting my argument and giving me the opportunity to elaborate.
That's what I've been using and idk if I need that much many features. Gogs gives me https+ssh, and a proper sane ui to quickly create accounts and config things. It's so lightweight I don't see me migrating to bigger stuff anytime soon.
Any clue on what gitlab-only features people need that makes Gogs unusable or unfitting? make me really curious
There's the whole CI part. Gitea miss code comments for code review.
Gitlab also have project management tools like issue boards
And surely some other things i haven't looked into
Gitea definitely do less but do it well and much in a much lighter way
For the past few years, I've been successfully running Gitolite[1] on a server with 1GB RAM. I recently checked out Gitlab as I thought it would be useful to have a nice web interface that allows users to easily see what projects are hosted and their corresponding URLs. I had to back away when I learned of Gitlab’s resource requirements.
Based on the sibling comments here, it looks like Gogs/Gitea should do what I want.
Yeah, I've tried buildkite, and like it, but the thing about CI is it should be immutable. Plus gitlab has pretty good pricing for me for my personal project (free).
Rather comically, I've been unable to import my Gitlab.com repo into an on-prem Gitlab EE instance for the last 3-4 months, due to an import bug -- seems like that's the one import that should be easy to test thoroughly, but apparently not.
Here's to hoping that this version happens to have fixed the issue!
I opened tickets with GitLab support, which were eventually closed due to inactivity (i.e. support let the issues time out without a resolution, despite me doing two 1-hour live debugging sessions with a support rep and a full stack trace highlighting the failing code).
In general I wasn't expecting to have to raise issues on the open source tracker myself after reporting to internal/paid support, but perhaps that's where I went wrong.
I'm working this quarter to help improve our quality of service. If you email me the ticket number(s) at lee@gitlab.com I'm happy to dive in and take a look. In theory, if we had clear traces an issue should have been made on your behalf. Happy to help get to the bottom of this.
Is there any roadmap for how the cloud-native chart is progressing? I’m really interested in switching to that, as the current implementation takes almost 15 minutes to restart and uses over 8GB RAM when idle for me.
We use GitLab at a small company (around 15 employees), and love it because it's free in its core offering, self-hosted, and works really well. Conveniently, it comes with MatterMost included out of the box. Great for intra-office communication!
We are at the point where we wouldn't mind scaling up to the paid 'Starter' level of GitLab if it would mean being able to replace Jira as our issue tracker. One thing that worries me though, is how GitLab seems to focus all of the relevant developments in that area (epics, roadmaps, etc.) on their 'Supreme' level of paid plans, which is way beyond our means.
Is there a clear plan for the issue tracking side of things as far as the 'Core' and 'Starter' offerings are concerned?
We are continuing to improve our issue tracking / project management at different tiers. You can take a look at these epics and issues to see much of the work that we have already planned. Most of these issues are in Core or Starter:
There seem to be several people involved with GitLab here, so maybe one of you would be kind enough to answer the question I've had for a long time: what exactly is GitLab? I've met several people who speak well of it or mention particular things they use it for, so I have to assume there is something very useful in there, but unfortunately I've always found the web site more confusing than enlightening.
IMHO the first point nails it pretty well: "GitLab is a single application with features for the whole software development and operations (DevOps) lifecycle."
> I've always found the web site more confusing than enlightening.
Did you take a look at our homepage (https://about.gitlab.com) recently? (we updated it not too long ago)
Thanks for replying. I did actually check your home page, and various others on the site, before commenting. The best way I can think of to describe my experience is that it feels like I'm reading something written for someone who already knows what they're looking for and what the context is, but that's exactly what I'm there to find out.
Perhaps some examples would help. For context, I am about to set up the infrastructure for a new project, involving source control, issue tracking, testing, deployment and so on. From past discussions with friends and colleagues who have used GitLab, I had the impression that it was somewhat like GitHub, in the sense of providing a front-end to help manage Git repos and some related facilities like issue tracking and CI, but GitLab was based on OSS and could be hosted locally. So, GitLab seems like something I should be very interested in right now. I'm an experienced developer and familiar with many other tools, so my interest is in whether GitLab might offer a better approach than things we've used before.
However, looking at the site, I can't find anything describing the relationship between GitLab and Git anywhere on the home page. I checked the features page, but again found nothing, aside from a few passing references to actions like merging but only in the context of other functionality. I tried putting "git" into the search box on the documentation page, but again, nothing. Have I just totally misunderstood what GitLab does? And if so, why "Git" in the name?
Likewise, I honestly can't tell whether GitLab is an OSS project or some sort of hosted enterprise "call us for pricing" behemoth (or both or neither). I've seen references to open source and some sort of community edition, but the "Community" link on the top of the site is clearly about something else entirely. There's a pricing page with various plans including a free plan, but while I initially assumed they were for a hosted online service, apparently they're for self-hosted. There is information about many ways to install GitLab locally on different platforms, but it's not clear what you're actually installing at that point or whether you then need some sort of licence to do anything with it. On the features page, each item has two different scales under it, one for GitLab and one for GitLab.com, but I really have no idea what the relationship between those is. There is an entirely separate feature comparison table that is actually linked from the pricing page, but that only shows one of the scales, and suggests that the lower/free tier is quite restrictive. But these look like they're self-hosted options and if there's OSS involved then how does that restriction work?
I hope you'll forgive the brain dump, but other than showing a stream of consciousness as I looked through the site earlier today and how I was unable to answer my two most basic questions, I can't think of a better way to illustrate the difficulty I encountered.
I use the community edition of Gitlab at work and the cloud version for personal projects.
Gitlab is a web interface for git.
It is like Github, but much better.
Gitlab also includes a great CI server (a bit like travis ci, or circle ci).
It has a docker registry if you need that.
It has issue tracking if you want to use that.
There is an open source free community version that does most things.
There is also an enterprise version if you need permissions managed by Active Directory or something like that.
And there is a cloud-hosted version if you don't want to host your own instance.
I'll try and clear up any confusion you might have about GitLab. Feel free to ask more questions if I left something out.
> I can't find anything describing the relationship between GitLab and Git anywhere on the home page.
The relation between git and GitLab is that GitLab is a front-end for git. However, it's so much more than that. We strive to offer features that encompass the whole DevOps lifecycle - see https://about.gitlab.com/direction/#scope for more context.
We have an integrated CI/CD system, issue tracker with boards and epics, built-in container registry, monitoring and many many others. All of them are listed in https://about.gitlab.com/features/
> Likewise, I honestly can't tell whether GitLab is an OSS project or some sort of hosted enterprise "call us for pricing" behemoth
We offer a proprietary version with added features - GitLab Enterprise Edition (EE) - https://gitlab.com/gitlab-org/gitlab-ee . It has a proprietary license. Even though it's proprietary, Enterprise Edition is source-visible i.e. you can browse the source.
> There's a pricing page with various plans including a free plan, but while I initially assumed they were for a hosted online service, apparently they're for self-hosted.
There's both a hosted solution (GitLab.com) and the option of self-hosting. The pricing page has two tabs - one for self-hosted options and the other for GitLab.com
> There is information about many ways to install GitLab locally on different platforms, but it's not clear what you're actually installing at that point or whether you then need some sort of licence to do anything with it.
No matter which package of GitLab (Community Edition or Enterprise Edition) you install locally, you'll always be able to access the free tier of features without a license.
> On the features page, each item has two different scales under it, one for GitLab and one for GitLab.com, but I really have no idea what the relationship between those is.
There's four feature / pricing tiers for self-hosted instances: Core (Free), Starter, Premium and Ultimate. From left to right, every tier has more features than the previous one. The distribution of features is documented in https://about.gitlab.com/features/ (upper scale).
If you opt for a hosted solution on GitLab.com, there's also 4 pricing / feature tiers: Free, Bronze, Silver and Gold. All public projects have access to Gold-tier features for free. The feature distribution between these tiers is also documented in https://about.gitlab.com/features/ (lower scale).
> There is an entirely separate feature comparison table that is actually linked from the pricing page, but that only shows one of the scales, and suggests that the lower/free tier is quite restrictive.
We prioritize features for one of the paid tiers if we think the feature is more relevant for larger organizations.
The relation between git and GitLab is that GitLab is a front-end for git. However, it's so much more than that.
I understand that there are lots of other features, but if I could make one suggestion to help improve the site, it would be to make that basic relationship clear -- or indeed evident at all. Apparently I did have the right general idea about what GitLab was, but I was expecting a front-end to Git to be #1 on the features page, and the rest to follow. Likewise I was expecting to find "getting started" documentation explaining things like whether Git needs to be installed independently of GitLab and where repositories are stored and how GitLab is integrated with them. In practice, I didn't find any of this in about half an hour of looking around the site, and so in effect what actually happened is that I turned up interested and having the right sort of idea and left thinking I'd totally misunderstood and GitLab wasn't what I was looking for at all. Probably not quite the result you were hoping for!
Hi, I'm rooting for Gitlab. Love your product, team, and particularly the way you all communicate with your customers.
But the root problem may be that the name "Gitlab" does not convey "Full Devops Solution". "Gitlab" the name is memorable, easy-to-spell, but having "Git" as a prefix might make it just a hair too narrow for what the product wants to be.
I am a sample size of one, so unless others have also been confused by the name, please feel free to keep on trucking.
> For example, you may now define which jobs you want to run just by tuning project variables, or you can restrict a job to be scheduled only when the variable is equal to a specific user.
How would this be used in practice?
For example-- suppose I want to give certain users access to my runners when they make a merge request. Can I use GITLAB_USER_NAME in .gitlab-ci.yml to achieve this?
1. Someone (new employee, FLOSS volunteer, doesn't matter) forks my repo. That's the normal way of working in Gitlab.
2. Someone creates a feature branch, tests it, considers it ready for merging. Again, common flow.
3. Someone creates a merge request. Totally reasonable.
So far so good. Now let's keep going.
4. I notice the merge request. It has almost certainly timed out and failed because new users don't come to the job with their own set of runners.
5. The only sane option is for me to allow them to use my runners. Ok, let's do it-- I must do the following:
6. Either have them add me to their fork with sufficient permissions to set up the runners, or log in to Gitlab as root, impersonate them, and add myself.
7. Unlock my runners from my repo and manually enable each one in the new user's fork using the Gitlab UI.
8. Retry the CI.
9. When it passes, either a) lock the runners again or b) put up with runners getting used by every single commit by the new user (which nobody, including the new user, wants).
Now, I could probably set up the runners as an initial step in welcoming a new user into the fold. That would save me the failure step #4 above. And maybe I could set up a webhook and an additional webserver to listen for it so that I can only trigger on merge requests.
But that's back to the old svn permissions pattern plus custom server hacks. That is what I wanted to avoid in the first place by using Git.
I really do want to use either a single variable or a single button click to mean "go ahead and use my runners for this particular user's merge requests." Or even, "go ahead and use my runners for this particular merge request." Even that would be a vast UX improvement.
The only serious alternative right now is for me to create a "dev" branch, have new users make merge requests to it, and just make a habit of accept them there to trigger CI. Then if tests pass merge them into master.
But that requires yet more documentation for new users and more complexity in the flow.
I just wanted to say that GitLab is a great project to contribute to, with a very friendly and professional community! Definitely recommend to anybody interested in contributing to a project themselves.
[1] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16273
[2] https://about.gitlab.com/contributing/