Re: Help with tarme.rb
Am Montag, 5. September 2022, 00:19:24 CEST schrieb Tobias Leupold: > Hi all, > > I have a small problem with creating release tarballs. I must have missed > something?! > > Yesterday, I created a release tarball for both KPhotoAlbum and KGeoTag. I > first tried to do this as I always did it: > > ./tarme.rb --origin trunk --version 5.9.0 kphotoalbum > > that gave me > > Traceback (most recent call last): > 8: from ./tarme.rb:74:in `' > 7: from ./tarme.rb:74:in `collect' > 6: from ./tarme.rb:81:in `block in ' > 5: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ > release.rb:66:in `get' > 4: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ > release.rb:154:in `check_ci!' > 3: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ > jenkins.rb:60:in `from_name_and_branch' > 2: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ > jenkins.rb:23:in `get' > 1: from /usr/lib64/ruby/2.7.0/net/http/response.rb:133:in > `value' /usr/lib64/ruby/2.7.0/net/http/response.rb:124:in `error!': 302 > "Found" (Net::HTTPRetriableError) > > Then, I had a look at the wiki and found "--origin stable". I used this, and > the tarball was created. > > Too late, I noticed (thanks Heiko Becker for mailing me!!!) that no > translations are included in neither tarball. > > As said, I must have missed something -- what's wrong?! > > Thanks for all help for a (after all those years still) junior dev not doing > releases too often ... ;-) > > Cheers, Tobias I have not much clue about Ruby, but I just noticed that the problem seems to originate from "jenkins.rb", where a connection to build.kde.org is established. This URL is since recently redirected to metrics.kde.org/login (due to the retirement of Jenkins I think). Also, invent.kde.org/sysadmin/repo-metadata lists "trunk", "stable", "stable_kf5" and "trunk_kf5" in i18n.json, whereas tarme.rb acceps (according to "./tarme.rb --help") "trunk", "stable", "lts", "trunk_kde4" and "stable_kde4". So ... is this a tarme.rb issue?!
Help with tarme.rb
Hi all, I have a small problem with creating release tarballs. I must have missed something?! Yesterday, I created a release tarball for both KPhotoAlbum and KGeoTag. I first tried to do this as I always did it: ./tarme.rb --origin trunk --version 5.9.0 kphotoalbum that gave me Traceback (most recent call last): 8: from ./tarme.rb:74:in `' 7: from ./tarme.rb:74:in `collect' 6: from ./tarme.rb:81:in `block in ' 5: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ release.rb:66:in `get' 4: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ release.rb:154:in `check_ci!' 3: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ jenkins.rb:60:in `from_name_and_branch' 2: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ jenkins.rb:23:in `get' 1: from /usr/lib64/ruby/2.7.0/net/http/response.rb:133:in `value' /usr/lib64/ruby/2.7.0/net/http/response.rb:124:in `error!': 302 "Found" (Net::HTTPRetriableError) Then, I had a look at the wiki and found "--origin stable". I used this, and the tarball was created. Too late, I noticed (thanks Heiko Becker for mailing me!!!) that no translations are included in neither tarball. As said, I must have missed something -- what's wrong?! Thanks for all help for a (after all those years still) junior dev not doing releases too often ... ;-) Cheers, Tobias
Re: Cleaning up cdash.org integration, what to do, or any hidden usage still?
Hi, On Freitag, 2. September 2022 12:20:50 CEST Friedrich W. H. Kossebau wrote: > Hi, > > (cc: kde-devel for heads-up, please reply only to kde-core-devel). > > we stumbled over some CTestConfig.cmake files in some of the KDE git > repositories. Which seem to originate from a time where people worked on > integration with cdash.org, that is a decade ago :) > > It seems though this integration no longer is maintained: > * no KDE projects seem listed on cdash.org anymore: > https://my.cdash.org/viewProjects.php?allprojects=1 > * the KDEUtilsNightly.cmake seems to have found no counterpart in the ECM > world. The only reference seen is the check for the presence of a > CTestConfig.cmake file and the inclusion of the CTest module in that case. > > With KDE's deployment of first Jenkins and now Gitlab CI around the purpose > of the integration with cdash.org also seems no longer needed, by what I > understand? > > So can we state that this cdash integration is officially no longer done, > and thus we can clean up any traces of it, for clean and non-confusing data > & code? I think so. > Are there any other things left to do to clean up this, besides the > following? > > T1) Remove any remaining CTestConfig.cmake files from KDE repos. > > T2) Remove support in KDECMakeSettings for deal with CTestConfig.cmake > files: > https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/295 > > T3) Add a note on the respective Wiki page about being outdated: > https://techbase.kde.org/Development/CMake/DashboardBuilds sounds good, but I didn't check. Thanks Alex
Re: Notice of impending change to Gitlab CI
On 4/9/22 10:42, Ben Cooksley wrote: Hi all, Currently our Gitlab CI jobs for Linux (SUSE) and Android (Ubuntu) run their respective jobs as root within the Docker containers that Gitlab spawns for them. This is a restriction that was previously required by the simultaneous use of these same images by Jenkins, which following the shutdown of build.kde.org this weekend is no longer a problem. I will look into making this adjustment to our CI image(s) in the coming week for Linux (SUSE). Once implemented, tests which made use of root privileges may begin to fail (and those that were incompatible with it will begin to pass). Android Qt 5 builds still share the image with the Binary Factory and therefore will have to continue to run as root at this time until we are able to discontinue the BInary Factory (or at least, Android's use of it). Thanks, Ben Good work! This is especially good news for KIO (and possibly other frameworks with unittests that make heavy use of I/O operations). Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
Re: Getting Involved Into KDE Developing
El dissabte, 3 de setembre de 2022, a les 15:28:54 (CEST), Emrecan Şuster va escriure: > Hi, I'm a KDE enthusiast who wants to get involved into KDE developing. I > have been learning about KDE Frameworks nowadays but I don’t know how I do > serve the needs of KDE. Is there any list of tasks or something else? https://community.kde.org/Get_Involved/development#Choose_what_to_do > By the way, I need to say that I’m relatively new to C++/Qt. A mentoring > would be good for me if possible. My suggestion is to jump on kde-devel in Matrix/IRC and make questions. Cheers, Albert > > Thanks, > Emre.
Re: Gitlab CI Dashboards and retirement of build.kde.org
On Sun, Sep 4, 2022 at 8:51 PM Gilles Caulier wrote: > Hi Ben, > HI Gilles, > > With build/binary-factory , it was possible to get an Embeddable Build > Status Icon as this one : > > > https://binary-factory.kde.org/view/AppImage/job/Digikam_Nightly_appimage-centos7/badge/ > > Does this feature still exist with Gitlab infrastructure ? > Yes, quoting my earlier email: [quote] Gitlab provides a limited selection of badges - which can be found at: - https://invent.kde.org/multimedia/kdenlive/badges/master/pipeline.svg - https://invent.kde.org/multimedia/kdenlive/badges/master/coverage.svg - https://invent.kde.org/multimedia/kdenlive/-/badges/release.svg [/quote] You'll need to swap multimedia/kdenlive to graphics/digikam but otherwise that should work fine. Please note that the Binary Factory is not impacted by this, so anything relating to the Binary Factory is unchanged at this time. > > Thanks > > Gilles > Regards, Ben > > Le sam. 27 août 2022 à 11:45, Ben Cooksley a écrit : > > > > 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, i'd like to proceed with retiring and shutting down > build.kde.org as soon as possible so the capacity it occupies can be > released and reallocated to Gitlab. > > > > 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 >
Re: Gitlab CI Dashboards and retirement of build.kde.org
On Sun, Sep 4, 2022 at 8:51 PM Gilles Caulier wrote: > Hi Ben, > HI Gilles, > > With build/binary-factory , it was possible to get an Embeddable Build > Status Icon as this one : > > > https://binary-factory.kde.org/view/AppImage/job/Digikam_Nightly_appimage-centos7/badge/ > > Does this feature still exist with Gitlab infrastructure ? > Yes, quoting my earlier email: [quote] Gitlab provides a limited selection of badges - which can be found at: - https://invent.kde.org/multimedia/kdenlive/badges/master/pipeline.svg - https://invent.kde.org/multimedia/kdenlive/badges/master/coverage.svg - https://invent.kde.org/multimedia/kdenlive/-/badges/release.svg [/quote] You'll need to swap multimedia/kdenlive to graphics/digikam but otherwise that should work fine. Please note that the Binary Factory is not impacted by this, so anything relating to the Binary Factory is unchanged at this time. > > Thanks > > Gilles > Regards, Ben > > Le sam. 27 août 2022 à 11:45, Ben Cooksley a écrit : > > > > 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, i'd like to proceed with retiring and shutting down > build.kde.org as soon as possible so the capacity it occupies can be > released and reallocated to Gitlab. > > > > 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 >
Re: Gitlab CI Dashboards and retirement of build.kde.org
On Sun, Sep 4, 2022 at 8:51 PM Gilles Caulier wrote: > Hi Ben, > HI Gilles, > > With build/binary-factory , it was possible to get an Embeddable Build > Status Icon as this one : > > > https://binary-factory.kde.org/view/AppImage/job/Digikam_Nightly_appimage-centos7/badge/ > > Does this feature still exist with Gitlab infrastructure ? > Yes, quoting my earlier email: [quote] Gitlab provides a limited selection of badges - which can be found at: - https://invent.kde.org/multimedia/kdenlive/badges/master/pipeline.svg - https://invent.kde.org/multimedia/kdenlive/badges/master/coverage.svg - https://invent.kde.org/multimedia/kdenlive/-/badges/release.svg [/quote] You'll need to swap multimedia/kdenlive to graphics/digikam but otherwise that should work fine. Please note that the Binary Factory is not impacted by this, so anything relating to the Binary Factory is unchanged at this time. > > Thanks > > Gilles > Regards, Ben > > Le sam. 27 août 2022 à 11:45, Ben Cooksley a écrit : > > > > 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, i'd like to proceed with retiring and shutting down > build.kde.org as soon as possible so the capacity it occupies can be > released and reallocated to Gitlab. > > > > 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 >
Re: Copying po/docbook files to repositories nightly
Le dim. 4 sept. 2022 à 11:14, Albert Astals Cid a écrit : > El dissabte, 3 de setembre de 2022, a les 10:44:01 (CEST), Johnny Jazeix > va > escriure: > > Hi, > > > > this is great. For GCompris, we have some stuff to handle translation > that > > differs from the usual (for example, the po files are in > > po/gcompris_.po, not po//gcompris_qt.po). I'll take a look to > > harmonise it with the usual. > > For the stable branch, we don't plan to do a release before December so > it > > would be better to not apply it at Akademy (except if the change on > > GCompris side is easily backportable but I have to check). > > If you don't plan to do a release before December you have 3 months to > make > sure it works, i don't understand the problem. > > Albert > > Priorities and time it requires to update the actual process. It's not just changing the handling of the tree of files, it's also make sure we don't ship translations with enough content and have it in a transparent way for each platform. For now, it's a script that fetch the po files and only take in account the good ones, we make a release tgz and we use it on all platforms. With this change, all the po will already be there (even the ones we don't want to ship) so we need to ensure at build time that the languages we don't want won't be in packages. Regarding the actual stable branch, even if we don't plan to make releases, it will still mean the new po files will be added in git so we need to ensure it does not break the actual flow in this branch or ship unwanted files. So yes, the work to do is defined, the available time, less. It will probably be done on time but the aim of this thread was to give opinions (big +1 on the idea) and comments (there is work to do, it's worth it but not free). Cheers, Johnny > > > > Cheers, > > > > Johnny > > > > Le sam. 3 sept. 2022 à 09:47, Albert Astals Cid a écrit > : > > > El dissabte, 3 de setembre de 2022, a les 1:01:47 (CEST), Ömer Fadıl > USTA > > > va > > > > > > escriure: > > > > Just wanted to learn one thing , isn't this will populate the logs > with > > > > lots of entries on git log history ? > > > > I mean right now I am tracking git changes based on changes in > history > > > > > > but > > > > > > > this will add a new entry > > > > each night or I understand this wrong ? > > > > > > If you look a the example URL i posted you can see there's not a new > entry > > > each night. > > > > > > Cheers, > > > > > > Albert > > > > > > > Also wouldn't it be possible to fetch related translation on the fly > > > > from > > > > the software side after releases ? > > > > I mean translation of language X might be getting a little back lets > say > > > > 5.26 released but team X > > > > might be late to complete their translation on time but user should > have > > > > chance to download it > > > > after the release of it (without waiting for the next tagging ). > > > > Wouldn't > > > > it be possible to download and install the latest > > > > language data in applications just like users do with themes? > > > > > > > > Thank you > > > > > > > > Ömer Fadıl Usta > > > > PGP key : 0xfd11561976b1690b > > > > about.me/omerusta > > > > > > > > > > > > Albert Astals Cid , 3 Eyl 2022 Cmt, 00:25 tarihinde > şunu > > > > > > > > yazdı: > > > > > As you may know, translations for apps don't live in the same > place as > > > > > > the > > > > > > > > code for the apps themselves. > > > > > > > > > > This greatly benefits translators but is not awesome for the > release > > > > > management > > > > > side of things since it means that for each release we need to not > > > > > > forget > > > > > > > > to > > > > > copy the appropriate files to the appropriate place, makes tagging > > > > > somewhat > > > > > harder, etc. > > > > > > > > > > For a while now we have been running an "experimental" > > > > > > copy-po-qm-docbook- > > > > > > > > back-to-repository in a number of "select" repositories and it > seems > > > > > to > > > > > have > > > > > worked quite well, you can seem one example in > > > > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po > > > > > > > > > > The idea is to enable this for all repositories. > > > > > > > > > > This is a heads up, as a developer there's nothing you need to do, > at > > > > > > most > > > > > > > > remove the po/ folder from .gitignore if for some reason it is > there. > > > > > > > > > > If you're a packager you will need to make sure your scripts don't > try > > > > > > to > > > > > > > > copy > > > > > po/qm/docbook files anymore when doing a release once this is > > > > > > activated. > > > > > > > > My plan would be to enable this scripts over Akademy so we have the > > > > > > high > > > > > > > > bandwidth there to fix things if needed. > > > > > > > > > > Opinions? Comments? > > > > > > > > > > Cheers, > > > > > > > > > > Albert > > > > >
Re: Gitlab CI Dashboards and retirement of build.kde.org
Hi Ben, With build/binary-factory , it was possible to get an Embeddable Build Status Icon as this one : https://binary-factory.kde.org/view/AppImage/job/Digikam_Nightly_appimage-centos7/badge/ Does this feature still exist with Gitlab infrastructure ? Thanks Gilles Le sam. 27 août 2022 à 11:45, Ben Cooksley a écrit : > > 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, > i'd like to proceed with retiring and shutting down build.kde.org as soon as > possible so the capacity it occupies can be released and reallocated to > Gitlab. > > 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
Re: Gitlab CI Dashboards and retirement of build.kde.org
Hi Ben, With build/binary-factory , it was possible to get an Embeddable Build Status Icon as this one : https://binary-factory.kde.org/view/AppImage/job/Digikam_Nightly_appimage-centos7/badge/ Does this feature still exist with Gitlab infrastructure ? Thanks Gilles Le sam. 27 août 2022 à 11:45, Ben Cooksley a écrit : > > 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, > i'd like to proceed with retiring and shutting down build.kde.org as soon as > possible so the capacity it occupies can be released and reallocated to > Gitlab. > > 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
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 Dashboards and retirement of build.kde.org
Le sam. 3 sept. 2022 à 21:28, Ben Cooksley a écrit : > On Sat, Sep 3, 2022 at 9:29 PM Gleb Popov <6year...@gmail.com> wrote: > >> On Sat, Sep 3, 2022 at 7:46 AM Ben Cooksley wrote: >> > >> > As previously indicated, I have now shutdown 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 domain has been redirected to metrics.kde.org. >> > >> > The server which was acting as a builder for build.kde.org will be >> rebuilt in the coming days and reallocated to support Gitlab CI workloads. >> > >> > Thanks, >> > Ben >> >> What should be used instead of binary-factory? How do I transform this >> link? >> >> >> https://binary-factory.kde.org/view/Windows%2064-bit/job/Kate_Release_win64/1762/artifact/kate-22.08.0-1762-windows-msvc2019_64-cl.exe > > > At this time the Binary Factory is not impacted by this. > > Regards, > Ben > Hi, I think the issue mentioned by Glen is that this link (and all other artifacts from binary-factory) is redirected to https://build-artifacts.kde.org/binary-factory/Kate_Release_win64/1762/kate-22.08.0-1762-windows-msvc2019_64-cl.exe which does not exist. Cheers, Johnny
Re: Gitlab CI Dashboards and retirement of build.kde.org
On Sat, Sep 3, 2022 at 7:46 AM Ben Cooksley wrote: > > As previously indicated, I have now shutdown 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 domain has been redirected to metrics.kde.org. > > The server which was acting as a builder for build.kde.org will be rebuilt in > the coming days and reallocated to support Gitlab CI workloads. > > Thanks, > Ben What should be used instead of binary-factory? How do I transform this link? https://binary-factory.kde.org/view/Windows%2064-bit/job/Kate_Release_win64/1762/artifact/kate-22.08.0-1762-windows-msvc2019_64-cl.exe
Re: Copying po/docbook files to repositories nightly
El dissabte, 3 de setembre de 2022, a les 10:44:01 (CEST), Johnny Jazeix va escriure: > Hi, > > this is great. For GCompris, we have some stuff to handle translation that > differs from the usual (for example, the po files are in > po/gcompris_.po, not po//gcompris_qt.po). I'll take a look to > harmonise it with the usual. > For the stable branch, we don't plan to do a release before December so it > would be better to not apply it at Akademy (except if the change on > GCompris side is easily backportable but I have to check). If you don't plan to do a release before December you have 3 months to make sure it works, i don't understand the problem. Albert > > Cheers, > > Johnny > > Le sam. 3 sept. 2022 à 09:47, Albert Astals Cid a écrit : > > El dissabte, 3 de setembre de 2022, a les 1:01:47 (CEST), Ömer Fadıl USTA > > va > > > > escriure: > > > Just wanted to learn one thing , isn't this will populate the logs with > > > lots of entries on git log history ? > > > I mean right now I am tracking git changes based on changes in history > > > > but > > > > > this will add a new entry > > > each night or I understand this wrong ? > > > > If you look a the example URL i posted you can see there's not a new entry > > each night. > > > > Cheers, > > > > Albert > > > > > Also wouldn't it be possible to fetch related translation on the fly > > > from > > > the software side after releases ? > > > I mean translation of language X might be getting a little back lets say > > > 5.26 released but team X > > > might be late to complete their translation on time but user should have > > > chance to download it > > > after the release of it (without waiting for the next tagging ). > > > Wouldn't > > > it be possible to download and install the latest > > > language data in applications just like users do with themes? > > > > > > Thank you > > > > > > Ömer Fadıl Usta > > > PGP key : 0xfd11561976b1690b > > > about.me/omerusta > > > > > > > > > Albert Astals Cid , 3 Eyl 2022 Cmt, 00:25 tarihinde şunu > > > > > > yazdı: > > > > As you may know, translations for apps don't live in the same place as > > > > the > > > > > > code for the apps themselves. > > > > > > > > This greatly benefits translators but is not awesome for the release > > > > management > > > > side of things since it means that for each release we need to not > > > > forget > > > > > > to > > > > copy the appropriate files to the appropriate place, makes tagging > > > > somewhat > > > > harder, etc. > > > > > > > > For a while now we have been running an "experimental" > > > > copy-po-qm-docbook- > > > > > > back-to-repository in a number of "select" repositories and it seems > > > > to > > > > have > > > > worked quite well, you can seem one example in > > > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po > > > > > > > > The idea is to enable this for all repositories. > > > > > > > > This is a heads up, as a developer there's nothing you need to do, at > > > > most > > > > > > remove the po/ folder from .gitignore if for some reason it is there. > > > > > > > > If you're a packager you will need to make sure your scripts don't try > > > > to > > > > > > copy > > > > po/qm/docbook files anymore when doing a release once this is > > > > activated. > > > > > > My plan would be to enable this scripts over Akademy so we have the > > > > high > > > > > > bandwidth there to fix things if needed. > > > > > > > > Opinions? Comments? > > > > > > > > Cheers, > > > > > > > > Albert
Re: Gitlab CI Dashboards and retirement of build.kde.org
Hi Ben, With build/binary-factory , it was possible to get an Embeddable Build Status Icon as this one : https://binary-factory.kde.org/view/AppImage/job/Digikam_Nightly_appimage-centos7/badge/ Does this feature still exist with Gitlab infrastructure ? Thanks Gilles Le sam. 27 août 2022 à 11:45, Ben Cooksley a écrit : > > 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, > i'd like to proceed with retiring and shutting down build.kde.org as soon as > possible so the capacity it occupies can be released and reallocated to > Gitlab. > > 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
Notice of impending change to Gitlab CI
Hi all, Currently our Gitlab CI jobs for Linux (SUSE) and Android (Ubuntu) run their respective jobs as root within the Docker containers that Gitlab spawns for them. This is a restriction that was previously required by the simultaneous use of these same images by Jenkins, which following the shutdown of build.kde.org this weekend is no longer a problem. I will look into making this adjustment to our CI image(s) in the coming week for Linux (SUSE). Once implemented, tests which made use of root privileges may begin to fail (and those that were incompatible with it will begin to pass). Android Qt 5 builds still share the image with the Binary Factory and therefore will have to continue to run as root at this time until we are able to discontinue the BInary Factory (or at least, Android's use of it). Thanks, Ben
Notice of impending change to Gitlab CI
Hi all, Currently our Gitlab CI jobs for Linux (SUSE) and Android (Ubuntu) run their respective jobs as root within the Docker containers that Gitlab spawns for them. This is a restriction that was previously required by the simultaneous use of these same images by Jenkins, which following the shutdown of build.kde.org this weekend is no longer a problem. I will look into making this adjustment to our CI image(s) in the coming week for Linux (SUSE). Once implemented, tests which made use of root privileges may begin to fail (and those that were incompatible with it will begin to pass). Android Qt 5 builds still share the image with the Binary Factory and therefore will have to continue to run as root at this time until we are able to discontinue the BInary Factory (or at least, Android's use of it). Thanks, Ben
Notice of impending change to Gitlab CI
Hi all, Currently our Gitlab CI jobs for Linux (SUSE) and Android (Ubuntu) run their respective jobs as root within the Docker containers that Gitlab spawns for them. This is a restriction that was previously required by the simultaneous use of these same images by Jenkins, which following the shutdown of build.kde.org this weekend is no longer a problem. I will look into making this adjustment to our CI image(s) in the coming week for Linux (SUSE). Once implemented, tests which made use of root privileges may begin to fail (and those that were incompatible with it will begin to pass). Android Qt 5 builds still share the image with the Binary Factory and therefore will have to continue to run as root at this time until we are able to discontinue the BInary Factory (or at least, Android's use of it). Thanks, Ben
