Oui, du coup, pour la release stable, il suffit de pointer sur https://git.duniter.org/nodes/typescript/duniter/wikis/Releases. Lorsque tu auras exécuté la publication de la release (donc lorsqu’on aura décidé qu’elle est stable — action publish dans le pipeline), cette page sera mise à jour automatiquement.
1 Like
Là, ça atteints 740Mb, donc une augmentation depuis le dernier relevé, et j’ai pas éteint l’ordi, mon nœud calcul des blocs et juste là il attends de meilleures conditions de preuve.
Oui ça je le savais déjà, ma question n’étais pas la, ma question était de savoir s’il était possible de récupérer le tag de la dernière release stable via une requete curl, comme on le fait actuellement avec github pour le bouton en haut du site.
Je ne comprends pas : quelle requête ? Sur le site, il y a un bouton. Ce bouton indique le numéro de la dernière version stable. Est-ce ce libellé qui est mis à jour automatiquement par une requête curl ? Si c’est le cas, non, je n’ai pas prévu cela. Mais si tu me donnes la requête utilisée actuellement, je peux peut-être voir s’il est possible de faire quelque chose… 
Oui c’est ça.
Le code est ici : website_fr/pelican-themes/pelican-bootstrap3/templates/base.html at master · duniter/website_fr · GitHub
1 Like
Alors en fait, il est possible de faire quelque chose de juste un peu plus complexe :
-
Récupérer la page des releases avec l’API Gitlab
GET https://git.duniter.org/api/v4/projects/47/wikis/Releases
-
Dans le résultat, lire la valeur de content
-
Extraire le texte situé entre “<placeholder content="tag">” et “</placeholder>”
Par contre, il me semble que le code devra être exécuté sur le poste d’une personne authentifiée avec au moins les droits développeur. Mais s’il y a des problèmes de droits, on pourra quand même récupérer le texte sans passer par l’API.
Pour suivi :
De ce que j’observe (je fais plus de vérifications que je n’en poste ici), c’est en dents de scie. Mais pour l’instant, la consommation ne fait que monter.
Ceci dit mon noeud autorise 50 connexions entrantes et sortantes pour WS2P, alors je ne sais pas si d’une part j’attendrai un palier à un moment donné, ni si c’est lié à WS2P d’autre part 
Nouveau point : à l’instant à 670-700Mb, mêmes conditions que préalablement :
ordi pas éteint depuis la mise en route du nœud
le nœud calcul
précision, j’ai mon %CPU réglé à 60 depuis le début, ce qui explique sans doute un process exe à 40-46% et donc le plus consommateur de mémoire
Ça se stabilise :
Je suis passé par une phase à plus de 450 Mo, mais ça redescend sans arrêt.
On peut continuer les mesures jusqu’à dimanche, qu’en pensez-vous ?
Perso je pense qu’il n’y a aucune fuite mémoire et qu’on peut pousser la 1.6.18 en stable la semaine prochaine. Sauf si le souci sur GT est avéré, mais, il y avait des nœuds en 1.6.18 sur les deux branches (celle ou le membre est partie et celle ou il n’est pas partie). Je pense donc que ce n’est pas lié au code du cœur, mais a une corruption de données lié a un réseau chaotique.
Le problème présent sur Ğ1-Test ne concernera Ğ1 qu’à partir du 8 mars (car l’exclusion concerne un non-renouvellement d’adhésion). S’il y a un véritable bug à corriger, nous aurons le temps de le débusquer et le corriger avec un hotfix sur la 1.6.18.
Donc pour la 1.6, il ne reste que le possible soucis de mémoire. Je suis du même avis que toi, je penche pour la non-fuite.
2 Likes
Normal que je viens de perdre mon status de membre sur g1test alors que j’ai renouvellé mon adhésion cet aprem ?
Pourtant je l’ai fait bien après le fork, et après m’être synchro sur la bonne branche, avec Cesium connecté directement à mon noeud.
heu il est toujours en cours le fork, le réseau vas un peu mieux mais il est encore divisé !
Je suis bien synchro sur la chaine la plus longue, donc mon renouvellement de dévrait pas disparaitre comme ça.
Ce n’est pas si simple… il n’a pas forcément disparu mais aucun noeud ne l’a écris. Quand le réseau est divisé certains documents se propagent mal car sont refusés par certain nœuds selon leur vision de la monnaie. On a déjà eu plein de renouvellements réussis sur g1-test et vue l’état actuellement pourave du réseau je penche a 80% de certitude pour un aléas réseau et non un bug.
Il faudrait éteindre les noeuds sur le fork non ?
haha mais on ne peut pas.
Je vexu dire : il faut que les personnes sur le fork le fasse.
1 Like