On Wed, Mar 27, 2024 at 5:40 AM Volker Krause <vkra...@kde.org> wrote:
> On Dienstag, 26. März 2024 08:59:29 CET Heiko Becker wrote: > > On Monday, 25 March 2024 23:23:01 CET, Albert Astals Cid wrote: > > > El dissabte, 23 de març de 2024, a les 21:06:46 (CET), Julius Künzel va > > > > > > escriure: > > >> 22.03.2024 17:22:33 Albert Astals Cid <aa...@kde.org>: ... > > > > > > It is some extra work (not a lot, but some). > > > > > > You're asking for the workflow of creating to be releases to be > changed by > > > creating the entry in the file earlier, that alone is a bit of work, > but > > > it > > > > > > has several other consequences: > > > * https://apps.kde.org/okular/ shows releases from the appstream > file (i > > > > > > think) meaning that the code should learn to ignore releases in the > > > future. > > > Arguably we would need also now, but given the data is added > > > just a few days > > > before the actual release i think users can understand "this release > will > > > happen soon)" compared to a thing one month in the future > > > > > > * What happens if we have to change the release date or release > version > > > > > > number (hasn't happened in a good while, but wouldn't be a bad thing to > > > prepare for it). We would need to update the string or date of an > existing > > > entry, as far as I know we don't have tooling for that (because we only > > > add > > > the data to the file when we're almost sure abiyt it). > > > > In addition I'm a litte bit wary of conflicts when cherry-picking the > > appstream changes between branches, which the script does after > > incrementing the version. I saw at least conflicts in itinerary's > releases > > notes and e.g. kdeconnect's or okular's windows releases in the past, > which > > isn't that much of a problem but it could become one with the 245 modules > > of gear (to be fair not all have appstream metadata (yet)). > > Sorry about that! I try to keep both branches in sync usually, if there is > anything I can do/do differently to not impact your work I'm happy to do > that > of course. > > > Otherwise I'd just miss the opportunity to trigger a CI build for > > everything again shortly before the release, but I'd guess that's easy to > > get over. > > Albert seems to have an alternative way using API (?) for the weekly build > status reports, I guess that could be reused/combined somehow? > Please see https://docs.gitlab.com/ee/api/pipelines.html#create-a-new-pipeline I imagine he uses https://docs.gitlab.com/ee/api/pipelines.html#get-the-latest-pipeline to fetch the outcome of that. Note that the above API is not suitable for building a public dashboard due to the number of queries we would need, but it is fine for one off runs like what Albert does. > > Regards, > Volker Cheers, Ben
