On Wed, Mar 27, 2024 at 5:40=E2=80=AFAM V= olker Krause <vkrause@kde.org>= wrote:

On Dienstag, 26. M=C3=A4rz 2024 08:59:29 CET Heiko Becke= r wrote:
> On Monday, 25 March 2024 23:23:01 CET, Albert Astals Cid wrote:
> > El dissabte, 23 de mar=C3=A7 de 2024, a les 21:06:46 (CET), Juliu= s K=C3=BCnzel va
> >
> > escriure:
> >> 22.03.2024 17:22:33 Albert Astals Cid <aacid@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 wo= rk, but
> > it
> >
> > has several other consequences:
> >=C2=A0 * https://apps.kde.org/okular/ shows releases from t= he appstream file (i
> >
> > think) meaning that the code should learn to ignore releases in t= he
> > 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 > >
> >=C2=A0 * What happens if we have to change the release date or rel= ease 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 (becau= se 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 th= e 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 d= o that
of course.

> Otherwise I'd just miss the opportunity to trigger a CI build for<= br> > everything again shortly before the release, but I'd guess that= 9;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=C2=A0https://docs.gitlab.com/ee/api= /pipelines.html#create-a-new-pipeline=C2=A0
I imagine he uses= =C2=A0https://docs.gitlab.com/ee/api/pipelines.html#get-the-latest-p= ipeline to fetch the outcome of that.

Note tha= t 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.
=C2=A0

Regards,
Volker

Cheers,
Ben=C2=A0

--0000000000007997240614983121--