[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Gitlab CI - Inbound
From: Johnny Jazeix <jazeix () gmail ! com>
Date: 2021-09-06 18:20:04
Message-ID: CAEtcAPH-S4wYan9MH-cFqPyVznWpZxF0SyMQKcBmWgwN-F1pRg () mail ! gmail ! com
[Download RAW message or body]
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/67c9839d7970b360b5d6b0ec=
928b492f9003d07d)
if it can help on more tests.
Cheers,
Johnny
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 KCoreAddon=
s).
>>
>> 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 a=
s
>> 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 projec=
ts
>> after substantial changes and 'cleanup jobs' to remove old builds from t=
he
>> 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 file=
s
> 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 conduct=
ed
>> - with a large part of the configuration of the jobs themselves, includi=
ng
>> 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' fil=
es
>> 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 min=
d
>> the following:
>> - For the 'on' section, the special value '@all' can be used to mean "Al=
l
>> 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 define=
d
>> in the branch-rules.yml file, which can be found in sysadmin/repo-metada=
ta
>>
>> 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 wee=
k
>> 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>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/67c9839d7970b360b5d6b0ec928b4 \
92f9003d07d">https://invent.kde.org/education/gcompris/-/commit/67c9839d7970b360b5d6b0ec928b492f9003d07d</a>) \
if it can help on more \
tests.</div><div><br></div><div>Cheers,</div><div><br></div><div>Johnny<br></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">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>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic