<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 6, 2021 at 12:46 AM Nicolas Fella <<a href="mailto:nicolas.fella@gmx.de">nicolas.fella@gmx.de</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">On 05.09.21 08:13, Ben Cooksley wrote:<br>
> Hi all,<br>
><br>
> This morning after much work i'm happy to announce that the new<br>
> generation CI scripts intended for use with Gitlab CI successfully<br>
> completed their first build (of ECM, and then subsequently of<br>
> KCoreAddons).<br>
><br>
> This begins our first steps towards transferring CI over from Jenkins<br>
> to Gitlab.<br>
><br>
> These scripts are 'Gitlab native' and are designed to work in an<br>
> environment where they will be running on merge requests, tags as well<br>
> as all branches of our repositories - something the existing scripts<br>
> were completely incompatible with. While there are still some<br>
> infrastructural elements to put in place (such as 'seed jobs' to mass<br>
> rebuild all projects after substantial changes and 'cleanup jobs' to<br>
> remove old builds from the Package Registry) the core elements needed<br>
> for initial testing of these scripts are now ready.<br>
><br>
> For those curious, the results of those initials runs can be found at<br>
> <a href="https://invent.kde.org/groups/teams/ci-artifacts/-/packages" rel="noreferrer" target="_blank">https://invent.kde.org/groups/teams/ci-artifacts/-/packages</a><br>
> <<a href="https://invent.kde.org/groups/teams/ci-artifacts/-/packages" rel="noreferrer" target="_blank">https://invent.kde.org/groups/teams/ci-artifacts/-/packages</a>><br>
><br>
> Due to the challenges associated with having to handle all of the<br>
> different forms of build and the versioning of this information, these<br>
> scripts also represent a radical change in how CI builds will be<br>
> conducted - with a large part of the configuration of the jobs<br>
> themselves, including information on project dependencies now shifting<br>
> to files located within the repository themselves. Those who monitor<br>
> commits to Frameworks repositories will have noticed the appearance of<br>
> these '.kde-ci.yml' files in some repositories.<br>
><br>
> To assist in the future rollout of the CI system it would be<br>
> appreciated if projects could please begin setting up these files<br>
> within their respective repositories.<br>
> You can find a template detailing the available options at<br>
> <a href="https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml" rel="noreferrer" target="_blank">https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml</a><br>
> <<a href="https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml" rel="noreferrer" target="_blank">https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml</a>><br>
><br>
> Where possible please avoid overriding the system defaults except<br>
> where needed by your project (ie. don't just copy the template in full)<br>
> The defaults mirror the template and can be found at<br>
> <a href="https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml" rel="noreferrer" target="_blank">https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml</a><br>
> <<a href="https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml" rel="noreferrer" target="_blank">https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml</a>><br>
><br>
> In terms of the format of the 'Dependencies' section, please bear in<br>
> mind the following:<br>
> - For the 'on' section, the special value '@all' can be used to mean<br>
> "All platforms" to avoid needing to update the file in the event<br>
> additional platforms are added in the future<br>
> - For the 'require' section:<br>
>   1) Please only include the projects you *explicitly* depend on.<br>
> Dependencies of your dependencies will be included automatically<br>
>   2) When specifying a project, you must use the repository path on<br>
> Gitlab. Legacy project paths (such as kde/workspace/plasma-desktop)<br>
> are no longer in use and will not work.<br>
>   3) There are three special values for the branch name - '@same',<br>
> '@latest' and '@stable' which can be used to refer to the branch/tag<br>
> of a dependency.<br>
>       '@same' means the branch name should be the same as that of the<br>
> project being built and should be used when declaring dependencies<br>
> among projects in a release group.<br>
>       '@latest' and '@stable' refer to the corresponding branches<br>
> defined in the branch-rules.yml file, which can be found in<br>
> sysadmin/repo-metadata<br>
><br>
> As a general rule, unless you require the absolute latest version of<br>
> another project in another release unit, it is recommended that you<br>
> use @stable.<br>
> Please avoid using explicit branch names unless absolutely necessary.<br>
><br>
> At this time it is expected that the first set of Gitlab CI builds<br>
> using the new scripts may be conducted for Frameworks within the next<br>
> week or so, assuming the build of the seed jobs goes according to plan.<br>
><br>
> Once the scripts have been proven successfully for Frameworks, we will<br>
> look at extending them to projects that depend only on Frameworks and<br>
> repositories within their release unit and finally will extend them to<br>
> projects with more complex dependency requirements. It is expected<br>
> that the switch will be flipped on the Frameworks builds sometime in<br>
> the next week or two.<br>
><br>
> Please let me know if you have any questions on the above.<br>
><br>
> Thanks,<br>
> Ben Cooksley<br>
> KDE Sysadmin<br>
<br>
Hi Ben,<br></blockquote><div><br></div><div>Hi Nicolas,</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">
<br>
thanks for your work on this!<br>
<br>
How would I best encode a dependency like "On Linux and FreeBSD depend<br>
on kwayland, but not on Windows and macOS"?<br></blockquote><div><br></div><div>I would suggest doing something like the following, modifying as needed for your usecase.<br></div><div><br></div><div>Dependencies:<br>- 'on': ['Linux', 'FreeBSD', 'Windows', 'macOS']<br>  'require':<br>    'frameworks/extra-cmake-modules': '@same'<br>    'frameworks/kcoreaddons' : '@same'</div><div>- 'on': ['Linux', 'FreeBSD']</div><div>  'require':</div><div>    'frameworks/kwayland': '@same'<br></div><div><br></div><div>You can have as many on/require sections as you need to express the dependencies of your project.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers<br>
<br>
Nico<br></blockquote><div><br></div><div>Cheers,</div><div>Ben</div><div><br></div></div></div>