On Wed, May 01, 2024 at 23:26:18 +0200, Mark Wielaard wrote:
> On Wed, May 01, 2024 at 04:04:37PM -0400, Jason Merrill wrote:
> > Do you (or others) have any thoughts about GitLab FOSS?
>
> The gitlab "community edition" still feels not very much "community".
> We could run our own instance, but it will still be "open core" with
> features missing to try to draw you towards the proprietary hosted
> saas version. Also it seems to have way too much overhead. The focus
> is clearly corporate developers where managers want assurances the
> mandatory "pipelines" are executed and "workflows" followed exactly.
I'll offer my experience here. We (at Kitware) have been using GitLab
FOSS for around 8 years. We can't use the other editions because of the
per-account pricing and having open registration (since pretty much
everything there is FOSS code). GitLab is receptive to patches sent
their way and have considered moving things to the FOSS edition to help
large FOSS organizations (freedesktop.org, GNOME, KDE, probably others
too). There's also been discussion of implementing features such as
commit message review in order to court Linux developers given
forge-like discussion happening there. FWIW, Fedora is also looking at
forges as well:
https://discussion.fedoraproject.org/t/2024-git-forge-evaluation/111795
That said, there are definitely gaps to fill. We have our tooling here:
https://gitlab.kitware.com/utils/rust-ghostflow (core actions)
https://gitlab.kitware.com/utils/ghostflow-director (service deployment)
We use it to implement things including:
- Basic content checks (scripts are executable, no binaries, file size
limits, formatting, etc.) either on a commit-by-commit basis or by
looking at the MR (patch series, PR, whatever the forge calls it) as
a whole. Docs for currently-implemented checks are here:
https://gitlab.kitware.com/utils/rust-ghostflow/-/blob/master/ghostflow-cli/doc/checks.md
- Reformatting upon request; if the formatter(s) in use supports
writing the content as intended, there is code to rewrite each
individual patch to conform. This avoids wasting time on either side
for things that can be done automatically (of course, you're also at
the mercy of what the formatter wants…I find it worth it on balance).
- More advanced merging including gathering trailers for the merge
commit message from comments and other metadata including
`Reviewed-by` and `Tested-by` (also from CI). Also supported is
merging into multiple branches at once (e.g., backports to older
branches with a single MR).
- Merge train support (we call it the "stage"); this feature is
otherwise locked behind for-pay editions of GitLab.
Right now, GitLab and Github are supported, but other forges can be
supported as well. In addition to the service (which is triggered by
webhook delivery), there's a command line tool for local usage (though
it only implements checking and reformatting at the moment mainly due to
a lack of available time to work on it).
There are other things that are probably of interest to supply chain or
other things such as:
- every push is stored in a ghostflow-director-side unique ref
(`refs/mr/ID/heads/N` where `N` is an incrementing integer) to avoid
forge-side garbage collection (especially problematic on Github;
I've not noticed GitLab collecting so eagerly)
- all webhooks are delivered via filesystem and can be archived
(`webhook-listen` is the program that listens and delivers them:
https://gitlab.kitware.com/utils/webhook-listen); events which
trigger failures are stored with some context about what happened;
those that are ignored are stored with a reason for the ignore (see
this crate for the "event loop" of `ghostflow-director` itself:
https://gitlab.kitware.com/utils/rust-json-job-dispatch)
- the forge is the source of truth; if a ref is force-pushed,
`ghostflow` will accept the state on the forge as gospel instead;
the only non-logging/historical tracking state off-forge includes:
- the config file
- formatter installation (formatting is designed to only use trusted
binaries; nothing from the repo itself other than which to use)
On the first two points, we had some data loss on our instance once and
using the webhook history and stored refs, I was able to restore code
pushed to projects and "replay" comments that happened since the last
backup (I copied the content and @mentioned the original author).
> At the moment though the only thing people seem to agree on is that
> any system will be based on git. So the plan for now is to first setup
> a larger git(olite) system so that every contributor (also those who
> don't currently have commit access) can easily "post" their git
> repo. This can then hopefully integrate with the systems we already
> have setup (triggering builder CI, flag/match with patchwork/emails,
> etc.) or any future "pull request" l
