
Gitlab 10.7 Released - jbergstroem
https://about.gitlab.com/2018/04/22/gitlab-10-7-released/
======
transmit101
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.

[1] [https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/16273](https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/16273)

[2]
[https://about.gitlab.com/contributing/](https://about.gitlab.com/contributing/)

~~~
no_protocol
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.

~~~
uallo
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-
renewal)

~~~
joshlambert
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](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...](https://docs.gitlab.com/ee/administration/pages/#custom-domains-with-
tls-support)

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](https://gitlab.com/gitlab-org/gitlab-ce/issues/28996)

------
jbk
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...

~~~
sytse
Awesome that your upgrades are smooth, thanks for posting. We're indeed a
completely remote team, see [https://about.gitlab.com/culture/remote-
only/](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](https://gitlab.com/gitlab-org/gitlab-ce/issues/40321) and
we're prioritizing it.

~~~
jbk
> We're indeed a completely remote team, see
> [https://about.gitlab.com/culture/remote-
> only/](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.)

~~~
AsyncAwait
> 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.

~~~
ChristianBundy
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.

------
songzme
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](https://news.ycombinator.com/item?id=16212234)

~~~
jstsch
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! :)

~~~
songzme
Thanks for sharing, I did not think about this use case when making my
original statement.

------
dijit
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.

~~~
sondr3
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.

~~~
wjkohnen
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.

------
thejosh
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.

~~~
meta_AU
BuildKite is a pretty compelling option. Simple concepts combined with a
powerful plugin system.

~~~
thejosh
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).

------
theptip
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!

~~~
joshlambert
Thanks for the report @theptip.

Did you happen to open an issue? It would be great to ensure this one is being
tracked appropriately.

~~~
theptip
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.

~~~
lbotos
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.

------
kuschku
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.

~~~
matteeyah
The project hosting our WIP cloud-native chart is public and available at
[https://gitlab.com/charts/helm.gitlab.io](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](https://gitlab.com/charts/helm.gitlab.io/issues)

------
Freak_NL
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?

~~~
victorwu
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/8)

[https://gitlab.com/groups/gitlab-
org/-/epics/5](https://gitlab.com/groups/gitlab-org/-/epics/5)

[https://gitlab.com/groups/gitlab-
org/-/epics/6](https://gitlab.com/groups/gitlab-org/-/epics/6)

[https://gitlab.com/groups/gitlab-
org/-/epics/22](https://gitlab.com/groups/gitlab-org/-/epics/22)

[https://gitlab.com/groups/gitlab-
org/-/epics/156](https://gitlab.com/groups/gitlab-org/-/epics/156)

[https://gitlab.com/gitlab-org/gitlab-
ee/issues/3969](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.

------
Silhouette
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.

~~~
matteeyah
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/](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](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...](https://gitlab.com/gitlab-com/www-gitlab-
com/issues/new?issue)

~~~
Silhouette
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.

~~~
matteeyah
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](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/](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](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](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/](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/](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/](https://about.gitlab.com/stewardship/)

~~~
hitekker
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.

~~~
jhasse
Isn't the main feature still Git-hosting? I think the name is fine.

------
jancsika
> 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?

~~~
joshlambert
@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...](https://docs.gitlab.com/ce/ci/variables/README.html#priority-
of-variables)

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....](https://docs.gitlab.com/ee/user/project/pipelines/schedules.html#making-
use-of-scheduled-pipeline-variables)

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....](https://docs.gitlab.com/ee/user/project/pipelines/schedules.html#making-
use-of-scheduled-pipeline-variables)

~~~
jancsika
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?

~~~
joshlambert
If it is a forked project, CI should run in their own project I believe. It
should not run on your Runners.

~~~
jancsika
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.

~~~
joshlambert
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](https://gitlab.com/gitlab-org/gitlab-
ce/issues/23902)

It's a popular issue, but there are some tricky implementation details to work
out.

------
mychael
Bravo to the Gitlab team on building such a great product. I used to really
dislike it, now I'm a big fan!

