CI talk (Was: re: Manner in which kde-gtk-config development is conducted)

[Johan Ouwerkerk]

On Sun, Mar 22, 2020 at 3:20 AM Ben Cooksley <bcooksley at kde.org> wrote:
>
> We already do have a repository of artifacts :)
> You can find the public view of this at
> https://build-artifacts.kde.org/production/
>

>
> We already use Virtual Machines for both FreeBSD and Windows.
>
> The main problem here is that there is no way of dynamically
> provisioning full VMs without building an entire Openstack type
> system, which is just too much overhead for the number of builders we
> have.
>

First of all, thanks for your patience in explaining to me what must
be obvious to you. I really appreciate it.

>
> Shouldn't this kind of experimentation be done on developers systems
> rather than the CI system?
> Please do remember that CI resources are not infinite and at times can
> be quite constrained.
>
> My main query here though is what would be achieved by allowing this
> sort of thing that the existing system does not allow for?
> (Ignoring the fact we don't cover feature branches - something which
> is in the long term pipeline)
>

Pure experimentation should definitely be done on developers' systems.
But changes to your CI cannot be fully validated on your own machine
beforehand: you need to verify that it works on the actual CI
builders. Ideally without breaking the CI for anyone else.

So the main gain here is that projects can improve, evaluate and
mature their CI efforts independently. Examples of things we currently
don't have but some projects might benefit from are: licensing
compliance checking (reuse), dependency scanning (e.g.: snyk) and
mutation testing (e.g.: stryker).

I'm not saying that this couldn't be achieved today with a lot of help
and guidance from the sysadmins. But I think this does impose a lot of
overhead, especially while such changes are still experimental and do
not fully work yet in CI or need tweaking for prettier output or
whatever. In fact, your reply to my other question kind of indicates
as much:

> >
> > Possibly projects would also submit custom images for consideration to
> > that registry.
>
> This isn't something that is terribly easy to do within our existing
> Jenkins setup - but is theoretically possible. It requires quite a bit
> of provisioning work on the Jenkins side.
>
> The CI scripts would also need some adapting to make this sort of
> setup efficient to operate with them if you were to use them (and you
> probably do want to use them for running tests).
> A good portion of this adapting will done as part of moving the CI
> system to Gitlab.

Does this mean that we will be encouraged to configure `image`
settings in .gitlab-ci.yml? If so, that basically gives me what I
really wanted here. All the actual images I might ever need could be
submitted for review via MR to a repository on invent as and when I
would need them.

>
> Note however that images based upon Fedora or anything that shares
> it's lineage (including CentOS and it's derivates) is strictly
> prohibited and won't be accepted for inclusion.
>

Personally I'm more inclined towards using Debian myself, but out of
interest what is the reason for banning Fedora and CentOS images? Does
this still apply when the move to Gitlab CI is completed?

Regards,

- Johan