Sauf que c’est déjà le principe de la page « Découverte » ça !
Donc pourquoi ne pas juste augmenter la limite ?
Parce que déjà à 100 appareils … c’est illisible ^^ Alors 950 … je te laisse imaginer
Et sans champs de recherche … humhum ^^ apres c’est possible hein (le CTRL+F du navigateur fonctionne) mais côté user friendly … ^^
Si tu as une autre propo, avec plaisir 
J’augmente la limite, et je rajoute un filtre de recherche !
Parfait ^^ Merci beaucoup ^^
Du coup @Terdious il faut qu’on se mette d’accord sur notre manière de fonctionner. Moi je n’ai absolument rien contre le fait que tu fasses des PR, mais je n’ai pas créé cette intégration pour te filer du travail en plus !
Je te laisse me dire, moi je suis ouvert à tout !!
Ouioui !! aucune inquietude (et le boulot ne m’embête jamais, ça nous apporte à tous ^^
Je met juste beaucoup de temps a te rédiger le message de réponse, pour qu’il soit au mieux ficeler et compréhensible en le faisant avec l’IA (présentation bien meilleur). Bon du coup il est long, mais je relis tout/corrige, normalement tout est clair, et au final tu verras pas si compliqué ^^
Chaque petite Intégration Externe devient un micro projet Gladys indépendant ^^
Hop :
Damn… ça laqisse de la marge ça ^^
J’ai testé, le search marche bien !
C’est mergé, ça partira dans la prochaine release de Gladys (aujourd’hui)
Yeees bienvenue !!
Normal, c’est les débuts, on est tous passés par là !
Mais oui, à éviter absolument : main c’est la branche que tout le monde utilise. Une modif qui casse, et c’est tes utilisateurs qui la prennent en pleine figure.
La règle simple
Chaque modification (sauf assurance totale sur un truc ultra sommaire) doit se faire sur une branche à part, que tu montes en image taguée :dev, ou :dev-tartempion pour un test spécifique avec quelqu’un.
Concrètement, ton cycle devient :
main ──► branche de travail ──► (test image :dev) ──► retour dans main
Et pas grand-chose de plus. En ligne de commande c’est littéralement :
git checkout main
git pull
git checkout -b fix-ip-gateway # ta branche de travail
# ... tu bosses, tu commits ...
git push -u origin fix-ip-gateway
Deux avantages immédiats :
- si ça casse chez quelqu’un, tu reviens en arrière en supprimant/annulant une branche, pas en démêlant 15 commits mélangés dans
main; - tu peux avoir plusieurs chantiers en parallèle sans qu’ils se marchent dessus.
Les PR : pas obligatoires, mais très pratiques
À noter : les PR ne sont pas obligatoires. Tu peux très bien faire main → branche de travail → main tout seul, sans jamais ouvrir de PR.
C’est surtout utile :
- quand quelqu’un de l’extérieur veut te proposer quelque chose (mon cas) ;
- quand tu veux partager une avancée / une préparation avant de la sortir.
Perso je bosse beaucoup en PR même sur mes propres repos, parce que :
- tu as un vrai historique, lisible, avec le pourquoi de chaque changement ;
- tu peux commenter directement dans le code ;
- tu peux avoir des sujets au long cours sans avoir à te souvenir de quelle branche il s’agissait — tout le contexte est dans la PR.
Ce que tu vas concrètement devoir faire d’une PR
Alors bonne nouvelle : tu as déjà tout ce qu’il faut dans ton repo
D’abord, le plus important : une PR ne change RIEN chez toi tant que tu ne cliques pas.
Tant que tu n’as pas appuyé sur le bouton vert, ton main est intact, ton image :latest est intacte, tes utilisateurs ne voient rien. Zéro risque. Et tu peux fermer une PR sans la merger, sans aucune justification. Même si c’est mieux avec je ne te le cache pas ^^
Ensuite, dans l’ordre :
1. Le CI vérifie le code à ta place — c’est déjà en place
Ton .github/workflows/ci.yml se déclenche déjà on: pull_request. À chaque PR il lance automatiquement :
npm run format:check(Prettier)npm run lint(ESLint)npm test
Tu n’as donc rien à relire pour savoir si c’est cassé : tu regardes en bas de la PR, coche verte = ça passe, croix rouge = ça passe pas. C’est tout.
2. Tu peux demander la review à ton IA
Tu lui donnes le lien de la PR et tu lui demandes de la relire et de commenter directement dedans. Moi je verrai ses commentaires et je corrigerai. C’est là que les allers-retours se font, sans que tu aies à écrire une ligne.
3. Tu construis une image de test — là aussi c’est déjà en place
Ton .github/workflows/build.yml a déjà un workflow_dispatch avec un champ image-tag qui prend par défaut le nom de la branche, et surtout il ne touche pas à :latest. Donc :
Onglet Actions → workflow Build → bouton Run workflow → tu choisis la branche → Run
et tu récupères ghcr.io/guim31/gladys-integration-unifi:<nom-de-la-branche> que tu tires dans ton Docker pour tester en vrai. Tes utilisateurs sur :latest ne voient rien passer.
(Petit détail : ton build.yml ne se déclenche automatiquement que sur les tags v*, c’est-à-dire tes releases. Le déclenchement manuel ci-dessus est donc bien le bon chemin pour tester une branche.)
4. Tu merges (ou pas)
Si tes tests sont OK : gros bouton vert « Merge pull request » en bas de la PR, puis « Confirm merge ». Deux clics. Tu peux aussi demander à ton IA de le faire.
Si ça ne te convient pas : tu commentes, ou tu fermes. Aucun souci.
En résumé, tu n’as jamais à lire mon code si tu ne veux pas. Tu regardes la coche verte, tu testes l’image, tu cliques.
Un point sur le fork => Et donc les PR qui apparaissent chez toi
Comment on s’organise concrètement (et tu gardes TOUS les droits)
Je précise, parce que c’est important : je ne te demande aucun droit sur ton repo. Je fais exactement ce que je fais sur le repo de Gladys — je forke, je bosse sur mon fork, je te propose une PR. Je ne peux ni pousser chez toi, ni merger. Tu es le seul à pouvoir appuyer sur le bouton. C’est le fonctionnement standard de l’open source, et c’est très bien comme ça.
Et pour les tests, pas besoin que tu builds quoi que ce soit : je te livre l’image en même temps que la PR.
Le déroulé
- Je bosse sur une branche de mon fork.
- Je lance le build chez moi — ton
build.ymlmarche tel quel dans un fork, il calcule l’image avecghcr.io/${GITHUB_REPOSITORY,,}et n’écrase jamaislatest. Ça me sort par exempleghcr.io/terdious/gladys-integration-unifi:fix-ip-gateway. - Je rends ce package public chez moi.
- J’ouvre la PR chez toi, et je mets l’adresse de l’image directement dans la description, avec le manifeste à copier-coller.
- Toi tu installes cette image dans ton Gladys, tu testes, et tu me dis.
- Si c’est bon : bouton vert. Sinon : tu commentes, ou tu fermes.
Tu n’as donc rien à builder, rien à configurer, et rien à désinstaller.
Comment tu installes mon image (2 champs à remplir)
Dans Gladys : Intégrations → Installer depuis GitHub → « Mode développeur : installer depuis une image Docker »
- champ Image Docker → tu colles l’adresse que je te donne dans la PR ;
- champ Manifeste (JSON, optionnel) → tu colles le JSON que je te donne juste en dessous.
Et c’est tout. Deux copier-coller.
Deux ou trois choses à savoir
Ça s’installe À CÔTÉ de ta version actuelle, tu ne casses rien.
Gladys construit le selector différemment selon le mode d’install : ext-guim31-gladys-integration-unifi pour ton install normale, ext-dev-unifi-network pour une install par image. Deux selectors différents = les deux intégrations cohabitent tranquillement. Tu gardes ta prod qui tourne, tu testes à côté, et quand tu as fini tu désinstalles juste celle de test.
Pourquoi je dois te donner le manifeste à coller ?
Normalement Gladys sait le lire tout seul dans les labels de l’image (le label io.gladysassistant.manifest). Mais ton Dockerfile n’en pose aucun et ton build.yml n’en passe pas non plus, donc l’install échouerait sur un MANIFEST_NOT_FOUND. D’où le copier-coller manuel — sans gravité, c’est exactement à ça que sert le champ optionnel.
Du coup, je te propose ça comme toute première PR : ajouter ce label à l’image. C’est 2 lignes, ça ne touche aucun code fonctionnel, et après ça n’importe qui (toi le premier) pourra installer une image de test en collant juste son nom, sans manifeste. Ça t’améliore ton propre confort de dev pour toutes les fois suivantes — et ça te fait voir le mécanisme d’une PR de bout en bout sans le moindre risque. Idéal pour se faire la main 
Un point d’attention pour les tests
Comme les deux intégrations tournent en parallèle, elles découvrent les mêmes équipements. Or dans Gladys le selector d’un appareil est unique au niveau global. Donc :
- pour vérifier ce qu’une PR change (les paramètres IP, les features de ports qui apparaissent ou non, les noms) → l’écran de découverte de l’instance de test suffit largement, tu n’ajoutes rien, aucun risque ;
- pour piloter réellement un port PoE depuis l’instance de test → il faut d’abord supprimer les appareils concernés côté prod, sinon tu auras une erreur au moment de les ajouter. Rien de cassé, juste un message d’erreur dans la carte, mais autant le savoir.
Et à terme
Quand tu seras à l’aise, le confort en plus c’est de te créer une branche dev chez toi :
git checkout main
git checkout -b dev
git push -u origin dev
Tu y merges les PR au fil de l’eau (ça ne publie toujours rien, latest ne bouge pas), tu builds ton image :dev depuis Actions → Build → Run workflow → branche dev, tu testes plusieurs changements d’un coup, et tu ne merges vers main que quand tu es content. Mais ce n’est pas nécessaire pour démarrer.
Sur les équipements dédoublés
Alors là je vais te rassurer : ce n’est pas la faute de Gemini, et ton code était probablement bon.
Ce que tu as vu n’est pas un problème de nommage de tes features, c’est le comportement de l’écran de découverte de Gladys : sur ces petites cartes, Gladys affiche la catégorie de la feature, pas son nom.
La preuve est dans mes propres captures du post précédent :
- sur la carte Dream Machine Pro, on lit
Présence/Débit/Débit— alors que dans tongateway.jsces features s’appellent en réalitéStatus,WAN Upload SpeedetWAN Download Speed. DeuxDébitidentiques à l’écran, deux noms bien distincts dans le code ; - et surtout, sur la carte « Switch PoE : SW-CAMPING-02 », on lit quand même 4 ×
Commutateur. Autrement dit : le dédoublement n’a pas résolu le problème que tu cherchais à résoudre — les ports restent indistinguables sur cet écran, séparés ou pas
Alors que dans le JSON des devices découverts (ma première capture), tes noms sont parfaits : Port 1 (SW-MAISON-01 / Port 19). Ils sont bien là, ils sont bien construits.
Test de 30 secondes si tu veux vérifier : ajoute un switch à Gladys, puis va ajouter les ports sur le dashboard, tu auras les bons noms. Tu verras les vrais noms (Port 1 (…), Port 3 (…), etc.), et tu les retrouveras aussi dans les sélecteurs de features quand tu construis une scène.
Donc si tu es d’accord, on peut fusionner sans crainte : un switch = un équipement, présence + ports ensemble, tout reste identifiable. Le vrai gain c’est le nombre de devices et la cohérence
Voilà, dis-moi ce que tu préfères sur le fork vs collaborateur, et par quel point tu veux qu’on commence. Je te propose de démarrer par l’IP locale / IP publiques de la gateway : c’est le plus autonome, ça touche un seul fichier, et ça te fera une première PR « pour la route » histoire de voir le mécanisme en vrai sans risque
Merci beaucoup pour ce message TRÈS complet !
Comme je l’ai déjà expliqué : je ne suis pas développeur, je n’ai aucune formation là-dedans. Ce projet existe parce que l’IA me permet aujourd’hui de construire des choses que je n’aurais jamais pu écrire moi-même. Donc quand tu dis que je n’ai jamais à lire ton code si je ne veux pas… ça tombe bien ^^ je ne saurais pas le juger de toute façon. Et c’est très bien comme ça : je préfère largement te faire confiance sur le fond et me concentrer sur ce que je sais faire, tester chez moi pour de vrai.
Donc le système fork + PR me va parfaitement. Comme ça je vais voir passer chaque
changement un par un, avec le pourquoi écrit à côté.
Ce que tu m’expliques sur « tant que tu ne cliques pas, rien ne bouge » me rassure. J’avais l’impression qu’une PR c’était déjà un pied dans la porte. Là je comprends que je garde la main du début à la fin, et ça change tout dans ma façon d’aborder le truc.
Pour l’ordre, je te suis à 100% :
- la PR du label dans le Dockerfile, pour que je voie le mécanisme en entier
sur un truc à risque zéro ; - puis l’IP locale / les IPs publiques de la gateway.
Sur les équipements dédoublés : merci pour les détails et surtout de m’avoir dit que ce n’était pas forcément une erreur de ma part. Je n’avais pas du tout compris que l’écran de découverte affichait la catégorie et pas le nom de la feature — du coup j’avais « réparé » quelque chose qui n’était pas cassé. Je pars du principe que tu as raison : on fusionne, un switch = un équipement. Je peux essayer de faire cette partie dans une PR de mon coté pour me faire la main !
Et je note la règle « une modif = une branche », je m’y mets aussi pour mes
propres modifs, Claude est quand même un super pote pour ces choses là 
Je vais avoir des questions bêtes en cours de route, je préfère te prévenir
Merci de prendre tout ce temps !!!
Petite avancée de mon côté : j’ai fait la fusion des switches et
fait ma première PR ! J’emploi le « je » mais on aura tous compris qui se cache derrière
Un matériel = un équipement maintenant.
C’est mergé dans main mais je n’ai pas fait de release.
Bref, je suis prêt pour tes PR quand tu veux
Pour apporter ma petite pierre à l’édifice, j’ai testé de mon côté la version 1.5.2 et la récupération des éléments fonctionnent sans problème