On Tue, Sep 7, 2021 at 6:20 AM Johnny Jazeix <jaz...@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 <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 >> >