<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 7, 2021 at 1:04 AM Tom Zander <<a href="mailto:tom@flowee.org">tom@flowee.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On maandag 6 september 2021 11:48:39 CEST Ben Cooksley wrote:<br>
> > Pushing everything into required is likely not scalable,<br>
> > causing projects too wait too long for compile.<br>
> > Avoiding the optional ones means you lack coverage of compile<br>
> > and testing failures due to changes in libs.<br>
> <br>
> The CI system has reused the results of previous builds of<br>
> dependencies since the very first generation of the system<br>
<br>
We seem to be talking about two slightly different topics.<br>
<br>
When the (for instance) KIO repo changes, then the CI will <br>
obviously rebuild that repo and will pull in all the things that <br>
kio depends on.<br>
<br>
What many CIs do is additionally trigger rebuilds of projects <br>
that _use_ KIO, by them marking kio as a required dependency.<br></blockquote><div><br></div><div>Our CI system has never done this, in part due to difficulties in communicating this to Jenkins and also because of the build storm it would create (which I believe is what you are referring to).</div><div>If we were to limit it to select projects, then we would need to 'pick' those projects which would raise questions of favouritism which I'd rather avoid.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Imagine a small extragear app that uses some KIO stuff and it has <br>
some unit tests that would break as a result of the KIO change.<br>
When the KDE CI triggers a rebuild of projects that mark KIO as a <br>
required dependency, this little app would show its breaking as a <br>
result of the KIO push. Helping the KIO dev to realize the <br>
fallout as well.<br>
Without such a feature the app would show breakage at a random <br>
time in the future after a new push was made in that repo. Losing <br>
lots of dev time and compromising quality.<br>
<br>
Now, the optional requirements would help diminish the effect of <br>
changes in frameworks paralysing the build system by limiting the <br>
apps that gets scheduled for a rebuild. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
This kind of functionality becomes pretty easy to add to gen5.1 <br>
of the CI, provided that at this time the dependencies are <br>
already split since doing it later is going to be an uphill <br>
battle.<br></blockquote><div><br></div><div>Cheers,</div><div>Ben<br></div></div></div>