Gitlab CI - Inbound
bcooksley at kde.org
Tue Sep 7 09:03:11 BST 2021
On Tue, Sep 7, 2021 at 1:04 AM Tom Zander <tom at flowee.org> wrote:
> 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.
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).
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kde-core-devel