[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Gitlab CI - Inbound
From: Ben Cooksley <bcooksley () kde ! org>
Date: 2021-09-07 8:04:20
Message-ID: CA+XidOGvW3kVm203G9-d2LXOgT0s-h6=7hsa4BZvYBivDbP-9Q () mail ! gmail ! com
[Download RAW message or body]
On Tue, Sep 7, 2021 at 6:20 AM Johnny Jazeix <jazeix@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/67c9839d7970b360b5d6b0=
ec928b492f9003d07d)
> 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 =C3=A0 12:11, Ben Cooksley <bcooksley@kde.org> a =C3=
=A9crit :
>
>> On Sun, Sep 5, 2021 at 6:13 PM Ben Cooksley <bcooksley@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 KCoreAddo=
ns).
>>>
>>> This begins our first steps towards transferring CI over from Jenkins t=
o
>>> 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 infrastructura=
l
>>> elements to put in place (such as 'seed jobs' to mass rebuild all proje=
cts
>>> 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 th=
eir
>> 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 conduc=
ted
>>> - with a large part of the configuration of the jobs themselves, includ=
ing
>>> information on project dependencies now shifting to files located withi=
n
>>> the repository themselves. Those who monitor commits to Frameworks
>>> repositories will have noticed the appearance of these '.kde-ci.yml' fi=
les
>>> in some repositories.
>>>
>>> To assist in the future rollout of the CI system it would be appreciate=
d
>>> 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 additi=
onal
>>> 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 amon=
g
>>> 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 usin=
g
>>> 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 we=
ek
>>> or two.
>>>
>>> Please let me know if you have any questions on the above.
>>>
>>> Thanks,
>>> Ben Cooksley
>>> KDE Sysadmin
>>>
>>
>> Thanks,
>> Ben
>>
>
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep \
7, 2021 at 6:20 AM Johnny Jazeix <<a \
href="mailto:jazeix@gmail.com">jazeix@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Ben,</div><div>not sure on \
which priority it is regarding the KDE Frameworks but I've added one on GCompris \
(<a href="https://invent.kde.org/education/gcompris/-/commit/67c9839d7970b360b5d6b0ec928b492f9003d07d" \
target="_blank">https://invent.kde.org/education/gcompris/-/commit/67c9839d7970b360b5d6b0ec928b492f9003d07d</a>) \
if it can help on more tests.</div></div></blockquote><div><br></div><div>Thanks for \
getting that landed Johnny.</div><div><br></div><div>Please note that you've \
specified no dependencies, so your builds won't even have ECM available so you \
may wish to fix that.<br></div><div> <br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div><br></div><div>Cheers,</div><div><br></div><div>Johnny<br></div></div>< \
/blockquote><div><br></div><div>Cheers,</div><div>Ben</div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 5 sept. 2021 Ã \
12:11, Ben Cooksley <<a href="mailto:bcooksley@kde.org" \
target="_blank">bcooksley@kde.org</a>> a écrit :<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Sun, Sep 5, 2021 at 6:13 PM Ben Cooksley <<a \
href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi \
all,</div></div></blockquote><div><br></div><div>Hi all,</div><div> \
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div><br></div><div>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).</div><div><br></div><div>This begins our first steps towards \
transferring CI over from Jenkins to Gitlab.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>As an update, an initial version \
of the seed job tooling is now ready, however testing that tooling requires that \
dependency information be available.</div><div>This requires that the .kde-ci.yml \
files be populated in repositories.</div><div><br></div><div>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.<br></div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>For those \
curious, the results of those initials runs can be found at <a \
href="https://invent.kde.org/groups/teams/ci-artifacts/-/packages" \
target="_blank">https://invent.kde.org/groups/teams/ci-artifacts/-/packages</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>You can find a template detailing the available options at <a \
href="https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml" \
target="_blank">https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml</a></div><div><br></div><div>Where \
possible please avoid overriding the system defaults except where needed by your \
project (ie. don't just copy the template in full)</div><div>The defaults mirror \
the template and can be found at <a \
href="https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml" \
target="_blank">https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml</a></div><div><br></div><div>In \
terms of the format of the 'Dependencies' section, please bear in mind the \
following:</div><div>- 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</div><div>- For the \
'require' section:</div><div> 1) Please only include the projects you \
*explicitly* depend on. Dependencies of your dependencies will be included \
automatically</div><div> 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.<br></div><div> 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.</div><div> \
'@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.</div><div> '@latest' and '@stable' refer to the \
corresponding branches defined in the branch-rules.yml file, which can be found in \
sysadmin/repo-metadata<br></div><div><br></div><div>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.</div><div>Please avoid using explicit branch names \
unless absolutely necessary.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Please let me know if you have any questions on the \
above.</div><div><br></div><div>Thanks,</div><div>Ben Cooksley</div><div>KDE \
Sysadmin<br></div></div></blockquote><div><br></div><div>Thanks,</div><div>Ben<br></div></div></div>
</blockquote></div>
</blockquote></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic