Telliot: Utilisez consisent logging au lieu de printf partout.

Créé le 26 sept. 2020  ·  9Commentaires  ·  Source: tellor-io/telliot

La base de code contient printf à de nombreux endroits, ce qui est facile à démarrer, mais lors de l'analyse ou du filtrage des journaux, cela soulève de nombreux problèmes plus tard avec la surveillance et le traçage.

un enregistreur doit être initialisé dans le package principal, puis transmis à tous les constructeurs de packages.

C'est un très bon package de journalisation
github.com/go-kit/kit/log

pour un exemple de mise en œuvre, regardez les projets thanos ou prometheus.

tous les printf-s commentés peuvent être remplacés par des journaux de débogage afin qu'ils ne soient affichés que lorsque le débogage est activé.
level.Debug(logger).Log("msg", "debug")

Important! Consultez les directives de codage du projet
https://github.com/tellor-io/telliot/blob/master/docs/coding-style-guide.md

good first issue help wanted .high

Tous les 9 commentaires

Je vais prendre celui-ci aujourd'hui !

Une mise à jour : c'est partiellement fait, mais il y a encore peu d'endroits avec printf et logrus.
TL-DR doit utiliser github.com/go-kit/kit/log partout. Il doit être passé en argument lors de l'initialisation des composants.

État du problème : 1. Ouvert 2. Commencé 3. Soumis 4. Terminé


__Ce numéro a maintenant un financement de 0,1 ETH (114,26 USD @ 1142,63 $/ETH) qui lui est attaché dans le cadre du fonds Tellor-io.__

@krasi-georgiev J'aimerais m'en occuper, mais après avoir lu vos suggestions sur Gitcoin et lu le code Telliot, je dirais qu'au lieu de changer tous les commentaires de fmt.Printf en level.Debug(logger).Log(... .) nous devons décider pour chaque situation ce qui a le plus de sens du point de vue de l'utilisateur.
J'utiliserais le débogage du journal lorsque la sortie devrait être utile pour inspecter un problème, davantage du point de vue du développeur, mais les situations où l'utilisateur s'attend à une sortie sur la console devraient être au niveau INFO. Comme par exemple
https://github.com/tellor-io/telliot/blob/master/pkg/ops/disputeOps.go#L249 -L255

    fmt.Printf("Dispute %s (%s):\n", dispute.DisputeId.String(), descString)
    fmt.Printf("    Accused Party: %s\n", reportedAddr.Hex())
    fmt.Printf("    Disputed by: %s\n", reportingMiner.Hex())
    fmt.Printf("    Created on:  %s\n", createdTime.Format("3:04 PM January 02, 2006 MST"))
    fmt.Printf("    Fee: %s TRB\n", util.FormatERC20Balance(uintVars[8]))
    fmt.Printf("    \n")
    fmt.Printf("    Value disputed for requestID %d:\n", dispute.RequestId.Uint64())

Corrigez-moi si j'ai tort, s'il-vous plait. Merci!

ouais très vrai ! Une autre règle est également que si un journal se produit une fois au démarrage, il est bien d'être une information, mais si cela se produit plusieurs fois dans une boucle, à moins que cela ne soit extrêmement important, dans la plupart des cas, il y a trop de bruit et cela devrait être débogué.

@krasi-georgiev Oui, il est logique de ne pas submerger l'utilisateur, mais je pense que dans les situations où vous souhaitez analyser les journaux avec un outil, changer de comportement peut être déroutant car c'est le seul retour que vous avez pour votre analyse, mais de toute façon nous trouverons le bon équilibre je pense. Je vais apporter quelques modifications ici et au fur et à mesure que j'en apprendrai plus sur ce projet, nous trouverons ce qui fonctionne pour une bonne expérience utilisateur.

une fois cela fait, vous devez également ajouter dans le même PR un peu plus de peluches au makefile comme

go-lint: check-git deps $(GOLANGCI_LINT) $(FAILLINT)
    $(call require_clean_work_tree,'detected not clean master before running lint, previous job changed something?')
    <strong i="6">@echo</strong> ">> verifying modules being imported"
    @$(FAILLINT) -paths "errors=github.com/pkg/errors" ./...
    @$(FAILLINT) -paths "fmt.{Print,Printf,Println,Sprint}" -ignore-tests ./...
    <strong i="7">@echo</strong> ">> linting all of the Go files GOGC=${GOGC}"
    @$(GOLANGCI_LINT) run
    <strong i="8">@echo</strong> ">> ensuring Copyright headers"
    <strong i="9">@go</strong> run ./scripts/copyright
    $(call require_clean_work_tree,'detected files without copyright, run make lint and commit changes')

les 2 lignes etra sont :

    @$(FAILLINT) -paths "errors=github.com/pkg/errors" ./...
    @$(FAILLINT) -paths "fmt.{Print,Printf,Println,Sprint}" -ignore-tests ./...

Cela forcera qu'il n'y a aucune instruction print nulle part et que pkg/errors est utilisé partout

État du problème : 1. Ouvert 2. Commencé 3. Soumis 4. Terminé


__Les travaux ont commencé__.

Ces utilisateurs ont chacun affirmé qu'ils pouvaient terminer le travail d'ici 265 ans, dans 6 mois.
Veuillez consulter leurs plans d'action ci-dessous :

1) g33kidd a postulé pour commencer le travail _(Bailleurs de fonds uniquement : approuver le travailleur | rejeter le travailleur )_.

Je vais m'y atteler, cela semblait être une chose intéressante à faire.
2) voanhcung a demandé à commencer le travail _(Bailleurs de fonds uniquement : approuver le travailleur | rejeter le travailleur )_.

D'accord [email protected]......................
3) therocketcat a été approuvé pour commencer les travaux.

J'ai regardé la base de code et les exemples de projets mentionnés précédemment que vous avez mentionnés.

D'après les exemples, j'ai déduit que si les fonctions utilisant printf n'ont pas de constructeur, le journal de bord doit être une dépendance injectée dans la fonction elle-même. Si ce n'est pas le cas, j'aimerais avoir des éclaircissements.

Et dans le package principal (telliot/cmd/telliot/main.go), ils seront configurés à l'aide de la fonction SetupLogger de util et transmis au constructeur ou injectés directement dans la fonction (en tant que premier paramètre).

En regardant également la base de code, je ne trouve aucun printfs commenté, donc je suppose que vous voulez dire printfs en général?

Ouvert pour en discuter davantage si j'ai mal compris la tâche RocketCat # 3507
4) mendesfabio a postulé pour commencer le travail _(Bailleurs de fonds uniquement : approuver le travailleur | rejeter le travailleur )_.

Je viens de vérifier le repo et il semble que certains printf-s aient été remplacés (et cela m'a aidé à comprendre comment le faire). Nous avons encore 10 fichiers avec printf-s et je vais changer cela.
5) rodrigoadriandiaz a postulé pour commencer le travail _(Bailleurs de fonds uniquement : approuver le travailleur | rejeter le travailleur )_.

je pourrais le faire, en remplaçant tous les appels à printf pour une implémentation du package de journalisation mentionné ci-dessus, je pourrais commencer à travailler dessus demain
6) raulcorreia7 a demandé à commencer le travail _(Bailleurs de fonds uniquement : approuver le travailleur | rejeter le travailleur )_.

Salut,
Ce serait une évidence,
DM moi.
7) coder4520 a demandé à commencer le travail _(Bailleurs de fonds uniquement : approuver le travailleur | rejeter le travailleur )_.

Je suppose que ce serait un très bon premier projet pour commencer.
8) adiprerepa a demandé à commencer le travail _(Bailleurs de fonds uniquement : approuver le travailleur | rejeter le travailleur )_.

Ce serait très facile - il suffit de trouver et de remplacer printf dans la journalisation, puis de vérifier.
9) xf3rno a demandé à commencer le travail _(Bailleurs de fonds uniquement : approuver le travailleur | rejeter le travailleur )_.

J'effectuerais la tâche demandée ; remplacez tous les journaux actuels par la bibliothèque golang logger de google (assez léger : https://github.com/google/logger) et étendez chaque message en fonction du contexte (débogage, avertissement, etc.).

En savoir plus sur la page Détails du problème Gitcoin .

État du problème : 1. Ouvert 2. Commencé 3. Soumis 4. Terminé


__Un travail pour 0,1 ETH (167,47 USD à 1674,72 $/ETH) a été soumis par__ :


Cette page vous a été utile?
0 / 5 - 0 notes