Gitlab CI - Inbound

[Ben Cooksley]

On Tue, Sep 7, 2021 at 6:20 AM Johnny Jazeix <jazeix at gmail.com> wrote:

> Hi Ben,
> not sure on which priority it is regarding the KDE Frameworks but I've
> added one on GCompris (
> https://invent.kde.org/education/gcompris/-/commit/67c9839d7970b360b5d6b0ec928b492f9003d07d)
> if it can help on more tests.
>

Thanks for getting that landed Johnny.

Please note that you've specified no dependencies, so your builds won't
even have ECM available so you may wish to fix that.


> Cheers,
>
> Johnny
>

Cheers,
Ben


> Le dim. 5 sept. 2021 à 12:11, Ben Cooksley <bcooksley at kde.org> a écrit :
>
>> On Sun, Sep 5, 2021 at 6:13 PM Ben Cooksley <bcooksley at kde.org> wrote:
>>
>>> Hi all,
>>>
>>
>> Hi all,
>>
>>
>>> This morning after much work i'm happy to announce that the new
>>> generation CI scripts intended for use with Gitlab CI successfully
>>> completed their first build (of ECM, and then subsequently of KCoreAddons).
>>>
>>> This begins our first steps towards transferring CI over from Jenkins to
>>> Gitlab.
>>>
>>> These scripts are 'Gitlab native' and are designed to work in an
>>> environment where they will be running on merge requests, tags as well as
>>> all branches of our repositories - something the existing scripts were
>>> completely incompatible with. While there are still some infrastructural
>>> elements to put in place (such as 'seed jobs' to mass rebuild all projects
>>> after substantial changes and 'cleanup jobs' to remove old builds from the
>>> Package Registry) the core elements needed for initial testing of these
>>> scripts are now ready.
>>>
>>
>> As an update, an initial version of the seed job tooling is now ready,
>> however testing that tooling requires that dependency information be
>> available.
>> This requires that the .kde-ci.yml files be populated in repositories.
>>
>> It would be appreciated if people could please work on getting these
>> files populated in Frameworks (as everyone needs those) as well as in their
>> own repositories as they are required before we can proceed much further.
>>
>>
>>> For those curious, the results of those initials runs can be found at
>>> https://invent.kde.org/groups/teams/ci-artifacts/-/packages
>>>
>>> Due to the challenges associated with having to handle all of the
>>> different forms of build and the versioning of this information, these
>>> scripts also represent a radical change in how CI builds will be conducted
>>> - with a large part of the configuration of the jobs themselves, including
>>> information on project dependencies now shifting to files located within
>>> the repository themselves. Those who monitor commits to Frameworks
>>> repositories will have noticed the appearance of these '.kde-ci.yml' files
>>> in some repositories.
>>>
>>> To assist in the future rollout of the CI system it would be appreciated
>>> if projects could please begin setting up these files within their
>>> respective repositories.
>>> You can find a template detailing the available options at
>>> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml
>>>
>>> Where possible please avoid overriding the system defaults except where
>>> needed by your project (ie. don't just copy the template in full)
>>> The defaults mirror the template and can be found at
>>> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml
>>>
>>> In terms of the format of the 'Dependencies' section, please bear in
>>> mind the following:
>>> - For the 'on' section, the special value '@all' can be used to mean
>>> "All platforms" to avoid needing to update the file in the event additional
>>> platforms are added in the future
>>> - For the 'require' section:
>>>   1) Please only include the projects you *explicitly* depend on.
>>> Dependencies of your dependencies will be included automatically
>>>   2) When specifying a project, you must use the repository path on
>>> Gitlab. Legacy project paths (such as kde/workspace/plasma-desktop) are no
>>> longer in use and will not work.
>>>   3) There are three special values for the branch name - '@same',
>>> '@latest' and '@stable' which can be used to refer to the branch/tag of a
>>> dependency.
>>>       '@same' means the branch name should be the same as that of the
>>> project being built and should be used when declaring dependencies among
>>> projects in a release group.
>>>       '@latest' and '@stable' refer to the corresponding branches
>>> defined in the branch-rules.yml file, which can be found in
>>> sysadmin/repo-metadata
>>>
>>> As a general rule, unless you require the absolute latest version of
>>> another project in another release unit, it is recommended that you use
>>> @stable.
>>> Please avoid using explicit branch names unless absolutely necessary.
>>>
>>> At this time it is expected that the first set of Gitlab CI builds using
>>> the new scripts may be conducted for Frameworks within the next week or so,
>>> assuming the build of the seed jobs goes according to plan.
>>>
>>> Once the scripts have been proven successfully for Frameworks, we will
>>> look at extending them to projects that depend only on Frameworks and
>>> repositories within their release unit and finally will extend them to
>>> projects with more complex dependency requirements. It is expected that the
>>> switch will be flipped on the Frameworks builds sometime in the next week
>>> or two.
>>>
>>> Please let me know if you have any questions on the above.
>>>
>>> Thanks,
>>> Ben Cooksley
>>> KDE Sysadmin
>>>
>>
>> Thanks,
>> Ben
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20210907/6fd16c36/attachment.htm>