On Mon, Sep 6, 2021 at 12:46 AM Nicolas Fella <nicolas.fe...@gmx.de> wrote:
> On 05.09.21 08:13, Ben Cooksley wrote: > > 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. > > > > For those curious, the results of those initials runs can be found at > > https://invent.kde.org/groups/teams/ci-artifacts/-/packages > > <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 > > < > 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 > > < > 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 > > Hi Ben, > Hi Nicolas, > thanks for your work on this! > > How would I best encode a dependency like "On Linux and FreeBSD depend > on kwayland, but not on Windows and macOS"? > I would suggest doing something like the following, modifying as needed for your usecase. Dependencies: - 'on': ['Linux', 'FreeBSD', 'Windows', 'macOS'] 'require': 'frameworks/extra-cmake-modules': '@same' 'frameworks/kcoreaddons' : '@same' - 'on': ['Linux', 'FreeBSD'] 'require': 'frameworks/kwayland': '@same' You can have as many on/require sections as you need to express the dependencies of your project. > > Cheers > > Nico > Cheers, Ben