Gitlab CI - Inbound

[Tom Zander]

On maandag 6 september 2021 11:48:39 CEST Ben Cooksley wrote:
> > Pushing everything into required is likely not scalable,
> > causing projects too wait too long for compile.
> > Avoiding the optional ones means you lack coverage of compile
> > and testing failures due to changes in libs.
> 
> The CI system has reused the results of previous builds of
> dependencies since the very first generation of the system

We seem to be talking about two slightly different topics.

When the (for instance) KIO repo changes, then the CI will 
obviously rebuild that repo and will pull in all the things that 
kio depends on.

What many CIs do is additionally trigger rebuilds of projects 
that _use_ KIO, by them marking kio as a required dependency.

Imagine a small extragear app that uses some KIO stuff and it has 
some unit tests that would break as a result of the KIO change.
When the KDE CI triggers a rebuild of projects that mark KIO as a 
required dependency, this little app would show its breaking as a 
result of the KIO push. Helping the KIO dev to realize the 
fallout as well.
Without such a feature the app would show breakage at a random 
time in the future after a new push was made in that repo. Losing 
lots of dev time and compromising quality.

Now, the optional requirements would help diminish the effect of 
changes in frameworks paralysing the build system by limiting the 
apps that gets scheduled for a rebuild.

This kind of functionality becomes pretty easy to add to gen5.1 
of the CI, provided that at this time the dependencies are 
already split since doing it later is going to be an uphill 
battle.