aconadi-contacts dependeny on kmime on Windows

[Volker Krause]

On Thursday, 6 August 2020 20:14:08 CEST Ben Cooksley wrote:
> On Fri, Aug 7, 2020 at 2:38 AM Volker Krause <vkrause at kde.org> wrote:
> > On Wednesday, 5 August 2020 10:36:27 CEST Christoph Feck wrote:
> > > Hello PIM developers,
> > > 
> > > I see akonadi-contacts regularily failing on CI, because the version of
> > > KMime doesn't match, see
> > > https://build.kde.org/job/Applications/view/Everything%20-%20stable-kf5-> > > qt5/ job/akonadi-contacts/job/stable-kf5-qt5%20WindowsMSVCQt5.14/
> > > 
> > > Could someone please check the build metadata for akonadi-contacts?
> > 
> > This looks more complicated than just a missing dependency info if I read
> > the logs correctly:
> > - KMime is retrieved as a dependency (ie. build metadata should be
> > correct). - There is no Windows CI build for KMime!? That makes it hard
> > to check which version was actually built, or where KMime comes from at
> > all here.
> It is perfectly fine for a project to depend on a project that no job
> exists for.
> 
> This scenario is covered by the Dependency Build jobs, which build
> every project that the jobs in a given Product need.
> This is how Frameworks are provided to the
> Plasma/Applications/Extragear jobs (as they don't rely on the
> Frameworks jobs, they're separate)
> 
> > - Looking at past CI state, it alternates between working and the KMime
> > being too old error every few builds. It breaks when the dependency
> > version is bumped, but then gets back to working without any code change.
> 
> The Dependency Build jobs run once a week, which would explain this -
> it breaks when it bumps, then after a few days the Dependency Build
> comes through and updates KMime, after which the next build of
> akonadi-contacts succeeds.

I see, that explains the status quo. It still seems useful to have a CI build 
for KMime too, given we expect it to work, so better catch issues early: 
https://invent.kde.org/sysadmin/ci-tooling/-/merge_requests/84

Regards,
Volker