On improvements invisible to users, but which the team would like to talk

hi oy all!

the yunohost team is glad to announce that we improved the packaging process [OMG it’s way to corporate lol sorry :smiling_face_with_tear:]

i start again…
in the last few weeks we’ve unexpectedly improved our internal tools and we’re just proud of it, so we’re talking about it, that’s all

it will just be a nerdism post, feel free to stop reading here if that doesn’t interest you, it’s okay, i won’t be sad, promise!


so… [OMG there’s still someone, am shy]

in the beginning, there was packaging v1. it was a mess.
then packaging v2 came and saved us (almost)

packaging v1 had github actions scripts to automatically update the package when a new version of the app was released by it’s devs
unfortunately, too few packages implemented it, due to a lack of standardization

when packaging v2 (our saviour) brought standardization and saved us (almost), many more apps used a new auto-update mechanism, but that wasn’t enough, because only github upstream was supported

one day one of our regular contributors modified our current auto-updater scripts to support gitlab

it was nice, but not enough!

using this great work and the energy I didn’t have (i’m tired), I added support for gitea and forgejo, on a whim in a single night (as all my work lmao)

yes, gitea and forgejo are using the exact same API, but now as forgejo is a hard fork, this may change in the future

so now the auto-updater script is able to handle most of app’s upstream, as we will see just below

we also worked to better show what the script has done, by clearly displaying updates that have just been pushed, those that have been pending (so who needs attention), as well as those that have failed and why

this greatly simplify a significant part of package maintenance work, allowing us to rest (many people in the team are exhausted) or work on something else

for you, apps will simply updated quickly! which is nice too, eh ^w^


huge nerdism time! :tada:

today, we have :

  • 558 yunohost packages
  • but 22 packages tagged as deprecated (so no longer maintained by their devs)
  • so 558 - 22 = 536
  • 515 packages are tagged “working”

and more precisely, in those 558 packages (sorry it’s a pain to filter deprecated ones so I just won’t do it :smiling_face_with_tear:):

  • 86 packages v1 (so incompatible with the new auto-updater)
  • 472 packages v2
    • so only less than 15% packaging v1 remaining after one year :tada:

apps using auto-update (not the github action shit):

  • 321 apps in total
  • 281 apps using github as upstream
  • 27 apps using gitlab as upstream
    • 5 among them on the flagship gitlab.com instance
    • 15 among them on framagit.org
    • so 7 among them who are on other gitlab instances
  • 2 apps using gitea as upstream
  • 11 apps using forgejo as upstream
    • 8 among them on codeberg.org
    • so 3 among them who are on other forgejo instances

so the auto-updater script is covering nearly 70% ((321 * 100) / 472 = 68,00) of packages v2!!
how cool is that?! :grin:

the remaining are mostly edge-case (devs doing weird stuff, basically) or sources provided on a custom website (but we’re working on that)

so, yeah, the team is proud and we wanted to share this to you ^w^


you’re still there? woaw nice!

so i can tell you a secret, only you and me will know:
we also improved the app store recently, you noticed?

  • we put it on the weblate to allow translation
  • deprecated apps are now in a seperate list (at the bottom) instead of mingled with all the others
  • there are now a link to the package license in app pages
  • we’ve improved eloquence of error messages when sending a wishlist request, because not everyone is a huge nerd like us!
  • oh and we’re now supporting non-free (and more specifically: post-free) licenses for apps and yunohost packages ! a proper warning will be show to let people know if an app that interests them is concerned

PS: am sorry, i don’t have energy for a french-speaking translation, please forgive me :smiling_face_with_tear:

40 Likes

:purple_heart: Thank you and all the other devs for all the hard work! :heart:

Especially the back-side of things – the hidden cogs and wheels – that make the foundation of everything else are sometimes hard to appreciate as an end-user. And we really should!

(P.S. if there is need for help with the licensing side, I’m happy to help)

7 Likes

Bravo for this huge improvements :clap: :clap: :clap:

1 Like

Is there a way to have a look at the auto-update queue ?
(To see if the one app I’m waiting for will be there soon or not)

I think that this is not possible, but I’ll never know without asking :face_with_peeking_eye:

Infinite love on the team :heart:

1 Like

Congratulations!
Thank you for the information and thank you for your work!!

1 Like

there is no “queue”, the script runs once a day on all catalog apps that activated the auto-update mechanism and if an update is available, opens a PR an create a CI test

you can see all CI tests here: YunoRunner for CI
those containing ci-auto-update in their name are those triggered by the auto-update script

In my specific case, I still have questions.
Minetest’s last run was on february 21, there was a merge request, but this version was bugged and the MR is waiting : Upgrade sources by yunohost-bot · Pull Request #56 · YunoHost-Apps/minetest_ynh · GitHub
So, for the but to run again, the MR should be removed/closed/validated ?

What are the rules ?

on the latest log: https://paste.yunohost.org/raw/aborelanek

you can see minetest under “Apps already with an update PR”, so yes you need to close the actual PR for the bot to open a new one

Thanks :slight_smile:
(the log you pasted is not public ? )

it’s posted on the YunoHost development matrix channel each night

1 Like