Fwd: Re: About Trac to GitLab migration

[Sajith Sasidharan]

I asked some questions about CI setup and wiki.  Below are Ben's answers.

Preserving Trac issue numbers has been a concern for haskell.org.  I am not
sure if it is a concern for Tahoe-LAFS.  I am also not sure if preserving
usernames is a concern.

Since haskell.org has a self-hosted GitLab, they have to also manage their own
CI runners.  I think we can experiment with gitlab.com' shared CI runners and
see how things work.  There's no shared CI runners for macOS on gitlab.com at 
present, but that seems to be in the works.

Regards,
Sajith.

-------- Forwarded Message --------
From: Ben Gamari
To: Sajith Sasidharan
Cc: Daniel Stone
Subject: Re: About Trac to GitLab migration
Date: Wed, 22 Jul 2020 23:09:30 -0400

Sajith Sasidharan <sajith at hcoop.net> writes:

> Hi Ben,
> 
> On Wed, 2020-07-22 at 19:26 -0400, Ben Gamari wrote:
> 
> > Anyways, I hope this helps! I would be happy to chat if you have any
> > specific questions.
> 
> Thank you very much!  What you wrote is very helpful.  The GHC blog post did
> not turn up in my search results.  Glad that I asked: I got more this way.
> :)
> 
Sure, not a problem.

> We have been talking to GitLab about their open source program.  I don't
> believe we can (or should!) spare the resources for self-hosting GitLab.
> 
> It sounds like we won't be able to preserve issue numbers if we're to move
> straight to gitlab.com, but I don't know how important of an issue this
> would
> be for us.  Tahoe-LAFS wiki is rather modest in comparison to GHC wiki, so
> the
> manual intervention also must be modest.
> 
> I actually have some more questions:
> 
> Have you been able to update your patched GitLab installation to a
> "standard"
> GitHub release later?
> 
Yes, at this point we run a mostly un-patched instance. The only patches
which we do have are small changes to the subject line format of
notification email.

> What is the setup like for macOS and Windows CI runners?
> 
Indeed this is perhaps my least favorite part of the CI story. On
Linux we can use gitlab-runner's docker executor, which allows nicely
hermetic, mostly-reproducible builds. However, on Windows and Darwin we
need to use the shell executor, which loses these properties. Moreover,
gitlab-runner makes no attempt to the working directories of old builds
(see [1]). Consequently, one must arrange for some other means of
cleaning up these directories lest the runners run out of disk space.
We have a Python script which is regularly run on all of our Windows and
Darwin runners [2] to tae care of this.

See [3] for more details on our CI configuration.

> I am guessing that you must have considered making a Pandoc reader for Trac
> wiki markup before writing a custom tool -- is that a viable approach?
> 
This was an option (and it wouldn't be hard to turn the parser from our
converter into a Pandoc reader) but we didn't see what value Pandoc
would offer. Afterall, the hard part is writing the parser (Trac markup
syntax is remarkably liberal in what it accepts, unfortunately);
producing the Markdown is quite straightforward. Pandoc would have only
helped with the latter.

> May I share our communication with tahoe-dev mailing list?  It is a low
> traffic public list (currently a little broken too, perhaps), with a public
> list archive.
> 
Of course. Feel free.

Cheers,

- Ben


[1] https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3856
[2] https://gitlab.haskell.org/ghc/ci-config/-/blob/master/cleanup.py
[3] https://gitlab.haskell.org/ghc/ci-config