Re: request for votes for continuous integration system

[Toon Claes <toon@iotcl.com>]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Meanwhile, gitlab.com has issues mirroring the Emacs repository, but
> they said that's a system-wide issue, and they host many thousands of
> repositories. So I don't think that will be an issue with a dedicated
> private installation, but I'm bringing it up in the interest of full
> disclosure: https://gitlab.com/emacs-ci/emacs/issues/3
>
> Unless there are objections, I ask (again) for a machine to host a
> GitLab installation. I can help set it up, but it has to be allocated
> like the GNU ELPA server, internally. Once it's up and running, we can
> set it up and start doing CI against all emacs.git commits.

Before you start setting up emacs's private GitLab instance for CI, I
should explain something.

GitLab is built in 2 flavours, CE and EE:
- GitLab CE is Free Software, and licensed under MIT Expat License.
- GitLab EE is built on top of GitLab CE, it includes extra features
  that are destined for enterprise users. GitLab EE has a proprietary
  license. https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE

The feature to mirror a repo, from Savannah to GitLab, is an EE
feature. So you cannot use that feature without a subscription.
(see https://about.gitlab.com/products/).

So to use GitLab CI, there are a few options:

- Set up a private GitLab EE instance with a paid subscription
  => I doubt GNU/FSF would agree with this

- Set up a private GitLab CE instance and build some custom scripts to
  /manually/ sync the repo from Savannah to GitLab.

- Keep using GitLab.com (the SaaS solution GitLab provides, which is
  running GitLab EE).

- Instead of the savannah repo, use the GitLab repo as the main one.
  => I don't see this happen in the near future.


-- Toon