Ça n'a pas l'air aussi simple que de changer la valeur "50" vu la gueule de la PR (dans un langage du diable ne plus).
Il a complètement changé la façon dont est géré le champ mais je ne sais pas si c'était obligatoire ou si c'est juste son choix pour homogénéiser ou améliorer plus largement le code :jap:
Bon, là c'était déjà fait. Mais si t'as le code source, tu corrige toi même. [:paydaybear:3] Surtout pour un truc genre limité à x caractères.
Ça n'a pas l'air aussi simple que de changer la valeur "50" vu la gueule de la PR (dans un langage du diable ne plus).
Gauteng
Bon, là c'était déjà fait. Mais si t'as le code source, tu corrige toi même. [:paydaybear:3] Surtout pour un truc genre limité à x caractères.
J'avais raconté la fois où j'avais corrigé une tâche Azure DevOps pour nos déploiements internes? Bug bloquant pour notre déploiement automatisé, je regarde, je corrige. Pas le temps de regarder comment faire notre propre version de façon clean, je drop mon fix dans le cache de notre agent, il n'y a pas de vérification que le code n'a pas été modifié, ça marche. Je me dis que ça va être chiant de faire ça à chaque nouvelle version de la tâche, je fais bug report et PR. Et là un indien de chez MS me répond c'est bien t'as bug report, fix, et PR mais et ce que tu peux kindly aussi écrire le test. [:tim_coucou]
Reverse-aigritude, pour une fois :
Je bossais sur un dashboard grafana avec un panel basé sur une requête API. Le plugin utilisé pour ça (Infinity) nécessite d'indiquer dans la configuration de la datadource le(s) fqdn autorisés pour éviter qu'un utilisateur de grafana envoie des credentials vers un host random. Le champ n'autorise que 50 caractères et mon fqdn est plus long [:cerveau manust] Je vais sur le github du plugin sans grand espoir, je trouve une issue qui en parle, je vois que l'auteur du plugin a bien pris en compte le problème, je continue à scroller, problème fixé, merge dans main et nouveau package release il y a 2j :love:
