Gitlab 10.7 Released(about.gitlab.com)
about.gitlab.com
Gitlab 10.7 Released
https://about.gitlab.com/2018/04/22/gitlab-10-7-released/
83 comments
Thank you.
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.
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.
Automatic renewal has also been added in 10.7:
https://docs.gitlab.com/omnibus/settings/ssl.html#automatic-...
https://docs.gitlab.com/omnibus/settings/ssl.html#automatic-...
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
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
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
Letsencrypt integration with pages is coming!
https://gitlab.com/gitlab-org/gitlab-ce/issues/28996#note_69...
[deleted]
> I just wanted to say that GitLab is a great project to contribute to, with a very friendly and professional community!
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!
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!
Thanks for contributing Rob, and we're very glad to hear it was a good experience.
> 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.
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.
What features you have in gitlab that you couldn't find on bitbucket / stash ?
Please add the mirror functionality to CE.
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...
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...
Awesome that your upgrades are smooth, thanks for posting. We're indeed a completely remote team, see https://about.gitlab.com/culture/remote-only/
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.
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.
> We're indeed a completely remote team, see https://about.gitlab.com/culture/remote-only/
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.)
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.)
Thanks for sharing more info about this jbk.
> - 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.
> - 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.
> A way to fork/MR across Gitlab/Github instances
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.
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.
There's this proposal issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/44486
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.
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
"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'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.
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 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.
There was discussion about this about three months ago, when this feature was first announced:
https://news.ycombinator.com/item?id=16212234
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.
https://news.ycombinator.com/item?id=16212234
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.
> 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?
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?
> Do you think this is true of all "tech" or just software?
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?
YES.
> 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.
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?
YES.
> 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.
Um. A car is not software. How do I do a pull request for a new clutch.
I hear ya. But your analogy is buggy.
I hear ya. But your analogy is buggy.
They said tech. My question was if they would apply the same logic to physical engineers, they they should be spending their time differently.
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 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.
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 would have loved to see this somehow merged with Eclipse Che instead
> 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:
https://public.gitsense.com/insight/github?r=Microsoft/vscod...
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.
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:
https://public.gitsense.com/insight/github?r=Microsoft/vscod...
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.
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.
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.
[1]: http://gitolite.com/gitolite/index.html
Based on the sibling comments here, it looks like Gogs/Gitea should do what I want.
[1]: http://gitolite.com/gitolite/index.html
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.
We use GitLab on prem at work because we want the features. For private stuff or super small teams I'd chose Gitea as well. And/or GitLab.com.
GitLab's performance is a major pain point for us. We throw an absurd amount of hardware at it for mid sized teams.
GitLab's performance is a major pain point for us. We throw an absurd amount of hardware at it for mid sized teams.
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.
have not used drone yet, will give it a shot.
have not used drone yet, will give it a shot.
Bitbucket. It's cheap.
Agreed. I really would prefer to use Gitlab, but at the moment I'm using Gogs on my Linode instance because it runs smoothly in <1GB of RAM.
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
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
Gitea definitely do less but do it well and much in a much lighter way
It may be coming in the near future: https://github.com/go-gitea/gitea/pull/3748
I switch to gogs (and now gitea) for this reason 2 years ago.
It does much less in term of features though
It does much less in term of features though
They have a dedicated section about performance improvements in the release notes.
It links to a list of 53 commits from this release targeting performance:
https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=...
It links to a list of 53 commits from this release targeting performance:
https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=...
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
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
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
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.
1: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3313
Also, the cookbook for setting up postgres also takes your total ram into account.
1: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3313
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.
Gitlab is pretty much the only provider other than CircleCI to get CI right.
I use their hosted gitlab version, but have their CI runner on our ci box that runs docker. It's fantastic.
I use their hosted gitlab version, but have their CI runner on our ci box that runs docker. It's fantastic.
What do other provides do wrong?
we have been recently exploring concourse and I would say their approach to CI has been very refreshing.
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!
Here's to hoping that this version happens to have fixed the issue!
Thanks for the report @theptip.
Did you happen to open an issue? It would be great to ensure this one is being tracked appropriately.
Did you happen to open an issue? It would be great to ensure this one is being tracked appropriately.
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.
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 [email protected] 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.
The project hosting our WIP cloud-native chart is public and available at https://gitlab.com/charts/helm.gitlab.io
It's currently in Alpha. You can see a list of ongoing efforts in https://gitlab.com/charts/helm.gitlab.io/issues
It's currently in Alpha. You can see a list of ongoing efforts in https://gitlab.com/charts/helm.gitlab.io/issues
[deleted]
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 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:
https://gitlab.com/groups/gitlab-org/-/epics/8
https://gitlab.com/groups/gitlab-org/-/epics/5
https://gitlab.com/groups/gitlab-org/-/epics/6
https://gitlab.com/groups/gitlab-org/-/epics/22
https://gitlab.com/groups/gitlab-org/-/epics/156
https://gitlab.com/gitlab-org/gitlab-ee/issues/3969
Highlights are bulk subscriptions of issues, better subgroup support for labels and milestones, and expanded issue weight support.
https://gitlab.com/groups/gitlab-org/-/epics/8
https://gitlab.com/groups/gitlab-org/-/epics/5
https://gitlab.com/groups/gitlab-org/-/epics/6
https://gitlab.com/groups/gitlab-org/-/epics/22
https://gitlab.com/groups/gitlab-org/-/epics/156
https://gitlab.com/gitlab-org/gitlab-ee/issues/3969
Highlights are bulk subscriptions of issues, better subgroup support for labels and milestones, and expanded issue weight support.
As you noted a lot of the planning features are focussed on portfolio management that is part of our ultimate tier.
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...
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...
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.
Glad to hear you're interested Silhouette!
> 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...
> 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...
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.
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 hope that helps a bit.
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'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
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/
> 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/
Thanks for following up.
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!
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.
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.
Isn't the main feature still Git-hosting? I think the name is fine.
> 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?
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?
@jancsika you could implement a whitelist using this feature, by having jobs only run for specific usernames.
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....
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 me see if I understand it.
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?
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?
If it is a forked project, CI should run in their own project I believe. It should not run on your Runners.
That is my understanding, too.
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.
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.
jancsika, totally understand the forking workflow is not ideal right now. Thanks for sharing your use case and using GitLab.
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.
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.
Bravo to the Gitlab team on building such a great product. I used to really dislike it, now I'm a big fan!
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/