The 'quick fix' for setup these days is supposed to be to use a docker image... but the docker image most people use is unofficial, the maintainer is swamped and has a policy of ignoring problems, and although it runs it doesn't work well with real IPs/DNS/SSL/etc. for common cases (eg. email setup silently fails for many and has for ages - see https://github.com/sameersbn/docker-gitlab/issues/596 and https://github.com/sameersbn/docker-gitlab/issues/1005 which I recently opened) and adds the docker-is-a-moving-target complexity issue to the potential user's stack.

Normally I am based in China. Given that Github access is not super fast or stable there, you guys have a great opportunity to take that market. I'd personally love to use Gitlab both for my own business and those I consult for, but I can't get past go with mail on real infrastructure, and experiences with upgrades to date have been terrible.

Just offering my own recent experiences as a point of reference.

I was under the impression that everyone used the fully featured official docker image (https://hub.docker.com/r/gitlab/gitlab-ee/). We've been using this for over a year without issues now. Is there a reason you need the unofficial version? Does it do something different?

I've added a section to say that these images are officially supported with https://gitlab.com/gitlab-org/omnibus-gitlab/commit/26501d91...

If you experience problems with them please feel free to file an issue under https://gitlab.com/gitlab-org/omnibus-gitlab/issues (more than 1500 have been closed there already).

I suspect that many of the upgrade problems you experienced can be solved by using an official image.

I agree that the demo video we show is limited to a specific Kubernetes installation (OpenShift self hosted). In 2017 we plan to make sure everyone can use it, for details see https://gitlab.com/gitlab-org/gitlab-ce/issues/25986

OK. I definitely remember running in to something that looked official but wasn't up to date (remotely) a few weeks ago. Perhaps it was this image, perhaps not. IIRC at the time I was judging only from the 'updated [time periods] ago' data in the docker hub webpages.

Anyway, if there is an urgent problem with those consider tweeting to @gitlabstatus to get our attention. I think it won't be needed since many people use them so we should be on top of them. The only package that is sometimes late is the non-docker package for the Raspberry Pi since it takes hours to build.

Out of curiosity, why use the Docker image over our Omnibus package? Omnibus is generally what we recommend, but if that's not good enough we'd love to know how it can be improved.

Basically I'm at this point: 'what's the easiest self-contained box to run and maintain', with conditions 'I have an IP but it's not dedicated (ports 22/80/443 unavailable)' and 'there may not be existing DNS/SSL for this server but I can set it up' and 'SMTP from this IP is not desired/desirable, but I have an existing offsite ISP allowing relay with credentials'. This doesn't strike me as particularly weird, except that in the latter case Google is not an option (GFW'd from China).

    docker pull gitlab/gitlab-ce:latest
    docker stop gitlab
    docker rename gitlab gitlab-old
    docker run --detach --publish 60100:80 --publish 58432:22 --name gitlab --restart always \
         --volume /var/volumes/gitlab/config:/etc/gitlab \
         --volume /var/volumes/gitlab/logs:/var/log/gitlab \
         --volume /var/volumes/gitlab/data:/var/opt/gitlab \
         gitlab/gitlab-ce:latest
    
    # after verifying the new image works, docker rm docker-old; docker rmi [old image]. 

I did just get started with it, but I have to say the omnibus install was fairly easy.

The Sameer docker image used to be the only way to run GitLab with Docker but we don't recommend it and it is no longer listed on our installation page https://about.gitlab.com/installation/ to prevent confusion.

Also see my answer in https://news.ycombinator.com/item?id=13243443

FWIW: I ran GitLab at my previous company (2yrs agoish) because GitHub was a non-starter for political reasons. We loved it! Keep rocking.

Here's some thing I wish for gitlab:

1. On merge, run "stop_review" so that we don't end up with a lot of old review apps.

2. I wish you could take over https://github.com/sameersbn/docker-gitlab or offer something similar. I find it a little crazy that you have a single docker image for redis, gitlab, postgresql. There's multiple reason why we don't want to use this, but the simplest is: we already have mysql running (and feel no need to move to pgsql), and we already have experience in running redis.. I kinda like my containers to do 1 thing and 1 thing well.

Merry Christmas, thanks for this patch!

Thanks for the wish list!

1. Automatically stopping the review on merge makes a lot of sense. The issue for that is in https://gitlab.com/gitlab-org/gitlab-ce/issues/22191 and it got added to 8.13 if I'm not mistaken https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6669

2. As you know we already have official docker images with https://docs.gitlab.com/omnibus/docker/ so we won't take over Sameer his work. If you want to have separate containers for the datastores (totally a good idea) I recommend you use the Helm Chart https://github.com/kubernetes/charts/tree/master/stable/gitl... It has separate containers for Redis and PostgreSQL https://github.com/kubernetes/charts/blob/master/stable/gitl...

1. Since the review apps is tied with a branch, as soon as branch is deleted the review app is stopped. This actually happening in above video. At the end you see the stopped review :)

2. You can use your own services. Sid did propose to use Helm package. If you look into Helm package sources you will see how they do it and following the same you get the same result on vanilla Docker.

Kamil, GitLab CI Lead

My name is Angela and I do researches on user experience for different Git tools on the market. I’m kicking off a round of discussions with people who use Git tools. Ideally, I’d like to talk to people that sit on a team of 3 or more.

If this is you, I would love to talk to you about your experience with <using> Git tools, or just some of the pain points that are keeping you up at night when doing your jobs. 

I’ll just need 30 mins of your time, and as a token of my thanks to those that participate, I’d like to offer a US$50 Amazon gift voucher. 


If you’re interested, just shoot me an email with your availability over the next few weeks and we can set up a time to chat for 30 minutes. Please also include your timezone so we can schedule a suitable time (as I’m located in San Francisco). Hope to talk to you soon!

Cheers, 
 Angela Guo [email protected]

EE is open source but requires a license. Do you just trust companies won't download the source code and run it. Do you have heartbeat code injected somewhere to ping servers that are running EE to homebase?

I'm thinking of starting a project, charge money but also open-source it. Curious what your strategies are, especially since the project is still greenfield.

Thanks!

It's the same codebase with some additional code. Every few days we merge CE into EE[1], which always ends up with some merge conflicts – though those are getting better as we learn to engineer around them – and its own problems, but it works pretty well. I think this is a great system, even with its drawbacks, if you want to keep the base product as FOSS. Just be aware of the problems you'll likely run into, and avoid implementing any EE-only features that will cause crazy merge conflicts.

>EE is open source but requires a license. Do you just trust companies won't download the source code and run it. Do you have heartbeat code injected somewhere to ping servers that are running EE to homebase?

It has a built-in system for uploading the license and verifying that the license covers the users of the instance. The license (as in the copyright license) says that users cannot use EE if they get around that. We don't have many cases of piracy as far as we know, and don't care too much. No major enterprise customer would realistically pirate software since that'd be a legal nightmare if they were caught.

>I'm thinking of starting a project, charge money but also open-source it. Curious what your strategies are, especially since the project is still greenfield.

Best of luck! It's awesome to see others try to go for this kind of model, I hope it works for you :)

Some others to look at: Sentry, Mattermost, and Code Climate.

[1]: Example of a CE-to-EE merge request: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/991

It is _not_. You cannot distribute it. That makes it not open source.

Someone else put it better than I could:

> Likewise a Source Available is not necessarily Open Source, but Open Source is necessarily Source Available.

https://haacked.com/archive/2006/07/26/CodeAvailableVsOpenSo... (requires you to accept github cert because https is difficult for some reason)

Blog github at https://github.com/Haacked/haacked.com

We encourage you to start a project, try to monetize it and also open-source it. The benefits of open sourcing are huge. Take a look at some of blog posts about that:

[0]: https://about.gitlab.com/2016/07/08/7-myths-about-open-sourc...

[1]: https://about.gitlab.com/2016/07/07/trends-version-control-i...

One thing I find strangely lacking (seeing as you bundle it) is notifications from gitlab to mattermost when builds fail or issues/mrs are opened. Apparently I have to run some strange 3rd party application to process webhooks?

Build failures can be sent to Mattermost using our Pipeline webhooks described here: http://docs.gitlab.com/ce/web_hooks/web_hooks.html#pipeline-...

And then the Incoming Webhooks in Mattermost described here: https://docs.mattermost.com/developer/webhooks-incoming.html

Allowing us to create the infrastructure outside of gitlab-ci and setting the reviewapp url/domain etc using the API would be extremely valueable for us, as we are stepping off of the gitlab-ci, but would very much like the UI interface upgrades review apps provides.

We are stepping off of Gitlab CI because of: * Only a single pipeline allowed per repository. We have a monorepo as we have a lot of small artifacts that make no sense to split out to multiple repo's and have to manage using gitsubmodules or having a separate code review process (we use merge requests a lot!) * Gitlab-ci's "stages" and not allowing dependencies on cross-stage is not helpful * No "skipped" status that can be supplied during the pipeline. E.g., we want to ignore changes to our documentation .

Instead we would gladly word with you to make GitLab CI better so you can keep using it.

1. Single pipeline => I understand using a monorepo. But I don't understand yet why you need multiple pipelines. Does the pipeline work different depending on what file is updated?

2. Do you mean cross project pipelines? https://gitlab.com/gitlab-org/gitlab-ee/issues/933

3. Do you mean setting criteria for build skipping in .gitlab-ci.yml ? What would be an example criteria?

Since you are a paying customer feel free to work with our support team to have the features you need prioritized. We want everyone to be able to use GitLab CI.

1. There is only one pipeline allowed at the moment (see issue about support for multiple pipelines: https://gitlab.com/gitlab-org/gitlab-ce/issues/22972), but you can use multiple builds / stages to usually achieve the same. We also plan to add ability to control status using exist code from the build (see https://gitlab.com/gitlab-org/gitlab-ce/issues/25738). You can also use our pipeline trigger API with environment variables to control what get executed.

2. That is true, we already did some backstage work to improve that. In the meantime it is possible to explicitly depend on builds from the previous stages to download all artifacts in subsequent jobs.

3. I'm not sure if I understand correctly, what you want to accomplish, but if `[ci skip]` is not enough, then status based on the exit code may be helpful as well.

Its great to finally see some improvements in the interface, but its still rather far from being as user-friendly as GitHub.

I've got some very specific aspects in mind. Are contributions to Gitlab's interface accepted?

Contributions of any kind are always appreciated. We have a guide about contributing [0] that will help you in the process.

You can also create an issue [1] to let other people participate to your suggestions if you like.

[0]: https://about.gitlab.com/contributing/

[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/new

The main parts I've used in both are creating Issues and Merge Requests, and in GitLab I've accepted them and managed teams/projects.

- On the main project page, the file list/table cells have too much padding. The same project's file list, with 22 files, on GitHub fits on my screen comfortably. On Gitlab, the whole table sits at 928px in height. Reducing the top/bottom padding in cells to 5px, without a loss in usability, yields a much nicer 708px height

- The two panels above the file list (the branch, and the latest commit) could be streamlined and merged

- Frankly, the whole area with the project name and the buttons below is incredibly and unnecessarily convoluted. Some important links are grayed, some others are not relevant for every project (e.g. I don't need a contribution guide for my private project)

- A lot of links are indistinguishable from text

On top of my head I only know f-droid that is there. I use it for personal use and love it, would love if more projects moved away from github.com, especially open source.

[0]: https://gitlab.com/danger-systems/danger.systems

[1]: https://gitlab.com/gnachman/iterm2/issues

[2]: https://gitlab.com/groups/xonotic

[3]: https://code.videolan.org/videolan/VLCKit

[4]: https://git.gnu.io/explore/projects

https://news.ycombinator.com/item?id=11155293

and at the present moment, they are still pretty far from being able to convince notable projects to leave github.com for gitlab.com The biggest issue right now, is there is a measurable difference between gitlab.com and github.com, which is, it's much slower.

GitLab is working on this and I have no doubt this will become a non-issue in the future, but they still have to deal with the fact that you can't compete with being "as good as". Even if gitlab.com becomes as good as github.com, they will still have a difficult time, to convince others to leave github.com for gitlab.com

I guess my point is, since github.com is the incumbent, the only way that gitlab.com can become the next place to collaborate, is they have to make it clear, that they are better than github.com They can't strive for equality, since you can't compete with "as good as".

Otherwise, you can see the most star-ed repos here: https://gitlab.com/explore/projects/starred

(I think more people should consider moving from github to gitlab or bitbucket, but for gods sake avoids googles new git site).

I'm also excited about adding Prometheus monitoring for apps you deploy https://www.youtube.com/watch?v=NFPGtbQfL1A

osm01-03 - OpenShift masters, don't run anything other than OpenShift services (Atomic host)

osn01-03 - OpenShift nodes, actually run the apps (Atomic host)

osnlb - Load balancer for the master (CentOS 7)

oss - NFS server providing storage for OpenShift docker images (CentOS 7)

On your storage node make sure /exports is on a separate filesystem with adequate storage to store your container images, it will be set up automatically from there.

Once you have these couple servers spun up (You can skip the multiple masters + load balancer if you don't care about HA, though I recommend it) from a CentOS box you want to deploy from make sure you push an SSH key out to all the servers for root access then run the following.

    yum install centos-release-openshift-origin 
    yum --enablerepo=centos-openshift-origin-testing install atomic-openshift-utils 
    atomic-openshift-installer install

[1]: https://docs.openshift.com/enterprise/3.0/admin_guide/config...

[2]: https://docs.openshift.com/enterprise/3.0/install_config/ins...

Sorry for the wall of text, I spent two days figuring this out myself - but after a month in production my team is loving OpenShift and we've already deployed three greenfield apps on it. It's getting a lot more love than I ever expected, and I'm already looking at needing to give my node VM's more resources. Feel free to email me at the address in my profile if you have any questions.

GitHub is great, does the job incredibly well, doesn't get in the way and have never been spammed (tip for you gitlab here).

[update] Please don't forget to downvote me for giving honest feedback :-)

Interesting that I get downvoted for giving honest feedback. I would have thought it would help them improve seeing how different marketing ideas impact their users.

My hunch is the "GitHub is great" line, it feels a bit unnecessary and somewhat shill-y.

To share a little background, our marketing automation system does have a limit to the number of emails a person can receive: max of 2 per day; 5 per seven days; and no limit to operational emails. Operational emails are things like a signup confirmation, EE trial license key & initial download instruction.

There are a certain periods of time that have the potential to create a "perfect storm" of emails to be sent/received in short succession.

Example of "perfect storm": If a person signs up for GitLab and download an EE trial the day or two before the bi-weekly newsletter email is sent, they could receive 3 operational emails and 1 marketing email in the first 24 hours.

Please let me know if you have additional questions or if I can explain something more clearly.

I don't understand why this is not max 5 times per month.

The 5 emails per seven day limit is not something we expect to ever utilize but allows for flexibility in our communication strategy.

[email protected] [email protected] [email protected]

All marketing their features and help to get started. Like I said nothing wrong with sending this kind of email just over a certain period in moderation.

Everything in life is relative isn't it :-)

The other features are awesome, but this is the one that will get us to upgrade right now! We use dozens of repositories, and it's been a pain to manually configure and update hooks.

The gitlab came on the scene, shipped a Github replacement and then some. Is shipping features in 6 months faster than Github did over the past few years.

Github have woken up though and started shipping features again.

It's good to have competition. At least, for consumers.

For reference, i'm running gitlab-ce on a 2 core 2gb vm with 8gb disk and except for one out of memory error about 6 months ago it has been running great for a single user. For more serious use i'd give it way more resources, but for personal use it's humming along perfectly.

2GB for a single user should be enough. To prevent the out of memory error since using the Omnibus package and configuring 1 or 2GB of swap space if you haven't done so already.

As mentioned in the blog post, this release we decreased page size a lot (from 1800kb to 718kb for a given Merge Request).

We're also working on moving to our own infrastructure, the reasoning behind that move is described here: https://about.gitlab.com/2016/11/10/why-choose-bare-metal/

EDIT: Strike that, we've decided against moving to bare metal for now due to the complexity. I somehow missed that decision.

https://gitlab.com/gitlab-com/infrastructure/issues/727#note...

I, personally, was apprehensive of going to bare metal for most of the reasons that Sid lists in the above message, and I think that making the app just _better_ is where we should focus before we try and run to pure hardware to solve the problem.

So as strange as it sounds, are you happy with people like me moving to GitLab even though it may compound your performance problems?

And over time we'll start monetizing it more, see https://about.gitlab.com/gitlab-com/#free-forever for more information.

And if I can just say, the more actual services you add to your system (as opposed to SaaS features), the more likely I am to become a paying customer. For me, I really value free software. I'm not so interested in paying for proprietary SaaS features, and receiving free services. I'd much, much rather pay for services and use free software.

Whether you can build a business around customers like me, I don't know, but I just wanted to make sure that you know there are at least some of us out there.

What spec hardware are you running this on?

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues