Gitlab CI - Inbound
Christoph Cullmann (cullmann.io)
christoph at cullmann.io
Mon Sep 6 13:21:00 BST 2021
On 2021-09-06 11:48, Ben Cooksley wrote:
> On Mon, Sep 6, 2021 at 9:00 PM Tom Zander <tom at flowee.org> wrote:
>
>> On zondag 5 september 2021 08:13:09 CEST Ben Cooksley wrote:
>>> In terms of the format of the 'Dependencies' section,
>>
>> Playing with kde-build script and noticing the fast growing
>> dependency trees we have today, I think it may be beneficial to
>> have two types of compile dependencies in this setup.
>>
>> 1. required-to-build.
>> Which means that if something in the parent tree changes, this
>> one is scheduled for re-build.
>>
>> 2. optional. Equivalent of the cmake feature, if its not there
>> some code is not compiled.
>> At least once before a release the full dependencies can be
>> compiled to see if it fully compiles.
>
> From the perspective of the CI system there is basically no difference
> in terms of making a dependency available or not as all dependencies
> are always satisfied using previously built binaries.
> If a dependency is not available your build fails.
>
> We also have to make a hard choice - we either bring in optional
> dependencies or we don't.
>
> If we were to randomise whether we brought them in - or just brought
> them in at certain times - then we would make the system state
> deterministic. This could in some cases cause builds to break if it
> was random whether or not we included optional dependencies. This
> would occur if the dependency of a dependency of a project were
> rebuilt without an optional dependency being present which in turn
> caused it's API interface to change. That would then cause the project
> to fail as the dependency would now be broken.
>
>> 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 (this would
> be generation 5) so this is not a problem facing the CI system.
> For individual developers, my understanding is that kdesrc-build makes
> use of incremental builds which eliminates most of the issue as well.
>
>> What do people think, is it useful to have an 'optional' category
>> in future there?
>> Maybe useful to think that far ahead now people are populating
>> their dependencies :-)
Hi,
I would prefer to not have some optional category to be sure
the CI always builds with the same state of dependencies, too.
Greetings
Christoph
--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org
More information about the Kde-frameworks-devel
mailing list