
GitLab 10.4 released - okket
https://about.gitlab.com/2018/01/22/gitlab-10-4-released/
======
protomikron
CI is fine and I am happy GitLab is offering it as it makes sense to integrate
strongly with source control. But building a web-IDE?

Please don't go down this rabbit hole, GitLab - there will be dragons (in
essence you will have to build an OS for the browser). Developers have their
beloved editors that work very well for the most part (at least better than
their JS counterparts).

~~~
zellyn
I was at Google when they implemented something like this in their source code
viewing system. 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.

It is fantastic.

I'm so glad Gitlab is providing competition to Stash and Github. Nice work.

~~~
segmondy
Someone in my twitter feed was just asking for this feature last night. I
don't want to open an editor, checkout, fetch, edit, commit, push, open a PR
to a PR when I can just do it in an editor. I don't use Gitlab but I agree,
it's a brilliant feature.

~~~
vog
This is not so much an argument for a Web IDE.

It is an argument against the cumbersome Git workflows, and the even more
cumbersome GitHub Pull Request workflow on top of that.

Why can't I fix the typo in my editor, hit "upload", enter some commit message
and be done with it?

~~~
zellyn
I'd respectfully disagree. In a monorepo the size of Google's (or even
Square's, where I work now), there would be a whole schlep to open the file in
your editor. Much better to fix right there where you're browsing.

Also, at Google, it's not even Git, or a Git/Github workflow.

~~~
vog
Please respect the context of a comment, and refrain from strawman arguments.

This was _not_ about whether or not this feature is good for the Google repo
(of course it is, nobody disputed that!). This was about whether and how to
apply this to other projects.

~~~
zellyn
Please respect the fact that some of us actually read comments and reply to
them thoughtfully. Throwing around trite accusations of “strawman” arguments
doesn't help anything.

The comment I replied to was claiming that it was the git workflows (I assume
for submitting, but am open to correction) that make this cumbersome. I was
pointing out that in an enormous repository (and I did mention my current
employer as an example too -- and we use Git, not Google's internal tooling),
just getting to the point of having the latest version of some far-flung file
that you usually never touch open in your editor is cumbersome enough to make
this feature a win, regardless of whether the workflows for submitting the
change disappear altogether.

~~~
vog
Thanks for the clarification.

I would still see this as an instance of unnecessary complexity in the Git
workflow - mostly the workflow for submitting, but not just that.

Of course, one could also argue that this is by design. Still, I don't see why
a lightweight client that is feasible for the web would not also be feasible
for the command line.

For example, it would be great to be able to have a checkout with reduced
history. You could reduce in time and/or space, i.e. just a subtree and/or
just the last 3 months. Even a distributed VCS doesn't need all history and
all files as long as it has the relevant checksums.

~~~
zellyn
I totally agree about the unnecessary complexity of the git workflow.

If you haven't seen it before, check out gitless: actual research-backed
simplification of the git commandline workflow.

Reduced views of files and history are super useful, but unfortunately don't
work in the case where you've browsed your way to a part of the code that you
seldom work on, since you're less likely to have loaded them into your narrow
slice: it's still nice to be able to fix spelling mistakes far afield, and the
web editing helps nicely for that.

What _would_ help with the cases you describe, though, is a synthetic
filesystem view, cache-faulted in as needed, like the one Microsoft is
building. I'm pretty excited about where that's heading.
[https://github.com/Microsoft/GVFS](https://github.com/Microsoft/GVFS) for the
project,
[https://blogs.msdn.microsoft.com/devops/2017/11/15/updates-t...](https://blogs.msdn.microsoft.com/devops/2017/11/15/updates-
to-gvfs/) for the announcement they're going to be working with Github. Pretty
cool stuff.

------
nilsjuenemann
It looks like that GitLab got the Featuritis. Instead of adding tons of
unready and half baked feature it should focus on stability and performance.

~~~
mh-cx
Yeah, and they've promised to work on performance for ages now with almost no
improvement.

I run a very small installation with only a couple of projects and some
hundred issues on a 4 GB machine. It eats up 2 GB (sigh!!!) - and often still
feels extremely slow. I mean 2 Gigabytes!! What for? That's a multitude of all
the data I have in the DB there. And then it's not even used for something
useful like caching. Some pages take several seconds to load. As a developer
that's totally unacceptable to me.

Is ruby really such a mess that it's impossible to run an app with reasonable
memory consumption?

~~~
lloeki
> Is ruby really such a mess that it's impossible to run an app with
> reasonable memory consumption?

Yes.

Any non-trivial Ruby app will quickly eat up 500MB, and any non-trivial Rails
app will soon balloon to 1GB, with things getting worse over time due to
memory fragmentation†. Since there is no parallelism your only option is to
either have more unicorn workers, for which prefork and COW are hardly working
to save you from duplicating memory, especially over time, or have puma
threads and use JRuby, which is a memory hog of its own and often slower than
MRI.

There have been arguments made that developer time trumps CPU time [0] but
there are some workloads and problem domains and uncontrollable events for
which this works at the beginning yet later on you find having yourself
painted into a corner as suddenly things are not sustainable because you just
can't throw more hardware at the issue without going belly up[1]. Once the low
hanging fruits have been reaped you're being challenged just to make your app
behave within established parameters with diminishing returns, which I'm sure
you'd rather spend on solving _actual_ problems for your customers. At that
point you might just as well spend the money on rewriting part or all of your
app in a more frugal ecosystem and mindset[2].

† Switching to jemalloc may or may not help. Over here it did not.

[0]: [https://m.signalvnoise.com/ruby-has-been-fast-enough-
for-13-...](https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-years-
afff4a54abc7)

[1]:
[https://twitter.com/migueldeicaza/status/950054181045440518](https://twitter.com/migueldeicaza/status/950054181045440518)

[2]:
[https://twitter.com/lloeki/status/950079609051152384](https://twitter.com/lloeki/status/950079609051152384)

~~~
mh-cx
Thanks. I was afraid to hear something like this.

Being a PHP developer myself it's really hard to believe that resource
consumption is obviously treaded with so little priority in the rails/ruby
world.

And some attitudes here like "who cares? memory/cpu is cheap nowadays" are in
my opinion part of the problem. I'd say, well written software should use as
little resources as possible. Probably a habit that comes from my early days
on a C64 back in the 80s.

~~~
maxehmookau
> well written software should use as little resources as possible

It's about priorities. IMO if using as little resources as possible is
priority number 1, then something is amiss.

------
_pdp_
The security testing feature is definitely interesting but I wonder how it
performs as that by itself is a non-trivial task. It can be done for sure but
it takes a lot of resources and care to make it useful.

EDIT:

I would like to add that if this feature is in fact really useful and it
works, the price for the GitLab Ultimate is justified if the license does not
restrict you to the number of targets you can test. It can be used as a
service and could potentially replace other infrastructure in a typical corp
environment that is used mainly by the security team. But as I said earlier,
this is a non-trivial task.

EDIT 2:

This is my last edit. We use GitLab CI internally and it is quite nice
although it is not without issues. There are some really funky problems. But
it works and I love the fact that it is integrated into the GitLab product.
Except for TravisCI which makes it trivial, most other CI tools are very
difficult to setup and maintain and for small teams this is yet another
annoying thing to do. As a startup, I can say it is very useful.

~~~
theptip
The DAST feature uses ZAP under the covers, their integration is a thin
trigger around that tool. You can already use it for free outside of GL.

[https://hub.docker.com/r/owasp/zap2docker-
stable/](https://hub.docker.com/r/owasp/zap2docker-stable/)

[https://docs.gitlab.com/ee/ci/examples/dast.html](https://docs.gitlab.com/ee/ci/examples/dast.html)

~~~
_pdp_
I was suspecting that. Thanks for sharing this info. It will be really nice if
you guys implement ways to swap the built-in DAST tool. My startup is actually
going to release something really cool and useful in the next couple of weeks
and it will be awesome if we can provide features to be compatible with
GitLab.

~~~
sytse
Interesting. If you want to integrate it there are instructions in the docs
[https://docs.gitlab.com/ee/user/project/merge_requests/dast....](https://docs.gitlab.com/ee/user/project/merge_requests/dast.html)
(use gl-dast-report.json to send results back).

If your product is as cool as you say it is we would love to add it to GitLab
by default and run both ZAProxy and yours by default.

~~~
_pdp_
Thanks. I will have a look. Btw, the tool will be a black-box vulnerability
scanner but just like ZAP, it will be able to proxy as well - all nicely
packaged with minimal dependencies and no framebuffer rendering - so it should
be snappy.

~~~
theptip
Is there a repo I can follow along at? Sounds interesting.

------
relaxatorium
Are most if not all of GitLab's future CI and CD improvements going to be
focused on using Kubernetes and/or containers exclusively?

We're not using that method of either hosting GitLab or deploying our software
at my company for various historical reasons, and while GitLab has been good
for us overall in its basic workflow, it's a bummer how much of the future
roadmap and CD/Devops improvement seems not to apply to our setup.

~~~
Snappy
We're definitely doing a lot with Kubernetes, especially within CD, but it's
not completely exclusive. We usually provide powerful primitives that can be
used for anything, but make it easier if you're using Kubernetes.

Take monitoring for example. You can add Prometheus monitoring to (nearly)
anything. But if you happen to use it with Kubernetes, we'll grab a bunch of
data automatically. If not, you may have to configure it yourself.

------
pritambarhate
At my company, we use Gitlab only as version control system and it works very
well for around 100 programmers. We run it on an EC2 medium instance, around
200 GB standard SSD storage.

We don't use Gitlab for CI. We use Jenkins.

For task and issues management we use JIRA.

Yes, it's 3 tools to manage but since each of the tools is really optimized
for its task, it works really well.

~~~
Waterluvian
Didn't even know gitlab has CI. At my office we have Jenkins plugged into our
local gitlab instance.

~~~
lloeki
GitLab CI is, for us, configurable in ways that CircleCI and Travis are not,
by a long shot (but they both have other features that gitlab doesn't have,
it's just that we don't need them)

I sure miss CircleCI step folding in the log output though.

~~~
allan_s
this, step folding is definitely missing in gitlab-ci compare to travis,
especially as it seems most CI product have it and (I think) it something that
only require frontend developement ?

~~~
Snappy
Thanks for the feedback. Here's an issue to track the request:
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/14664](https://gitlab.com/gitlab-org/gitlab-ce/issues/14664) and I
added it to our Missing features section with [https://gitlab.com/gitlab-
com/www-gitlab-com/commit/ddfc9ee1...](https://gitlab.com/gitlab-com/www-
gitlab-com/commit/ddfc9ee10a1fdd39dfabd7ec2bbcdabbbb2fdf61).

------
KeitIG
I had to use Gitlab several times in the past, mostly because the companies I
was working for wanted free private repositories.

Though I appreciate to have a Github alternative with some really solid CI
tools, it just feels like Gitlab cannot compete. Discussions and the UI in
general are unreadable, everything feels slow (10 seconds to populate the
asignee dropdown, come on...), updates and deployments every two days in the
middle of work days ("sorry, I cannot push, Gitlab is down"), and the
cringiest thing of all, seeing: "deploying Gitlab CE 10.4.0-rc8" [1].
Releasing Release Candidates?!

Maybe I should try to deploy Gitlab on some server of my own.

[1]
[https://twitter.com/gitlabstatus/status/954491741322776582](https://twitter.com/gitlabstatus/status/954491741322776582)

~~~
dijit
What people don't understand about gitlab is that it's a absolutely monumental
resource consumer.

I run one for a community of hobby developers and to keep my stuff out of
github for ideological reasons, but it's running on what is, by _FAR_ the most
beefy machine I run.

Normally I have machines that are a couple cores, couple gigs of ram, or
single purpose machines with under 1G and a dedicated thread on the
hypervisor.

Gitlab has a 32G DDR3/8 Physical core CPU machine to itself.

I consumes, at any given time, about 25% of that (before FS caches, which,
you're going to want).

I had a friend running this before me on a VPS with 4G of memory and the thing
was so annoyingly slow that we blamed the hoster and our users were turning
back to bitbucket/github.

Since the upgrade, things are smooth as a babies butt.

Although it's hard to justify the SERIOUS expense of this server, it's
certainly fast enough. I worry about larger deployments though.

Btw, you can get a taste for yourself if you like;
[https://git.drk.sc](https://git.drk.sc)

Maybe it doesn't scale very well with many users/projects. We've only got a
couple hundred projects and around 100 users. (and only a handful of CI
runners)

~~~
zebra9978
Suggest gitbucket -
[https://gitbucket.github.io/](https://gitbucket.github.io/)

blazingly fast (a single war file - just run "java -jar gitbucket.war" to get
started) and has a very nice UI. A plugin system enables you to extend the
functionality (including CI) ... and a very active dev community.

[https://gitbucket.github.io/](https://gitbucket.github.io/)

~~~
carussell
For anyone running this, can you comment? For example, one recurring
criticism, before GitLab and the community managed to stamp out the
expectation that it would be feasible, was that people were trying to self
host a GitLab instance on a cheap SBC (e.g., a Raspberry Pi) or the smallest
DigitalOcean plan and were surprised when this wasn't doable, while Gogs and
Gitea handle this fine.

So to get a general idea of what sort of setup is expected in order to run a
gitbucket instance, if you're running one, what are the relevant details?

------
kuschku
> The gitlab Helm chart is deprecated, and will be replaced by the new cloud
> native GitLab chart.

On the other hand

> Cloud Native GitLab Helm Chart. THIS REPOSITORY IS UNDER HEAVY DEVELOPMENT.
> IT SHOULD NOT BE USED FOR ANYTHING EXCEPT DEVELOPMENT

So, what should I use now? also,

> A migration will be required to move from the current deprecated chart, to
> the new cloud native GitLab chart.

Yet I don’t see any explanation for how to migrate?

~~~
Snappy
From
[https://docs.gitlab.com/ee/install/kubernetes/](https://docs.gitlab.com/ee/install/kubernetes/),
the best way to run GitLab on Kubernetes today is the gitlab-omnibus chart:

[https://docs.gitlab.com/ee/install/kubernetes/gitlab_omnibus...](https://docs.gitlab.com/ee/install/kubernetes/gitlab_omnibus.html)

It's in beta, with some limitations on it's production-worthiness - basically
that the Postgres Helm chart that it depends on isn't configured as well as
the Postgres built into regular Omnibus.

I know it's confusing that we've got several charts, but we're trying really
hard to reduce that down to one as quickly as possible.

~~~
kuschku
That’s the one I’m using, but based on today’s release page saying the Helm
chart is deprecated and I should use the cloud-native GitLab chart, and based
on what your link to the Omnibus chart says:

> This Helm chart is in beta, and will be deprecated by the cloud native
> GitLab chart.

I interpreted it as this being deprecated.

That said, great work on performance and startup times in the past months, for
the first time my 2-user GitLab isn’t maxing a full core and using 6GB RAM
anymore, but instead using 60% of a core and 6.3GB RAM, while site load times
have gone down significantly, and startup now completes actually within of the
first 5 minutes (before, Kubernetes’ readiness checker often killed GitLab
before it managed to come up)

~~~
joshlambert
Hi Kuschku,

Sorry for the confusion, as noted we are trying to remedy this with a single
chart as quickly as possible.

Currently we have two Helm charts that can deploy GitLab, "gitlab" and
"gitlab-omnibus".

* The "gitlab" chart deploys only GitLab itself and is not recommended. This is the chart that has been announced as deprecated in the blog post.

* The "gitlab-omnibus" chart is what we recommend users to install today, and deploys everything you need for a working GitLab installation. (Postgres, Redis, an Ingress, etc.)

We still support and maintain the "gitlab-omnibus" chart, but it too will
eventually be deprecated as well in favor of the upcoming cloud native charts.

The cloud native charts will have a significant number of advantages,
including:

* Separation of components for improved horizontal scaling

* Improved resilience

* Faster startup time (current container runs `gitlab-ctl reconfigure` on every startup)

* No need for root access

Due to the significant architectural changes, migration will be via
backup/restore.

~~~
kuschku
> * Faster startup time (current container runs `gitlab-ctl reconfigure` on
> every startup)

Oh my god, how much I'd love that.

On the topic of cloud native charts, can I use the new cloud native gitlab
chart (if I run an external prometheus, postgres and redis already separately)
today? And how would I migrate?

And one thing I'd love to see is building docker containers without having to
give the runner access to the host's docker. How do other CI solutions do
that?

~~~
joshlambert
> On the topic of cloud native charts, can I use the new cloud native gitlab
> chart (if I run an external prometheus, postgres and redis already
> separately) today? And how would I migrate?

The cloud native chart is still under development and breaking changes will
occur, so I would not recommend using it for anything outside of testing. For
example our current sprint is focusing on storage persistence.

For migration, you would perform a backup of the current instance and restore
the backup onto the new cloud native based deployment.

------
ggregoire
I still have 20 FPS when scrolling in a big commit diff.

I also wish they improve a bit the UI/UX in general. I've used Github for
almost a decade and GitLab feels a bit messy.

~~~
jakecodes
Hi Jacob, Frontend Lead here. This is very high on my list. I have a team of 5
FE engineers (1 being me) focused on improving performance and this is one of
the big things on our list of highest priority performance improvements.

------
Gee19
Has the CI/CD > Environments table styling been fixed? All the environment
names are cut off and the table isn't resizable/sortable/searchable.

It's basically unusable in it's current state.

~~~
connorshea
Thanks for the feedback, I looked into it and it looks like neither of these
problems have been fixed as of yet. I've asked the CI and UX teams if we can
work on the Environments page.

Here's the issue for the table size: [https://gitlab.com/gitlab-org/gitlab-
ce/issues/41594](https://gitlab.com/gitlab-org/gitlab-ce/issues/41594)

------
theptip
The static/dynamic scanners are pretty cool; I just spent a couple days
configuring the same functionality using the underlying open-source projects
Clair (for Docker) and Bandit (for Python).

Doesn't seem worth the price bump from EES to EEU for me (which is a 4x per-
seat increase), but this is a good feature for those willing to pay for it (or
who already have another reason to buy the Ultimate edition).

Looks like my next task is to reimplement the DAST feature, which relies on
the owasp/zap2docker-stable container under the covers.

------
jancsika
I like Gitlab a lot, but I still struggle with things that shouldn't be hard.

For example: I have a single build box with a VM for linux, a VM for Windows,
and one for OSX. When I commit, CI queues up the runners. Great. Except that
there is some hard coded value of 1 hour after which the remaining jobs in the
queue will get dropped. That means if a single job takes over an hour the
remaining jobs will automatically fail, _even if_ you up the job timeout
limit. No error messages _at all_. Just failed jobs with blank logs.

You have to go in to a ruby configuration file and up the timeout to something
big enough to accommodate your _total_ time executing all runners, which means
you must know that value in advance. Each update of gitlab kills that conf
file so you have to log in and change it back and the stop/start the Gitlab
instance.

Edit: clarification

~~~
ayufan
Thanks. We are aware of this issue, and we even know what is causing that, we
also have ideas how to fix that. The plan is to release a fix with 10.5:
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/38265#note_55...](https://gitlab.com/gitlab-org/gitlab-
ce/issues/38265#note_55320316).

GitLab CI/CD Lead

~~~
jancsika
What's frustrating is that is a regression-- I used to be able to queue up
many jobs and never got the job failures (which, again, give no error message
whatsoever).

------
agnivade
Looks like HN loves to shit on Gitlab.

I will chime in with my experience. As a small startup, we have been using
gitlab.com with a private CI server for over a year now. The UI performance
has _most definitely_ improved. And their deployments do not cause outages
anymore.

Great work team !

------
wyldfire
I've started using gitlab for an open source project and I really like it.
With respect to git repos it's indistinguishable from GitHub (or better?),
_plus_ it has CI features integrated in.

The only thing that would be neater would be if they offered an OS X and/or
Windows runner in their CI. But since I'm not paying for the service, I'm
pretty happy with how it works.

~~~
connorshea
We do have support for macOS and Windows in Runner, though you'll have to run
them yourselves. We're looking into offering hosted macOS and Windows Runners
for the future, but we have no solid timeframe for those right now.
[https://gitlab.com/gitlab-
com/infrastructure/issues/3183](https://gitlab.com/gitlab-
com/infrastructure/issues/3183)

~~~
wyldfire
Yeah, sorry if I was unclear -- it's supported by the product but no runners
are available for the gratis service.

I saw that issue before but it refers to "gold subscribers" which I'm not
(just another freeloader).

Definitely keep up the good work, it's an awesome product and it's awesome
that you offer an open source release.

------
dominotw
reminder: gitlab still has blatant false claims on their website.

> GitLab has 2/3 market share in the self-hosted Git market [1]

Their CEO admitted that it was wrong here many times but chooses to keep those
blog post up without correction. [2]

1\. [https://about.gitlab.com/2017/06/29/whats-next-for-gitlab-
ci...](https://about.gitlab.com/2017/06/29/whats-next-for-gitlab-ci/)

2\.
[https://news.ycombinator.com/item?id=15703221](https://news.ycombinator.com/item?id=15703221)

~~~
sytse
I stand by the claim we have 2/3 market share in the self-hosted git market.
The claim is now linked to a page that contains the details
[https://about.gitlab.com/is-it-any-good/](https://about.gitlab.com/is-it-any-
good/)

~~~
dominotw
buddybuild and bitrise are not representative of * all * self-hosted git
market. Your claim is totally absurd.

See responses to your similar comment here
[https://news.ycombinator.com/item?id=15704055](https://news.ycombinator.com/item?id=15704055)

Also discounting jenkins as "not modern"( whatever that means) and declaring
yourself as number one is so dishonest. You "standing by it" means nothing.

Why is so important to you push these lies, I don't get it.

~~~
sytse
buddybuild and bitrise data probably has a bias in it. But we didn't find much
else to go on. If you of anyone else knows of something we should use instead
please let me know.

I think that since the blue ocean update to Jenkins they have added lot of the
next generation features. I'll either specify the claim better or lange it
later today.

~~~
dominotw
> But we didn't find much else to go on.

Don't make claims based on unreliable data. I am not sure how else to express
this.

see similar comments here
[https://news.ycombinator.com/item?id=15704407](https://news.ycombinator.com/item?id=15704407)

~~~
sytse
No data is perfect, we consider the data reliable.

As promised I changed the wording of our CI/CD claims
[https://gitlab.com/gitlab-com/www-gitlab-
com/commit/64ce89fd...](https://gitlab.com/gitlab-com/www-gitlab-
com/commit/64ce89fd740daf49580f1137d79b37af2e9cdc72)

~~~
dominotw
> buddybuild and bitrise data probably has a bias in it.

> we consider the data reliable.

I give up!

------
deedubaya
I tried to sign up to GitLab the other day. OAuth for Google seems to be
broken for me. I reached out on twitter, and it never got resolved. Just me
shouting into the void, apparently. ¯\\_(ツ)_/¯

~~~
connorshea
Hey, sorry about that. I just replied.

------
atsaloli
Just a reminder, as a GitLab reseller, I offer a 10% discount on GitLab
Enterprise Edition to the HN community. My email is in my profile.

~~~
aaron-lebo
Could you explain the reseller thing? The Gitlab people are on HN, why don't
they just sell directly to the community?

~~~
atsaloli
Oh, they do. You can buy directly from GitLab at
[https://about.gitlab.com/products/](https://about.gitlab.com/products/)

However, as a reseller and a member of the HN community, I can offer HN a
discount on list price which comes out of my cut.

~~~
aaron-lebo
Thanks. Good luck.

------
jpkeisala
Who are competitors of Gitlab?

~~~
MadcapJake
Hosted: GitHub, SourceForge, BitBucket

Self-hosted: Gitea/Gogs, Phabricator, Tuleap

~~~
wodenokoto
Github Enterprise is on-premise, so I'd call it self hosted.

[https://enterprise.github.com/faq](https://enterprise.github.com/faq)

