Gitlab CI - Inbound

[Nicolas Fella]

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,

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"?

Cheers

Nico