Re: CI moved to Qt 6.7 for Linux builds
kdiff3 will make one or two releases but needs only frameworks. This support will end in three months. master is qt6 only now. Apr 20, 2024 8:35:40 PM Ben Cooksley : > Hi all, > > I have just flipped the switch that has moved the CI system over to using Qt > 6.7 for Linux builds on our SUSE images. > > Should you see any issues with builds failing as a result of packages being > missing in the registry then please submit a merge request to > sysadmin/ci-management to ensure that build dependency is added to our seed > jobs. > > I'll leave the Qt 6.6 package registry and container images in place for > another week or so then will schedule them for removal. > > As part of this I have also updated the list of projects with Qt 6 only > master branches. Any residual Qt 5 build artifacts the CI system was holding > for those projects have now been purged, which may impact downstream projects > that depend on those projects that are still on Qt 5. > > On an adjacent note, i'd also like to schedule removing CI support for > release/23.08 and Plasma/5.27 builds (by purging all their binaries we > currently hold) for the Qt 5.15 series. > > While checking however I note that several projects still have activity on > those branches. Can we please confirm whether any further releases are > expected, as i'd prefer to remove anything that isn't being properly > maintained anymore. > > Thanks, > Ben signature.asc Description: PGP signature
Re: Gitlab CI Dashboards and retirement of build.kde.org
I now have no way to even test macosx builds for kdiff3, I have no access to a 64bit Intel mac. What are the plans for this and Windows builds. I have a functional windows based craft installed locally. Sep 3, 2022 12:47:06 AM Ben Cooksley : > On Sat, Aug 27, 2022 at 9:44 PM Ben Cooksley wrote: >> Hi all, >> >> This evening I completed the necessary setup required to complete our Gitlab >> CI dashboards, which can now be found at >> https://metrics.kde.org/dashboards/f/aNxvXJW4k/gitlab-ci (KDE Developer >> account login required) >> >> These allow any developer to get a view on the current CI status of projects >> and groups of projects on a branch and platform basis - and should hopefully >> provide useful insight into the overall status that can currently be >> obtained from Jenkins. >> >> As this was the last thing holding us back from shutting down >> build.kde.org[http://build.kde.org], i'd like to proceed with retiring and >> shutting down build.kde.org[http://build.kde.org] as soon as possible so the >> capacity it occupies can be released and reallocated to Gitlab. > > As previously indicated, I have now shutdown > build.kde.org[http://build.kde.org] along with the domain that supported it's > version of the CI tooling. > The repository containing that tooling has now also been archived, and the > former build.kde.org[http://build.kde.org] domain has been redirected to > metrics.kde.org[http://metrics.kde.org]. > > The server which was acting as a builder for > build.kde.org[http://build.kde.org] will be rebuilt in the coming days and > reallocated to support Gitlab CI workloads. > >> >> If anyone would like to experiment with customised views for their own >> purposes (where the above provided ones are insufficient) please file a >> Sysadmin ticket. >> >> Please let me know if there are any questions on the above. >> >> Thanks, >> Ben > > Thanks, > Ben signature.asc Description: PGP signature
Re: Gitlab CI - Inbound
How do we get a visual on exactly which lines are covered by auto testing and which aren't?
Re: Manner in which kde-gtk-config development is conducted
On Sat, Mar 21, 2020, 10:27 AM Johan Ouwerkerk wrote: > On Sat, Mar 21, 2020 at 1:32 AM Ben Cooksley wrote: > > > > Comments welcome. Please note that simply fixing the dependency > > breakage in this case is not enough to resolve this - there are > > underlying issues which need to be addressed here. > > > > Regards, > > Ben Cooksley > > KDE Sysadmin > > I cannot comment as to whether or not this is a pattern of behaviour > or just a few isolated instances. From a technical perspective I feel > there are two (additional) underlying issues worth addressing here: > > 1. This could be prevented for the most part by having CI run before, > and not after the fact. I.e. prior to merging code. > 2. Different projects have different CI needs, and it would help if a > project could safely manage their CI environment "on their own" as > much as possible. The current system requires a lot of daunting > (possibly otherwise unnecessary) complexity purely to manage the fact > that a builder image will be used not just for one project but for > perhaps the whole of KDE. > In regards to custom images kdiff3 has been using one since before invent.kde.org came into being. The repo is mirrored on gitlab. Now that invent.kde.org is up that setup runs the official ci as well. Since my custom image is based on bionic it doesn't have the lastest kf5. This quite recently cought a doc change made by some else that broke generation of docs on older doctools versions. Both KDE's official CI and my personal machine had the necessary kf5 version to build it and gave no error. Using custom docker images is a great way of catching this kind of "works for my setup issue". >
Re: CI system maintainability
On Thu, Mar 28, 2019, 6:36 AM Friedrich W. H. Kossebau wrote: > Am Donnerstag, 28. März 2019, 09:29:22 CET schrieb Kevin Ottens: > > Hello, > > > > On Thursday, 28 March 2019 09:16:11 CET Ben Cooksley wrote: > > > Please note that the commits in this instance were pushed without > > > review, so restrictions on merge requests wouldn't make a difference > > > in this case unfortunately. > > > > Maybe it's about time to make reviews mandatory... I know it's unpopular > in > > KDE, and I advocated for "don't force a tool if you can get someone to > look > > at your screen or pair with you" in the past. Clearly this compromise > gets > > somewhat exploited and that's especially bad in the case of a fragile and > > central component like KDE PIM. > Then fix what's broken. If these projects need manditory reviews fine but don't take a one-size-fits-all approach. > > > Mandatory reviews in my experience only result in more fake reviews due to > people pressuring each other to quickly get their simple patches reviewed, > lowering the general quality of reviews. > Also does the overhead reduce the number of minor improvements, where one > (as > qualified person) simply would have pushed in a minute a fix and get back > to > concentrate on the real work, instead of starting an overhead of having to > juggle with yet another patch-under-review where the current work depends > on. > > IMHO the actual problem here is: people do not do their post-push work and > care for the state on CI. > Agreed. > > From what I saw, many breakages happened with reviewed patches. Whole > releases even get done while CI is reporting failed builds, or at least > lots > of failing tests. > Requiring pre-commit hooks which run these could be helpful. They could stop this at the local machine. Perhaps also a reminder to check ci. Not sure this completely solves the issue but it would be workable for small projects like kdiff3 and would reduce overhead for minor typo correction. > > I have no idea how to fix that. We would need to ask the people for whom > this > happens why it does happen, and how we can improve things so that CI > checks > become part of their workflow. > > Cheers > Friedrich > > >
