J’ai arrêté de le maintenir il y a bientôt deux ans, car j’ai quasiment arrêté d’être actif dans la commu de la june.
Ce dépôt fonctionne encore, mais il contient des très vieilles versions des apps, principalement, parce qu’il fallait lancer les pipelines manuellement.
Je me suis rappelé de ce projet en discutant avec un nouvel arrivé dans la june, et en retestant les scripts, je me suis aperçu qu’ils fonctionnaient toujours.
Surtout qu’en 2 ans, gitlab a sorti les “scheduled pipelines” qui permettent de lancer une pipeline tous les jours pour que les mises à jour soient automatiques, j’ai donc activé cette option sur le dépôt, donc il se mettra automatiquement à jour tous les jours à minuit
Si quelqu’un est motivé pour reprendre la pleine gestion de ce (petit) projet, sentez-vous libre, je n’ai plus l’énergie et le temps pour m’en occuper (c’est principalement de la maintenance de scripts bash à faire, vu que les maj sont mtn automatiques)
Merci pour cette information par rapport à ton implication ! Ça clarifie le statut de ce dépôt F-Droid qu’il faudrait effectivement qu’on reprenne, notamment pour y mettre toutes les applications v2 (Cesium v2, Ğecko, Ğinkgo…). Je t’ai salué au CDL2024 mais tu avais l’air pris dans tes discussions
Si besoin, je peux sans problème passer la main en expliquant la structure du dépôt !
Ah mince, désolé p our être honnête, je suis très peu physionomiste, donc je t’ai pas reconnu sur le moment, et après coup je me suis dit “hé mais c’est hugo” et j’ai pas réussi à te retrouver après !
Tu nous as laissé une belle patate chaude ou une bombe à retardement entre les mains Le dépôt a déjà atteint 3.2Go en juste un mois, depuis la dernière fois ou on a entamer le ménage en septembre pour migrer GitLab !
Je me suis permis de changer les pipelines programées à une toutes les semaines. Ça me semble suffisamment fréquent.
Le problème étant que le job pages créé plein d’artefacts non nécessaires qui ne sont pas programmés à la suppression.
J’ai supprimé manuellement les artefacts.
Je prends le temps d’expliquer ça clairement et publiquement pour que les mainteneurs d’autres dépôts peuvent prendre en considération l’impact de leur dépôt sur l’espace disque occupé sur le serveur hébergeant GitLab.
Oups, je suis désolé de ça, je pensais avoir mis une valeur plus basse dans la CI
Les mises à jour des applications seront moins fréquentes, mais ça ne pose aucun problème !
J’avais pas du tout remarqué, my bad !
Du coup, petite question en retour, est-ce que c’est le fait de faire tourner des pipelines tous les jours qui est embêtant ? Ou c’est vraiment le stockage des artfacts.
Car dans ce cas, je pourrais voir s’il est possible de faire tourner la pipeline tous les jours, et d’update les artifacts uniquement si il y a une mise à jour de l’app, qu’en penses-tu ?
C’était le cumul des deux qui a fait exploser l’espace disque occupé. Mais, c’est surtout le fait de ne pas avoir mis en place la suppression automatique sur le job configure_fdroid. Ce point est lié à la doc GitLab qui ne précise pas ce point. Je me suis fait avoir au début. Réduire aussi la durée d’expiration de l’artefact sur le job pages est aussi bon à prendre.
On pourrait déjà remettre une pipeline par jours, mais je pense que ça ne vaille le coup, car ces trois projets (cesium, gchange et gecko) n’ont pas un débit de release plus élevé qu’hebdomadaire. Autrement, oui, tu peux développer cette fonctionnalité !
Ajouter l’app G1nkgo au dépôt serait aussi une bonne contribution !
p our être honnête, je suis très peu physionomiste, donc je t’ai pas reconnu sur le moment, et après coup je me suis dit “hé mais c’est hugo” et j’ai pas réussi à te retrouver après !
Le dépôt a déjà atteint 3.2Go en juste un mois, depuis la dernière fois ou on a 
