Why can't invent's CI build eventview's release branch?

Ben Cooksley bcooksley at kde.org
Sat Sep 4 21:16:08 BST 2021


On Sun, Sep 5, 2021 at 7:13 AM Friedrich W. H. Kossebau <kossebau at kde.org>
wrote:

> Am Samstag, 4. September 2021, 18:59:19 CEST schrieb Glen Ditchfield:
> > Eventview's release/21.08 branch builds successfully in Jenkins
> > (https://build.kde.org/job/Applications/job/eventviews/), but not
> > in invent.kde.org.  The most recent attempt at the moment is
> > https://invent.kde.org/pim/eventviews/-/jobs/128298
> > which fails during compilation:  one error message is `expected class
> > name`.  It seems to be objecting to `CalendarSupport::PluginFactory`,
> > which puzzles me, because calendarsupport's release/21.08 plugin.h does
> > declare `PluginFactory`.
> >
> > Could invent be using a broken version of calendarsupport?
>
> Given this is the build of eventview stable/release branch, those items in
> the
> cmake log are suspicious:
> "
>  * KF5PimTextEdit (required version >= 5.18.40)
>  * KF5IdentityManagement (required version >= 5.18.40)
> "
> which are indirect dependencies, so something wants the latest development
> version here.
>

Looking at the .gitlab-ci.yml file, I see BRANCH_GROUP=kf5-qt5 which is the
current development(master) branch group.
Therefore what you are seeing here is expected behaviour.


>
> I suspect that KDE Gitlab is currently not really configured to support
> both
> main/development and stable/release build setups for the pipelines, so it
> might be unclear what is in the build cache and from which branch.
> (beware, me
> no clue about gitlab CI things)
>
> AFAIK KDE's gitlab CI is currently still in experimental state and so far
> was
> only targetting KDE Frameworks for test runs, the gitlab CI config files
> added
> for PIM products was not yet done in collabiration with sysadmin, was it?
>

This was all done by Montel using some of the CI demo stuff that had been
done for other repositories.
I can confirm that Gitlab CI is experimental and not intended for
production use at this stage.


> Guess we should ask sysadmin to tweak off time to do an official update
> where
> we are, so we are not in the dark as we seem to be now (and could help to
> go
> to the light).
>
> So, dear sysadmin :), could you please do a short status update e.g. to
> the
> community ML, to tell where we are, where things are tracked and who could
> help with what to progress here?
>

We are getting fairly close now - the vast majority of the code for it is
now ready with just one piece left to complete.
Then we should be able to start a slow incremental rollout which will start
with Frameworks (subject to initial testing completing okay)

Plasma will likely be the last to be supported by the new system because
they require Frameworks master while also depending on a couple of Release
Service items that will generally be expected to depend on Frameworks
stable, and i'm not yet sure on how best to resolve that.

Looking at PIM's dependency chain, as long as KDiagram has the same set of
dependencies you shouldn't have an issue there (as all of your other
dependencies are within your release unit, or on Frameworks).
Should you opt to require Frameworks master, then you would be faced with a
similar issue due to Akonadi's dependency on kaccounts-integration.


>
> Cheers
> Friedrich
>

Regards,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20210905/8a1ffdc6/attachment.htm>


More information about the kde-pim mailing list