AppStream Metadata with our releases

[Ben Cooksley]

On Wed, Mar 27, 2024 at 5:40 AM Volker Krause <vkrause at 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 <aacid at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240327/7e9f324f/attachment.htm>