Use gitlab-git-http-server in installations from source

If all goes well with the soft-launch of https://gitlab.com/gitlab-org/gitlab-git-http-server (it will be in the omnibus packages but off by default) we should launch it properly in GitLab 8.0.

This means we need to:

• turn on gitlab-git-http-server in the omnibus packages by default !1229 (merged)
• remove the GITLAB_GRACK_AUTH_ONLY environment variable !1229 (merged)
• update the installation and update guides with instructions for downloading and compiling gitlab-git-http-server (which needs a golang compiler!!) !1229 (merged)
• update the GitLab init script to also manage gitlab-git-http-server omnibus-gitlab!450 (merged)
• ... ?

@JobV milestone 8.0?

@jacobvosmaer I assume you will do it? Then 8.0 is fine :)

Milestone changed to 8.0

update the installation and update guides with instructions for downloading and compiling gitlab-git-http-server (which needs a golang compiler!!)

I'm no go expert, but can't we just ship the binaries?

@axil we can ship binaries only if we are also hosting them. I.e. setting up a parallel release process for the gitlab-git-http-server binaries, just for people installing GitLab from source. I am not sure if that is something we want to spend time on. cc @sytses

@jacobvosmaer For now I'm fine with having instructions in the source install for both:

1. how to compile from source
2. how to not use gitlab-git-http-server at all

@jacobvosmaer The binary shipping is available in gitlab-ci-multi-runner. I think that the release process can be copied from there.

2 how to not use gitlab-git-http-server at all

@sytses I thought we wanted to remove this option. If we really want to keep gitlab-grack around we could, it would just make the 'trial' solution in 7.14 permanent.

@ayufan thanks for the tip, I suspected as much. I have not looked at in detail to understand how much more/less work it is (for the GitLab maintainers) compared to documenting how to compile and install a Go compiler (which is not so hard).

So we can do:

• 1 Keep gitlab-grack around, and have some installations using gitlab-git-http-server, some gitlab-grack
• 2 Force everybody to use gitlab-git-http-server and let installations from source compile it themselves (minimal effort for us)
• 3 Force everybody to use gitlab-git-http-server and make it easier for installations from source

cc @dzaporozhets

@jacobvosmaer Only 2 or 3. NO way we have 2 different git-over-http servers

Lets do 2 and see how much people still use the installation from source but object to compiling from source.

I added some text about the soft-launch of gitlab-git-http-server to the 7.14 blog post in gitlab-com/www-gitlab-com@cb2cc87aff5f377539498e2aa7c47e6c0ffd3039

Reassigned to @jacobvosmaer

MR: !1229 (merged)

omnibus MR to enable by default: omnibus-gitlab!450 (merged)

Why not create rpm/deb for gitlab-git-http-server, same way as you do with ci-runner?

@sashk see above.

@jacobvosmaer can you update this issue?

I think this is done.

Status changed to closed

mentioned in merge request !14785