Draft for mail about ci

[L. E. Segovia]

Hi all,

Based on the previous emails, it seems a key item wasn't covered:

6) Local builds with 3rdparty deps (replica CI environment)

     * uses our custom deps built from 3rdparty folder
     * can be rebuilt locally

Now, I'm totally unfamiliar with Craft's rationale and how it works, so
I have three questions coming from my own experience tinkering with
3rdparty.

- Ben had told me, if I'm not mistaken, about make DESTDIR being the
workhorse of Craft. I know that CMake may disallow it it in Windows:
https://cmake.org/cmake/help/latest/envvar/DESTDIR.html. So, does Craft
work with Windows dependencies, whether MSVC or Clang?

- Does KDE sysadmin allow external retrieval of the packages for a
developer environment? If so, what's the procedure to recreate it using
Craft?

- Does Craft require a certain directory layout? In other words, does it
support relocatable dependencies outside of Unix-based operating systems?

Best,

amyspark

On 09/03/2023 14:35, Ingo Klöcker wrote:
> On Donnerstag, 9. März 2023 17:52:20 CET Dmitry Kazakov wrote:
>> I think the problem is not in the specific tool we use (it is possible to
>> implement with any build system, including the upcoming GitLab). The
>> problem is that we need quite an extensive build matrix, and we are
>> wondering if KDE can actually host all that? We heard multiple times from
>> sysadmins that build times and build variety might be a problem.
> 
> The main problem is rebuilding things again and again that don't need 
> rebuilding. That's where Craft's cache can help.
> 
>> Ideally, what we need is something like that:
>>
>> 1) CI builds:
>>     * uses our custom deps built from 3rdparty folder
> 
> If you move the 3rdparty folder to a separate repo, then you'd get automatic 
> rebuilds of the dependencies for free. Of course, you will lose the baked-in 
> coupling to 3rdparty. Using Craft's blue print approach may be even better.
> 
>>     * builds unittests and static analyser
>>     * built for every (bunch of) commit(s)
>>     * built for linux (and, optionally, windows, osx, android)
> 
> Check (for GitLab CI).
> 
>> 2) MR builds: same as CI builds but
>>     * builds an AppImage or a prebuilt docker image for testers
>>     * built for each MR
> 
> Check.
> 
>> 3) Nightly builds:
>>     * uses our custom deps built from 3rdparty folder
>>     * builds packages for linux, windows, osx, android
>>     * builds nightly
> 
> Builds with a fixed schedule are a bit of the problem because they may not be 
> necessary if nothing changed in the last 24 hours. That may not be an issue 
> for an actively developed application like Krita. In any case, GitLab supports 
> scheduled builds even if we don't use them currently as far as I know.
> 
>> 4) Release builds:
>>     * uses our custom deps built from 3rdparty folder
>>     * builds packages for linux, windows, osx, android
>>     * builds on request
> 
> That's what manual GitLab jobs give us.
> 
>> 5) Distribution builds (just to make sure distributions can build Krita in
>> some (probably, unsupported) way)
>>     * uses dependencies from the distributions
>>     * some currently missing dependencies should be built somehow manually
>> or installed from a custom repository
>>     * builds unittests and static analyser
>>     * builds nightly
>>     * built for linux and freebds(?)
> 
> For some of this you might want to look into using the openSUSE Build Service. 
> Despite the name it allows building packages for many distributions. This 
> could be less work than maintaining your own set of Docker images for building 
> Krita for the different distributions.
> 
>> Technically, it is possible to implement such layout within the feature set
>> of GitLab. Though I'm not sure how many resources it would require.
> 
> If 3rdparty isn't rebuilt more often then necessary, then I'm sure GitLab will 
> manage this. It survived many frameworks releases and Gear releases.
> 
> Regards,
> Ingo

-- 
amyspark 🌸 https://www.amyspark.me