Meme si la version est la depuis un certain temps nous avons mis les nouveautés dedans qu’a l’instant. Ca sera une grosse version du core (d’ou 4.5). Dans les nouveautés marquante il y a :
suppression de l’ancien système de cache (et donc des dépendances composer de celui-ci)
suppression des dépendances composer GitHub et webdav (aucune perte de fonction au niveau du core tout a été refait maison)
Mise en place d’un système de queue (en beta pour le moment), qui permet de crée des queue de traitement. Pour le moment le système est très simpliste toute les minutes il regarde toute les queues et lance l’élément le plus vieux de chacune des queues. Une fois ce fonctionnement valider il sera bien sur améliorer pour éviter le délai d’attente de 1 minutes entre chaque traitement d’un élément de la queue.
Passage des scénarios en mode instanciation. Avant si vous aviez plusieurs lancement simultané d’un meme scénario les tags pouvaient se marcher dessus (si ils étaient different), ce n’est plus le cas maintenant. Vous avez aussi maintenant plus de tags et surtout un tag pour avoir la valeur de la commande qui a déclenchée le scénario au moment du lancement du scénario. Le changelog ainsi que la doc explique tout cela.
Voila pour les changements majeur pour le moment (il y en a d’autre et je vous laisse consulter le changelog complet). Dans la suite prévu pour cette version ca sera de s’attaquer a la partie composer ou l’idée est de réduire le nombre de lib utiliser et surtout de virer le dossier vendor du GitHub pour faire une installation propre des dépendances composer lors de la mise a jour du core ou de l’installation (déjà le cas en Debian 12). Dans cette optique pouvez vous me dire ce que vous utilisez comme lib composer du core :
La nouvelle gestion du cache ne sera pas déjà effective en 4.4.10 ? On en avait discuté sur un autre fil, notamment du lifetime. Ou alors, l’ancien système de cache sera encore présent en 4.4.10 mais aussi le nouveau et l’ancien sera supprimé en 4.4.11 ?
La queue, c’est une FIFO de tâches (commandes shell, … ?) à effectuer ?
C’est dans le but de lisser la charge du système ?
le problème de guzzle (dont j’aimerais bien me débarrasser), c’est quand tu utilises un lib qui en dépend
ok, je m’arrangerai pour synchroniser lorsque le core « 4.5 » sera sorti du coup
si tu veux bien confirmer ici la liste définitive que tu gardes lorsque tu as fait les vérif nécessaires;
je surveillerai les commit mais, comme d’autres probablement, je risque de rater l’info
Pour l’instant en Debian 12 php 8 j’ai pas vu de soucis flagrant et je pense pas pouvoir réduire plus (un jour peut être expression language ou au final je m’en sert que pour des calculs ca se trouve un eval ca fera pareil…)
Mise a jour : il est fort probable que la lib monologue soit supprimée aussi, elle est très bien faite mais pour l’usage qu’on en fait un simple append file marche tout aussi bien et simplifie pas mal le code. A noter que pour le moment le log en syslog ne sera plus possible si la demande est forte je verrais pour developper tout cas mais je doute que ca soit vraiment utile.
Je ne sais pas si c’est lié et je n’ai pas encore eu beaucoup de temps pour chercher, j’ai évidement fait les vérifs de base (update cli, http.error etc) mais rien trouvé pour l’instant
si je vais dans la config jeedom, j’ai cette erreur:
Je reproduis pas sur 7 jeedoms donc je comprends pas trop. La le seul moyen pour trouver est chiant mais j’en vois pas d’autre c’est de supprimer du code petit a petit de la page d’administration jusqu’a trouver le coupable. La c’est clairement une array qui est une string mais pour trouver laquelle (sans meme le pourquoi) je vois pas d’autre solution.
ok j’ai trouvé, voila le message que je reçois suite aux appels http sur https://api.github.com/repos/jeedom/core/...:
{"branchs":{"message":"API rate limit exceeded for x.x.x.x. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https:\/\/docs.github.com\/rest\/overview\/resources-in-the-rest-api#rate-limiting"},"tags":{"message":"API rate limit exceeded for x.x.x.x. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https:\/\/docs.github.com\/rest\/overview\/resources-in-the-rest-api#rate-limiting"}}
x.x.x.x est mon ip
je sais que c’est sensé être une api publique sans besoin d’authentification;
j’ai un ticket ouvert chez eux car j’étais déjà tombé dessus pour un autre projet
ils me disent qu’il n’y a pas de problème, que rien n’est bloqué mais … c’est pas vrai ! et c’est au point mort depuis des mois
bref… je suis complètement bloqué avec ce problème chez github mais je vais relancer pour comprendre
pour le core, le minimum serait de valider que le retour est valide et qu’il peut être utilisé pour éviter que ca crash derrière
c’est bon, la liste est vide du coup mais ca ne crash pas
pour l’instant c’est suffisant je pense, tant pis si liste vide, ca ne devrait pas arriver en théorie
et en plus juste après mon test l’appel n’était plus bloqué (ca arrive de temps en temps), du coup j’ai de nouveau la liste remplie
à voir si ca tient, mais c’est un autre problème