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.
The issue thread/request for this had been open for something like 2 years and I waited patiently for someone braver than me to implement it.
Now my custom domain on GitLab Pages automatically redirects to HTTPS. I'm happy.
Next up is to add an option to automatically renew Let's Encrypt certs for GitLab Pages.
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
The other method allows users bring their own "custom domains": https://docs.gitlab.com/ee/administration/pages/#custom-doma...
This is easier to manage, as we can do HTTP or SNI validation for each domain without hitting LE's rate limits. We are working on this now here: https://gitlab.com/gitlab-org/gitlab-ce/issues/28996
this. I've had a fantastic experience as well. Its one of those communities and projects that has been so good I have to leave a comment about it :)
Thank you GitLab team and contributors!
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 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. I understand the VideoLan needs https://gitlab.com/gitlab-org/gitlab-ce/issues/40321 and we're prioritizing it.
That's very hard to keep at a constant pace.
> 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);
This one's on our radar as well - https://gitlab.com/gitlab-org/gitlab-ee/issues/1906
> - 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.
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.
"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
Than, when the new user is comfortable they can work their way up.
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 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.
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.
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?
We should always be improving humanity and ending suffering through tech, software, law, and everything else.
> Do you think it similarly wasteful when a car manufacturer spends resources building yet-another-car?
> Who do you think _should_ get to decide what brilliant minds should spend their time doing?
Nobody. Everyone is entitled to doing what makes them happy.
I hear ya. But your analogy is buggy.
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.
GitLab's performance is a major pain point for us. We throw an absurd amount of hardware at it for mid sized teams.
have not used drone yet, will give it a shot.
It links to a list of 53 commits from this release targeting performance:
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
One big thing would be if we can run the Ruby code multithreaded https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 You can see I created that issue 2 years ago and there has been recent activity on it.
Right now GitLab the company is focussed on making complete DevOps https://about.gitlab.com/2017/10/11/from-dev-to-devops/ happening. So any help on the multi-threading is appreciated. The first thing would be to implement https://github.com/covermymeds/rubocop-thread_safety
Also, the cookbook for setting up postgres also takes your total ram into account.
Any clue on what gitlab-only features people need that makes Gogs unusable or unfitting? make me really curious
Gitea definitely do less but do it well and much in a much lighter way
Based on the sibling comments here, it looks like Gogs/Gitea should do what I want.
It does much less in term of features though
I use their hosted gitlab version, but have their CI runner on our ci box that runs docker. It's fantastic.
Here's to hoping that this version happens to have fixed the issue!
Did you happen to open an issue? It would be great to ensure this one is being tracked appropriately.
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.
It's currently in Alpha. You can see a list of ongoing efforts in https://gitlab.com/charts/helm.gitlab.io/issues
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?
Highlights are bulk subscriptions of issues, better subgroup support for labels and milestones, and expanded issue weight support.
The plans for starter are detailed on https://about.gitlab.com/direction/#starter right now the only issue management one is and API for boards https://gitlab.com/gitlab-org/gitlab-ee/issues/4266
Of course when you start paying for starter you gain the many features that are already in there: https://about.gitlab.com/pricing/self-hosted/feature-compari...
> what exactly is GitLab?
Here's a couple of points that might shed some more light on it: https://about.gitlab.com/about/.
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)
Which part of it do you find confusing? We'd love to make it better. If more direct feedback is your thing, you can also open an issue about it in https://gitlab.com/gitlab-com/www-gitlab-com/issues/new?issu...
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.
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 hope that helps a bit.
> 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
GitLab Community Edition (CE) is a completely open-source project - https://gitlab.com/gitlab-org/gitlab-ce . It's MIT licensed.
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.
You can find out more about our stewardship of the open-source GitLab CE project at: https://about.gitlab.com/stewardship/
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!
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.
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?
Keep in mind though that these variables can be overridden, so it probably shouldn't be used for security reasons: https://docs.gitlab.com/ce/ci/variables/README.html#priority...
To give a more detailed example on the nightly build, you would create a pipeline schedule that ran once per day and specified a variable: https://docs.gitlab.com/ee/user/project/pipelines/schedules....
Then you'd only trigger the nightly build job when this variable was present, using the `only` flag with the variable you defined for the job: https://docs.gitlab.com/ee/user/project/pipelines/schedules....
Let's say I whitelist user "me" and user "foo" using this variable in the .gitlab-ci.yml. Let's also assume I have runners locked to my repo.
Doing nothing else than that, user foo now submits a merge request from their fork to my repo.
Does CI now run for that merge request?
So consider the following common pattern:
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.
We are tracking more formal support for this here: https://gitlab.com/gitlab-org/gitlab-ce/issues/23902
It's a popular issue, but there are some tricky implementation details to work out.