reviewdog
v0.20.3
ReviewDog fournit un moyen de publier des commentaires de révision aux services d'hébergement de code, tels que GitHub, automatiquement en intégrant avec les outils Linter avec facilité. Il utilise une sortie des outils de peluche et les publie comme un commentaire si les résultats sont dans le différentiel des correctifs à examiner.
ReviewDog prend également en charge l'exécution dans l'environnement local pour filtrer la sortie des outils de charpie par Diff.
Doc de conception
# Install the latest version. (Install it into ./bin/ by default).
$ curl -sfL https://raw.githubusercontent.com/reviewdog/reviewdog/master/install.sh | sh -s
# Specify installation directory ($(go env GOPATH)/bin/) and version.
$ curl -sfL https://raw.githubusercontent.com/reviewdog/reviewdog/master/install.sh | sh -s -- -b $( go env GOPATH ) /bin [vX.Y.Z]
# In alpine linux (as it does not come with curl by default)
$ wget -O - -q https://raw.githubusercontent.com/reviewdog/reviewdog/master/install.sh | sh -s [vX.Y.Z]Vous pouvez également utiliser la version Nightly ReviewDog pour essayer les dernières améliorations de revueDog chaque jour!
$ curl -sfL https://raw.githubusercontent.com/reviewdog/nightly/master/install.sh | sh -s -- -b $( go env GOPATH ) /bin steps :
- uses : reviewdog/action-setup@v1
with :
reviewdog_version : latest # Optional. [latest,nightly,v.X.Y.Z]Vous pouvez également installer ReviewDog à l'aide de Brew:
$ brew install reviewdog/tap/reviewdog
$ brew upgrade reviewdog/tap/reviewdog > scoop install reviewdog
$ go install github.com/reviewdog/reviewdog/cmd/reviewdog@latestReviewDog accepte un compilateur ou un résultat de linter de Stdin et l'analyse avec Scan-F comme «ErrorFormat» , qui est la fonction d'erreur de VIM.
Par exemple, si le format de résultat est {file}:{line number}:{column number}: {message} , ErrorFormat doit être %f:%l:%c: %m et vous pouvez le transmettre en tant que arguments -efm .
$ golint ./...
comment_iowriter.go:11:6: exported type CommentWriter should have comment or be unexported
$ golint ./... | reviewdog -efm= " %f:%l:%c: %m " -diff= " git diff FETCH_HEAD "| nom | description |
|---|---|
| % f | nom de fichier |
| % L | numéro de ligne |
| % c | numéro de colonne |
| % m | message d'erreur |
| %% | le seul caractère «%» |
| ... | ... |
Veuillez consulter ReviewDog / ErrorFormat et: H ErrorFormat si vous souhaitez gérer une sortie plus complexe. «ErrorFormat» peut gérer une sortie plus complexe comme un message d'erreur multi-lignes.
Vous pouvez également essayer ErrorFormat sur le terrain de jeu!
Avec cette fonction «ErrorFormat», ReviewDog peut prendre en charge n'importe quelle sortie d'outil avec facilité.
Mais, vous n'avez pas à écrire «ErrorFormat» dans de nombreux cas. ReviewDog prend en charge l'erreur prédéfinie pour les principaux outils.
Vous pouvez trouver le nom d'erreur de format par avis par reviewdog -list et vous pouvez l'utiliser avec -f={name} .
$ reviewdog -list
golint linter for Go source code - https://github.com/golang/lint
govet Vet examines Go source code and reports suspicious problems - https://golang.org/cmd/vet/
sbt the interactive build tool - http://www.scala-sbt.org/
...$ golint ./... | reviewdog -f=golint -diff= " git diff FETCH_HEAD "Vous pouvez ajouter «ErrorFormat» prédéfini pris en charge en contribuant à ReviewDog / ErrorFormat
ReviewDog prend en charge ReviewDog Diagnostic Format (RDFORMAT) en tant que format de diagnostic générique et il prend en charge les formats RDJSON et RDJSONL.
Ce RDFormat prend en charge des fonctionnalités riches telles que des commentaires à distance multiline, de la gravité, du code de règle avec URL et des suggestions de code.
$ < linter > | < convert-to-rdjson > | reviewdog -f=rdjson -reporter=github-pr-review
# or
$ < linter > | < convert-to-rdjsonl > | reviewdog -f=rdjsonl -reporter=github-pr-review
Vous pouvez utiliser Eslint-formatter-RDJSON pour sortir rdjson comme format de sortie Eslint.
$ npm install --save-dev eslint-formatter-rdjson
$ eslint -f rdjson . | reviewdog -f=rdjson -reporter=github-pr-reviewOu vous pouvez également utiliser ReviewDog / Action-Eslint pour les actions GitHub.
ReviewDog prend en charge Diff (format unifié) en tant que format d'entrée particulièrement utile pour les suggestions de code. ReviewDog peut s'intégrer à tous les outils ou formateurs de suggestions de code pour signaler les suggestions.
-f.diff.strip : option pour -f=diff : strip num composants principaux à partir de noms de fichiers diff (équivalent à 'patch -p') (par défaut est 1 pour git diff) (par défaut 1)
$ < any-code-fixer/formatter > # e.g. eslint --fix, gofmt
$ TMPFILE= $( mktemp )
$ git diff > " ${TMPFILE} "
$ git stash -u && git stash drop
$ reviewdog -f=diff -f.diff.strip=1 -reporter=github-pr-review < " ${TMPFILE} "Ou vous pouvez également utiliser ReviewDog / Action-Sugter pour les actions GitHub.
Si les outils de diagnostic prennent en charge le format de sortie DIFF, vous pouvez tuer directement le DIFF.
$ gofmt -s -d . | reviewdog -name= " gofmt " -f=diff -f.diff.strip=0 -reporter=github-pr-review
$ shellcheck -f diff $( shfmt -f . ) | reviewdog -f=diffReviewDog accepte également le format XML de contrôle. Si le Linter prend en charge le format CheckStyle comme format de rapport, vous pouvez utiliser -f = CheckStyle au lieu d'utiliser «ErrorFormat».
# Local
$ eslint -f checkstyle . | reviewdog -f=checkstyle -diff= " git diff "
# CI (overwrite tool name which is shown in review comment by -name arg)
$ eslint -f checkstyle . | reviewdog -f=checkstyle -name= " eslint " -reporter=github-checkDe plus, si vous souhaitez passer un autre format JSON / XML / etc ... pour revoirDog, vous pouvez écrire un convertisseur.
$ < linter > | < convert-to-checkstyle > | reviewdog -f=checkstyle -name= " <linter> " -reporter=github-pr-checkReviewDog prend en charge le format JSON SARIF 2.1.0. Vous pouvez utiliser ReviewDog avec -f = option Sarif.
# Local
$ eslint -f @microsoft/eslint-formatter-sarif . | reviewdog -f=sarif -diff= " git diff "
ReviewDog prend en charge la fonction de suggestions de code avec l'entrée RDFormat ou DIFF. Vous pouvez également utiliser ReviewDog / Action-Sugter pour les actions GitHub.
ReviewDog peut suggérer des modifications de code avec les résultats de diagnostic si un outil de diagnostic prend en charge les données de suggestions de code. Vous pouvez intégrer ReviewDog avec tous les outils de fixation de code et tout format de code avec l'entrée Diff.
Notez que tous les journalistes ne soutiennent pas les suggestions de code.
-reporter | Support de suggestion |
|---|---|
local | Non [1] |
github-check | Non [2] |
github-pr-check | Non [2] |
github-pr-review | D'ACCORD |
gitlab-mr-discussion | D'ACCORD |
gitlab-mr-commit | Non [2] |
gerrit-change-review | Non [1] |
bitbucket-code-report | Non [2] |
gitea-pr-review | Non [2] |
ReviewDog peut également être contrôlé via le fichier de configuration .reviewdog.yml au lieu des arguments "-f" ou "-efm".
Avec .reviewdog.yml, vous pouvez exécuter les mêmes commandes pour le service CI et l'environnement local, y compris l'intégration de l'éditeur avec facilité.
runner :
<tool-name> :
cmd : <command> # (required)
errorformat : # (optional if you use `format`)
- <list of errorformat>
format : <format-name> # (optional if you use `errorformat`. e.g. golint,rdjson,rdjsonl)
name : <tool-name> # (optional. you can overwrite <tool-name> defined by runner key)
level : <level> # (optional. same as -level flag. [info,warning,error])
# examples
golint :
cmd : golint ./...
errorformat :
- " %f:%l:%c: %m "
level : warning
govet :
cmd : go vet -all .
format : govet
your-awesome-linter :
cmd : awesome-linter run
format : rdjson
name : AwesomeLinter $ reviewdog -diff= " git diff FETCH_HEAD "
project/run_test.go:61:28: [golint] error strings should not end with punctuation
project/run.go:57:18: [errcheck] defer os.Setenv(name, os.Getenv(name))
project/run.go:58:12: [errcheck] os.Setenv(name, " " )
# You can use -runners to run only specified runners.
$ reviewdog -diff= " git diff FETCH_HEAD " -runners=golint,govet
project/run_test.go:61:28: [golint] error strings should not end with punctuation
# You can use -conf to specify config file path.
$ reviewdog -conf=./.reviewdog.yml -reporter=github-pr-checkLe format de sortie pour le projet de configuration du projet est l'un des formats suivants.
<file>: [<tool name>] <message><file>:<lnum>: [<tool name>] <message><file>:<lnum>:<col>: [<tool name>] <message>ReviewDog peut signaler les résultats à la fois dans l'environnement local et les services d'examen comme une intégration continue.
ReviewDog peut trouver des résultats nouvellement introduits en filtrant les résultats de Linter en utilisant DIFF. Vous pouvez passer la commande Diff en ARG -diff .
$ golint ./... | reviewdog -f=golint -diff= " git diff FETCH_HEAD "
GitHub-Pr-Check Reporter rapporte les résultats aux vérifications GitHub.
Vous pouvez modifier le niveau de rapport pour ce champ Reporter par level dans le fichier de configuration ou l'indicateur -level . Vous pouvez contrôler les résultats de vérification de l'état GitHub avec cette fonctionnalité. (par défaut: erreur)
| Niveau | Statut de github |
|---|---|
info | neutre |
warning | neutre |
error | échec |
Il existe deux options pour utiliser ce journaliste.
Exemple: .github / workflows / reviewdog.yml
- name : Run reviewdog
env :
REVIEWDOG_GITHUB_API_TOKEN : ${{ secrets.GITHUB_TOKEN }}
run : |
golint ./... | reviewdog -f=golint -reporter=github-pr-checkVoir aussi la section Actions GitHub. Vous pouvez également utiliser des actions publiques de revueDog GitHub.
ReviewDog CLI envoie une demande au serveur d'applications GitHub ReviewDog et aux résultats de la publication du serveur en tant que vérifications GitHub, car l'API de vérification n'est pris en charge que pour l'application GitHub et les actions GitHub.
REVIEWDOG_TOKEN ou exécutez CLI ReviewDog dans les fournisseurs de CI de confiance.https://reviewdog.app/gh/{owner}/{repo-name} . $ export REVIEWDOG_TOKEN= " <token> "
$ reviewdog -reporter=github-pr-checkRemarque: le jeton n'est pas requis si vous exécutez ReviewDog dans Travis ou AppVeyor.
Prudence
Comme décrit ci-dessus, GitHub-P-Check Reporter avec l'option 2 dépend du serveur d'applications GitHub ReviewDog. Le serveur s'exécute avec l'argent de poche de Haya14busa pour l'instant et je peux casser les choses, donc je ne peux pas m'assurer que le serveur fonctionne 24h et 365 jours.
Mise à jour: a commencé à obtenir un support par OpenCollective et GitHub Sponsor. Voir Soutenir ReviewDog
Vous pouvez utiliser GitHub-Pr-Review Reporter ou utiliser Run ReviewDog sous GitHub Actions si vous ne souhaitez pas dépendre du serveur ReviewDog.
C'est essentiellement la même chose que -reporter=github-pr-check sauf qu'il fonctionne non seulement pour la demande de traction mais aussi pour commit.
Vous pouvez créer un badge ReviewDog pour ce journaliste.
GitHub-Pr-Review Reporter rapporte les résultats à GitHub PullRequest Review Commentaires à l'aide du jeton d'accès API personnel GitHub. GitHub Enterprise est également pris en charge.
repo les référentiels privés ou public_repo pour les référentiels publics. $ export REVIEWDOG_GITHUB_API_TOKEN= " <token> "
$ reviewdog -reporter=github-pr-reviewPour GitHub Enterprise, définissez le point de terminaison de l'API par une variable d'environnement.
$ export GITHUB_API= " https://example.githubenterprise.com/api/v3/ "
$ export REVIEWDOG_INSECURE_SKIP_VERIFY=true # set this as you need to skip verifying SSLVoir la section Actions GitHub également si vous pouvez utiliser les actions GitHub. Vous pouvez également utiliser des actions publiques de revueDog GitHub.
GitHub-PR-Annotations utilise le format d'annotation des actions GitHub pour sortir des erreurs et des avertissements pour stdout , par exemple
::error line=11,col=41,file=app/index.md::[vale] reported by reviewdog ?%0A[demo.Spelling] Did you really mean 'boobarbaz'?%0A%0ARaw Output:%0A{"message": "[demo.Spelling] Did you really mean 'boobarbaz'?", "location": {"path": "app/index.md", "range": {"start": {"line": 11, "column": 41}}}, "severity": "ERROR"}
Ce journaliste nécessite un jeton API GitHub valide pour générer un DIFF, mais n'utilisera pas le jeton pour signaler les erreurs.
Version GitLab requise:> = V10.8.0
Gitlab-Mr-Discussion Reporter rapporte les résultats aux discussions Gitlab MergeRequest à l'aide du jeton d'accès API personnel Gitlab. Obtenez le jeton avec la portée api de https://gitlab.com/profile/personal_access_tokens.
$ export REVIEWDOG_GITLAB_API_TOKEN= " <token> "
$ reviewdog -reporter=gitlab-mr-discussion La variable d'environnement CI_API_V4_URL , définie automatiquement par GitLab CI (V11.7), sera utilisée pour découvrir l'URL de l'API GitLab.
Alternativement, GITLAB_API peut également être défini, auquel cas il a la priorité sur CI_API_V4_URL .
$ export GITLAB_API= " https://example.gitlab.com/api/v4 "
$ export REVIEWDOG_INSECURE_SKIP_VERIFY=true # set this as you need to skip verifying SSLGitlab-MR-Commit est similaire au journaliste de Gitlab-MR-Discussion mais rapporte les résultats à chaque engagement dans Gitlab MergeRequest.
Gitlab-Mr-Discussion est recommandé, mais vous pouvez utiliser Gitlab-Mr-Commit Reporter si votre version GitLab est sous V10.8.0.
$ export REVIEWDOG_GITLAB_API_TOKEN= " <token> "
$ reviewdog -reporter=gitlab-mr-commitGerrit-Change-Review Reporter rapporte les résultats du changement de Gerrit à l'aide d'API Gerrit REST.
Le journaliste prend en charge l'authentification de base et l'authentification basée sur Git-Cookie pour la déclaration des résultats.
Définissez les variables d'environnement GERRIT_USERNAME et GERRIT_PASSWORD pour l'authentification de base et mettez GIT_GITCOOKIE_PATH pour l'authentification basée sur les cookies GIT.
$ export GERRIT_CHANGE_ID=changeID
$ export GERRIT_REVISION_ID=revisionID
$ export GERRIT_BRANCH=master
$ export GERRIT_ADDRESS=http:// < gerrit-host > : < gerrit-port >
$ reviewdog -reporter=gerrit-change-review
BitBucket-Code-Report génère le rapport annoté Bitbucket Code Insights.
Pour l'instant, seul le mode no-filter est pris en charge, donc l'ensemble du projet est analysé à chaque course. Les rapports sont stockés par validation et peuvent être consultés par validation de l'interface utilisateur des pipelines Bitbucket ou dans la demande de traction. Dans la demande de traction, les lignes de code affectées seront annotées dans le DIFF, ainsi que vous pourrez filtrer les annotations par cette demande de traction ou à tous .
Si vous exécutez des pipelines Bitbucket, aucune configuration supplémentaire n'est nécessaire (même les informations d'identification). Si vous exécutez localement ou à partir d'un autre système CI, vous auriez besoin de fournir des informations d'identification API BitBucket:
BITBUCKET_USER et BITBUCKET_PASSWORDBITBUCKET_ACCESS_TOKEN $ export BITBUCKET_USER= " my_user "
$ export BITBUCKET_PASSWORD= " my_password "
$ reviewdog -reporter=bitbucket-code-report Pour publier un rapport sur le serveur Bitbucket, utilisez la variable BITBUCKET_SERVER_URL :
$ export BITBUCKET_USER= " my_user "
$ export BITBUCKET_PASSWORD= " my_password "
$ export BITBUCKET_SERVER_URL= " https://bitbucket.my-company.com "
$ reviewdog -reporter=bitbucket-code-reportExemple: .github / workflows / reviewdog.yml
name : reviewdog
on : [pull_request]
jobs :
reviewdog :
name : reviewdog
runs-on : ubuntu-latest
steps :
# ...
- uses : reviewdog/action-setup@v1
with :
reviewdog_version : latest # Optional. [latest,nightly,v.X.Y.Z]
- name : Run reviewdog
env :
REVIEWDOG_GITHUB_API_TOKEN : ${{ secrets.GITHUB_TOKEN }}
run : |
reviewdog -reporter=github-pr-check -runners=golint,govet
# or
reviewdog -reporter=github-pr-review -runners=golint,govet.github / workflows / ReviewDog
Seul github-check Reporter peut également fonctionner sur l'événement Push.
name : reviewdog (github-check)
on :
push :
branches :
- master
pull_request :
jobs :
reviewdog :
name : reviewdog
runs-on : ubuntu-latest
steps :
# ...
- name : Run reviewdog
env :
REVIEWDOG_GITHUB_API_TOKEN : ${{ secrets.GITHUB_TOKEN }}
run : |
reviewdog -reporter=github-check -runners=golint,govet Vous pouvez utiliser des actions publiques GitHub pour commencer à utiliser ReviewDog avec facilité! ?
Dockerfile ..env Files.... et plus sur Github Marketplace.
Actions manquantes? Consultez ReviewDog / Action-Template et créez une nouvelle action ReviewDog!
Veuillez ouvrir une demande de traction pour ajouter vos actions de revue créées ici. Je peux également placer vos référentiels sous ReviewDog org et co-manager les actions. Exemple: Action-Tflint.
GITHUB_TOKEN pour les demandes de traction d'un référentiel fourchu n'a pas accès à l'écriture pour vérifier l'API ni revoir l'API en raison de la restriction des actions GitHub.
Au lieu de cela, ReviewDog utilise les commandes de journalisation des actions GitHub pour publier les résultats comme des annotations similaires à github-pr-check Reporter.
Notez qu'il existe une limitation pour les annotations créées par les commandes de journalisation, telles que Max # des annotations par exécution. Vous pouvez vérifier le journal des actions GitHub pour voir les résultats complets dans de tels cas.
Comme github-check Reporter Support en cours d'exécution sur Commit, nous pouvons créer un badge d'action GitHub ReviewDog pour vérifier le résultat contre Master Commit par exemple. ?
Exemple:
<!-- Replace <OWNER> and <REPOSITORY>. It assumes workflow name is "reviewdog" -->
[](https://github.com/<OWNER>/<REPOSITORY>/actions?query=workflow%3Areviewdog+event%3Apush+branch%3Amaster)
Si vous utilisez -Reporter = GitHub-P-Check dans Travis CI, vous n'avez pas besoin de définir REVIEWDOG_TOKEN .
Exemple:
install :
- mkdir -p ~/bin/ && export PATH="~/bin/:$PATH"
- curl -sfL https://raw.githubusercontent.com/reviewdog/reviewdog/master/install.sh| sh -s -- -b ~/bin
script :
- reviewdog -conf=.reviewdog.yml -reporter=github-pr-check Stockez le jeton API GitHub par les clés de cryptage Travis.
$ gem install travis
$ travis encrypt REVIEWDOG_GITHUB_API_TOKEN= < token > --add env.globalExemple:
env :
global :
- secure : <token>
install :
- mkdir -p ~/bin/ && export PATH="~/bin/:$PATH"
- curl -sfL https://raw.githubusercontent.com/reviewdog/reviewdog/master/install.sh| sh -s -- -b ~/bin
script :
- >-
golint ./... | reviewdog -f=golint -reporter=github-pr-reviewExemples
Store REVIEWDOG_GITHUB_API_TOKEN (ou REVIEWDOG_TOKEN pour GitHub-PR-Check) dans les variables d'environnement - Circleci
version : 2
jobs :
build :
docker :
- image : golang:latest
steps :
- checkout
- run : curl -sfL https://raw.githubusercontent.com/reviewdog/reviewdog/master/install.sh| sh -s -- -b ./bin
- run : go vet ./... 2>&1 | ./bin/reviewdog -f=govet -reporter=github-pr-review
# Deprecated: prefer GitHub Actions to use github-pr-check reporter.
- run : go vet ./... 2>&1 | ./bin/reviewdog -f=govet -reporter=github-pr-check Store REVIEWDOG_GITLAB_API_TOKEN dans la variable GitLab CI.
reviewdog :
script :
- reviewdog -reporter=gitlab-mr-discussion
# Or
- reviewdog -reporter=gitlab-mr-commitAucune configuration supplémentaire n'est nécessaire.
pipelines :
default :
- step :
name : Reviewdog
image : golangci/golangci-lint:v1.31-alpine
script :
- wget -O - -q https://raw.githubusercontent.com/reviewdog/reviewdog/master/install.sh |
sh -s -- -b $(go env GOPATH)/bin
- golangci-lint run --out-format=line-number ./... | reviewdog -f=golangci-lint -reporter=bitbucket-code-reportVous pouvez utiliser ReviewDog pour publier des commentaires de revue de n'importe où avec les variables d'environnement suivantes.
| nom | description |
|---|---|
CI_PULL_REQUEST | Numéro de demande de tirage (par exemple 14) |
CI_COMMIT | Sha1 pour la construction actuelle |
CI_REPO_OWNER | Propriétaire du référentiel (par exemple "ReviewDog" pour https://github.com/reviewdog/errorformat) |
CI_REPO_NAME | Nom du référentiel (par exemple "errorformat" pour https://github.com/reviewdog/errorformat) |
CI_BRANCH | Branche [facultative] du commit |
$ export CI_PULL_REQUEST=14
$ export CI_REPO_OWNER=haya14busa
$ export CI_REPO_NAME=reviewdog
$ export CI_COMMIT= $( git rev-parse HEAD )et définissez un jeton si nécessaire.
$ REVIEWDOG_TOKEN= " <token> "
$ REVIEWDOG_GITHUB_API_TOKEN= " <token> "
$ REVIEWDOG_GITLAB_API_TOKEN= " <token> " Si un service CI ne fournit pas d'informations telles que l'identification de la demande Pull - ReviewDog peut les deviner par un nom de branche et commettre SHA. Passez simplement le drapeau guess :
$ reviewdog -conf=.reviewdog.yml -reporter=github-pr-check -guess$ export CI_PULL_REQUEST= ${ghprbPullId}
$ export CI_REPO_OWNER=haya14busa
$ export CI_REPO_NAME=reviewdog
$ export CI_COMMIT= ${ghprbActualCommit}
$ export REVIEWDOG_INSECURE_SKIP_VERIFY=true # set this as you need
# To submit via reviewdog server using github-pr-check reporter
$ REVIEWDOG_TOKEN= " <token> " reviewdog -reporter=github-pr-check
# Or, to submit directly via API using github-pr-review reporter
$ REVIEWDOG_GITHUB_API_TOKEN= " <token> " reviewdog -reporter=github-pr-review
# Or, to submit directly via API using github-pr-check reporter (requires GitHub App Account configured)
$ REVIEWDOG_SKIP_DOGHOUSE=true REVIEWDOG_GITHUB_API_TOKEN= " <token> " reviewdog -reporter=github-pr-check Par défaut ( -fail-level=none ) ReviewDog renvoie 0 en tant que code de sortie même s'il trouve des erreurs. ReviewDog quittera le code 1 avec -fail-level=[any,info,warning,error] Indicateur s'il trouve au moins 1 problème avec la gravité supérieure ou égale au niveau donné. Cela peut être utile lorsque vous l'utilisez comme étape de votre pipeline CI et que vous souhaitez marquer l'étape échoué si une erreur trouvée par Linter.
Vous pouvez également utiliser l'indicateur -level pour configurer le rapport par défaut Revel.
ReviewDog Filter Résultats par Diff et vous pouvez contrôler comment ReviewDog Filter Results by -filter-mode Indicateur. Les modes de filtre disponible sont comme ci-dessous.
added (par défaut)Résultats du filtre par lignes ajoutées / modifiées.
diff_contextRésultats du filtre par contexte Diff. IE Lignes modifiées + -N lignes (n = 3 par exemple).
fileFiltre Résultats par fichier ajouté / modifié. IE ReviewDog rapportera les résultats aussi longtemps qu'ils sont dans un fichier ajouté / modifié même si les résultats ne sont pas en diffuse.
nofilterNe filtrez aucun résultat. Utile pour publier les résultats autant que possible les commentaires et vérifier les autres résultats dans la console en même temps.
-fail-on-error fonctionne également avec n'importe quel mode filtre et peut assister à tous les résultats de tous les liners avec le mode nofilter .
Exemple:
$ reviewdog -reporter=github-pr-review -filter-mode=nofilter -fail-on-error Notez que tous les journalistes ne fournissent pas une prise en charge complète du mode filtre en raison de la limitation de l'API. EG github-pr-review Reporter utilise l'API GitHub Review, mais cette API ne prend pas en charge les commentaires de publication en dehors du contexte Diff, donc ReviewDog utilise la vérification de l'annotation comme secours pour publier ces commentaires [1].
-reporter -filter-mode | added | diff_context | file | nofilter |
|---|---|---|---|---|
local | D'ACCORD | D'ACCORD | D'ACCORD | D'ACCORD |
github-check | D'ACCORD | D'ACCORD | D'ACCORD | D'ACCORD |
github-pr-check | D'ACCORD | D'ACCORD | D'ACCORD | D'ACCORD |
github-pr-review | D'ACCORD | D'ACCORD | Partiellement pris en charge [1] | Partiellement pris en charge [1] |
github-pr-annotations | D'ACCORD | D'ACCORD | D'ACCORD | D'ACCORD |
gitlab-mr-discussion | D'ACCORD | D'ACCORD | D'ACCORD | Partiellement pris en charge [2] |
gitlab-mr-commit | D'ACCORD | Partiellement pris en charge [2] | Partiellement pris en charge [2] | Partiellement pris en charge [2] |
gerrit-change-review | D'ACCORD | D'ACCORD? [3] | D'ACCORD? [3] | Partiellement pris en charge? [2] [3] |
bitbucket-code-report | Non [4] | Non [4] | Non [4] | D'ACCORD |
gitea-pr-review | D'ACCORD | D'ACCORD | Partiellement pris en charge [2] | Partiellement pris en charge [2] |
Utilisez le drapeau -tee pour afficher les informations de débogage.
reviewdog -filter-mode=nofilter -teehaya14busa
Devenez sponsor GitHub pour chaque contributeur ou devenez un bailleur de fonds ou un sponsor d'OpenCollective.
