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

[Ben Cooksley]

On Mon, Mar 23, 2020 at 12:41 AM Johan Ouwerkerk <jm.ouwerkerk at gmail.com> wrote:
>
> 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).
>

Sounds reasonable enough.

My main concern here is people trying to replicate builds under their
$distroOfChoice which doesn't really add value to the system but which
does increase resource consumption.

> 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.

I would prefer if we could avoid the proliferation of too many images
if at all possible, however there may be scope for this where they
don't overlap functionality wise with our existing images (a different
Qt version does not overlap, but providing builds using a different
distribution for a version of Qt already covered definitely would
overlap)

>
> >
> > 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?

I've detailed this ban in my response to Albert.
The ban applies to all parts of our infrastructure, including Gitlab,
and is indefinite in duration.

Images based upon Debian, Ubuntu and SUSE are perfectly acceptable.

>
> Regards,
>
> - Johan

Cheers,
Ben