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