Gitlab CI - Inbound

[Ben Cooksley]

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20210905/3c9bbd96/attachment.htm>