<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 7, 2021 at 6:20 AM Johnny Jazeix <<a href="mailto:jazeix@gmail.com">jazeix@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Ben,</div><div>not sure on which priority it is regarding the KDE Frameworks but I've added one on GCompris (<a href="https://invent.kde.org/education/gcompris/-/commit/67c9839d7970b360b5d6b0ec928b492f9003d07d" target="_blank">https://invent.kde.org/education/gcompris/-/commit/67c9839d7970b360b5d6b0ec928b492f9003d07d</a>) if it can help on more tests.</div></div></blockquote><div><br></div><div>Thanks for getting that landed Johnny.</div><div><br></div><div>Please note that you've specified no dependencies, so your builds won't even have ECM available so you may wish to fix that.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Cheers,</div><div><br></div><div>Johnny<br></div></div></blockquote><div><br></div><div>Cheers,</div><div>Ben</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 5 sept. 2021 à 12:11, Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 5, 2021 at 6:13 PM Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi all,</div></div></blockquote><div><br></div><div>Hi all,</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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).</div><div><br></div><div>This begins our first steps towards transferring CI over from Jenkins to Gitlab.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>As an update, an initial version of the seed job tooling is now ready, however testing that tooling requires that dependency information be available.</div><div>This requires that the .kde-ci.yml files be populated in repositories.</div><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>For those curious, the results of those initials runs can be found at <a href="https://invent.kde.org/groups/teams/ci-artifacts/-/packages" target="_blank">https://invent.kde.org/groups/teams/ci-artifacts/-/packages</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>You can find a template detailing the available options at <a href="https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml" target="_blank">https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml</a></div><div><br></div><div>Where possible please avoid overriding the system defaults except where needed by your project (ie. don't just copy the template in full)</div><div>The defaults mirror the template and can be found at <a href="https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml" target="_blank">https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml</a></div><div><br></div><div>In terms of the format of the 'Dependencies' section, please bear in mind the following:</div><div>- 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</div><div>- For the 'require' section:</div><div>  1) Please only include the projects you *explicitly* depend on. Dependencies of your dependencies will be included automatically</div><div>  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.<br></div><div>  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.</div><div>      '@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.</div><div>      '@latest' and '@stable' refer to the corresponding branches defined in the branch-rules.yml file, which can be found in sysadmin/repo-metadata<br></div><div><br></div><div>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.</div><div>Please avoid using explicit branch names unless absolutely necessary.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Please let me know if you have any questions on the above.</div><div><br></div><div>Thanks,</div><div>Ben Cooksley</div><div>KDE Sysadmin<br></div></div></blockquote><div><br></div><div>Thanks,</div><div>Ben<br></div></div></div>
</blockquote></div>
</blockquote></div></div>