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.
Cheers, Johnny Le dim. 5 sept. 2021 à 12:11, Ben Cooksley <bcooks...@kde.org> a écrit : > On Sun, Sep 5, 2021 at 6:13 PM Ben Cooksley <bcooks...@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 >