reviewdog
v0.20.3
ReviewDog bietet eine Möglichkeit, Kommentare zu Code -Hosting -Diensten wie GitHub automatisch zu veröffentlichen, indem sie mit einfachen Linter -Tools integriert werden. Es verwendet eine Ausgabe von Lint -Tools und veröffentlicht sie als Kommentar, wenn die Ergebnisse im Diff von Patches zu überprüfen sind.
ReviewDog unterstützt auch das Laufen in der lokalen Umgebung, um die Ausgabe von Lint -Tools nach Diff zu filtern.
Design Doc
# 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]Sie können auch die nächtliche RezensionDog -Veröffentlichung verwenden, um jeden Tag die neuesten Rezensionsdog -Verbesserungen auszuprobieren!
$ 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]Sie können auch ReviewDog mit Brew installieren:
$ brew install reviewdog/tap/reviewdog
$ brew upgrade reviewdog/tap/reviewdog > scoop install reviewdog
$ go install github.com/reviewdog/reviewdog/cmd/reviewdog@latestRezensionDog akzeptiert alle Compiler- oder Linterergebnisse von STDIN und analysiert es mit scan-f wie 'ERRAGEFORMAT' , dem Port der Fehlerformat-Funktion von VIM.
Wenn das Ergebnisformat beispielsweise {file}:{line number}:{column number}: {message} lautet, sollte ERRAGEFORMAT %f:%l:%c: %m sein und Sie können es als -efm -Argumente übergeben.
$ 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 "| Name | Beschreibung |
|---|---|
| %F | Dateiname |
| %l | Zeilennummer |
| %C | Spaltennummer |
| %M | Fehlermeldung |
| %% | der einzelne '%' Charakter |
| ... | ... |
Weitere Informationen finden Sie unter reviewdog/errorFormat und: H FehlerFormat, wenn Sie eine komplexere Ausgabe erfüllen möchten. 'ERRAGEFORMAT' kann eine komplexere Ausgabe wie eine Multi-Line-Fehlermeldung verarbeiten.
Sie können auch Fehlerformat auf dem Spielplatz ausprobieren!
Mit dieser Funktion "ERROFORMAT" kann ReviewDog alle Toolausgaben mühelos unterstützen.
Sie müssen jedoch in vielen Fällen nicht 'Fehlerformat' schreiben. ReviewDog unterstützt das vordefinierte Fehlerformat für wichtige Tools.
Sie können den verfügbaren FehlerFormat -Namen per reviewdog -list finden und verwenden ihn mit -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 "Sie können unterstützte vordefinierte 'ERRAGEFORMAT' hinzufügen, indem Sie zur Überprüfung von Dog/ERRAGEFORMAT beitragen
ReviewDog unterstützt das Überprüfungsdog -Diagnoseformat (RDFormat) als generisches diagnostisches Format und unterstützt sowohl RDJSON- als auch RDJSONL -Formate.
Dieser RDFormat unterstützt reichhaltige Funktionen wie Multiline -Rang -Kommentare, Schweregrad, Regelcode mit URL und Codevorschläge.
$ < linter > | < convert-to-rdjson > | reviewdog -f=rdjson -reporter=github-pr-review
# or
$ < linter > | < convert-to-rdjsonl > | reviewdog -f=rdjsonl -reporter=github-pr-review
Sie können Eslint-Formatter-Rdjson verwenden, um rdjson als ESINT-Ausgangsformat auszugeben.
$ npm install --save-dev eslint-formatter-rdjson
$ eslint -f rdjson . | reviewdog -f=rdjson -reporter=github-pr-reviewOder Sie können auch ReviewDog/action-eSlint für GitHub-Aktionen verwenden.
ReviewDog unterstützt Difff (Unified Format) als Eingabeformat, das besonders für Codevorschläge nützlich ist. ReviewDog kann in Tools oder Formatierungen für Codevorschläge integriert werden, um Vorschläge zu melden.
-f.diff.strip : Option für -f=diff : Streifennummere Hauptkomponenten aus Diff -Dateinamen (entsprechend 'patch -p') (Standard ist 1 für Git Diff) (Standard 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} "Oder Sie können auch RezensionDog/Action-Sugughester für GitHub-Aktionen verwenden.
Wenn diagnostische Werkzeuge das Diff -Ausgangsformat unterstützen, können Sie den Diff direkt reiten.
$ gofmt -s -d . | reviewdog -name= " gofmt " -f=diff -f.diff.strip=0 -reporter=github-pr-review
$ shellcheck -f diff $( shfmt -f . ) | reviewdog -f=diffReviewDog akzeptiert auch das XML -Format des Checkstyle. Wenn der Linter -Unterstützungs -CheckStyle -Format als Berichtsformat unterstützt wird, können Sie -f = CheckStyle verwenden, anstatt "Fehlerformat" zu verwenden.
# 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-checkWenn Sie ein anderes JSON/XML/etc ... -Format übergeben möchten, können Sie einen Konverter schreiben.
$ < linter > | < convert-to-checkstyle > | reviewdog -f=checkstyle -name= " <linter> " -reporter=github-pr-checkReviewDog unterstützt das Sarif 2.1.0 JSON -Format. Sie können RezensionDog mit -F = Sarif -Option verwenden.
# Local
$ eslint -f @microsoft/eslint-formatter-sarif . | reviewdog -f=sarif -diff= " git diff "
ReviewDog unterstützt die Funktionsfunktion für die Code -Vorschläge mit RDFormat oder Diff -Eingabe. Sie können auch RezensionDog/Action-Sugughester für GitHub-Aktionen verwenden.
ReviewDog kann Codeänderungen zusammen mit diagnostischen Ergebnissen vorschlagen, wenn ein diagnostisches Tool Code -Vorschläge Daten unterstützt. Sie können ReviewDog auch in alle Codefixier -Tools und alle Codeformierer mit Diff -Eingabe integrieren.
Beachten Sie, dass nicht alle Reporter Unterstützung für Codevorschläge bieten.
-reporter | Vorschlagsunterstützung |
|---|---|
local | Nein [1] |
github-check | Nein [2] |
github-pr-check | Nein [2] |
github-pr-review | OK |
gitlab-mr-discussion | OK |
gitlab-mr-commit | Nein [2] |
gerrit-change-review | Nein [1] |
bitbucket-code-report | Nein [2] |
gitea-pr-review | Nein [2] |
ReviewDog kann auch über die Konfigurationsdatei .reviewdog.yml anstelle von "-f" oder "-efm" -Argumenten gesteuert werden.
Mit .Reviewdog.yml können Sie dieselben Befehle sowohl für den CI -Service als auch für die lokale Umgebung ausführen, einschließlich der Integration von Editors mühelos.
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-checkDas Ausgabeformat für Projektkonfigurationen ist eines der folgenden Formate.
<file>: [<tool name>] <message><file>:<lnum>: [<tool name>] <message><file>:<lnum>:<col>: [<tool name>] <message>ReviewDog kann die Ergebnisse sowohl in der lokalen Umgebung als auch in der Überprüfungsdienste als kontinuierliche Integration melden.
RezensionDog finden neu eingeführte Ergebnisse, indem die Ergebnisse von Stoßern mit Diff gefiltert werden. Sie können den Diff -Befehl als -diff arg übergeben.
$ golint ./... | reviewdog -f=golint -diff= " git diff FETCH_HEAD "
GitHub-PR-Check Reporter meldet Ergebnisse an GitHub-Schecks.
Sie können die Berichtsebene für diesen Reporter nach level -Feld in der Konfigurationsdatei oder im Flag -level -Flag ändern. Sie können die Ergebnisse der GitHub -Statusprüfung mit dieser Funktion steuern. (Standard: Fehler)
| Ebene | Github -Status |
|---|---|
info | neutral |
warning | neutral |
error | Versagen |
Es gibt zwei Optionen, um diesen Reporter zu verwenden.
Beispiel: .Github/Workflows/ReviewDog.yml
- name : Run reviewdog
env :
REVIEWDOG_GITHUB_API_TOKEN : ${{ secrets.GITHUB_TOKEN }}
run : |
golint ./... | reviewdog -f=golint -reporter=github-pr-checkSiehe Abschnitt GitHub -Aktionen auch. Sie können auch öffentliche Überprüfungsdog -Github -Aktionen verwenden.
ReviewDog CLI sendet eine Anfrage zum Überprüfen von Dog Github App Server und die Serverpost -Ergebnisse als GitHub -Überprüfungen, da die API -API nur für GitHub -App- und GitHub -Aktionen unterstützt wird.
REVIEWDOG_TOKEN oder run ReviewDog CLI in vertrauenswürdigen CI -Anbietern.https://reviewdog.app/gh/{owner}/{repo-name} . $ export REVIEWDOG_TOKEN= " <token> "
$ reviewdog -reporter=github-pr-checkHinweis: Token ist nicht erforderlich, wenn Sie RezensionDog in Travis oder Appveyor ausführen.
Vorsicht
Wie oben beschrieben, hängt GitHub-PR-Check-Reporter mit Option 2 vom ReviewDog Github App Server ab. Der Server läuft vorerst mit Haya14busas Taschengeld und ich kann die Dinge brechen, sodass ich nicht sicherstellen kann, dass der Server 24 Stunden und 365 Tage läuft.
Update: Erhielt Unterstützung durch OpenCollective und Github -Sponsor. Siehe Unterstützung von ReviewDog
Sie können einen GitHub-pr-Review-Reporter verwenden oder Run ReviewDog unter GitHub-Aktionen verwenden, wenn Sie nicht auf den Überprüfungsdog-Server abhängig sind.
Es ist im Grunde dasselbe wie -reporter=github-pr-check außer es funktioniert nicht nur für Pull-Anfrage, sondern auch für Commit.
Sie können einen Überprüfungsdog -Abzeichen für diesen Reporter erstellen.
GitHub-Pr-Review-Reporter berichtet von Github PullRequest-Überprüfung Kommentare mit GitHub Personal API-Zugriffstoken. Github Enterprise wird ebenfalls unterstützt.
repo auf private Repositories oder public_repo Repositories. $ export REVIEWDOG_GITHUB_API_TOKEN= " <token> "
$ reviewdog -reporter=github-pr-reviewLegen Sie für Github Enterprise den API -Endpunkt durch eine Umgebungsvariable fest.
$ export GITHUB_API= " https://example.githubenterprise.com/api/v3/ "
$ export REVIEWDOG_INSECURE_SKIP_VERIFY=true # set this as you need to skip verifying SSLSiehe Abschnitt mit GitHub -Aktionen auch, wenn Sie GitHub -Aktionen verwenden können. Sie können auch öffentliche Überprüfungsdog -Github -Aktionen verwenden.
Github-pr-Annotationen verwendet das Annotationsformat für GitHub-Aktionen, um Fehler und Warnungen für stdout EG auszugeben
::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"}
Dieser Reporter benötigt ein gültiges Github -API -Token, um einen Diff zu generieren, verwendet das Token jedoch nicht, um Fehler zu melden.
Erforderliche GitLab -Version:> = v10.8.0
GitLab-MR-Diskussion-Reporter berichtet von GitLab MergeRequest-Diskussionen mit Gitlab Personal API-Zugriffstoken. Holen Sie sich das Token mit api -Bereich von https://gitlab.com/profile/personal_access_tokens.
$ export REVIEWDOG_GITLAB_API_TOKEN= " <token> "
$ reviewdog -reporter=gitlab-mr-discussion Die Umgebungsvariable CI_API_V4_URL , die automatisch von Gitlab CI (V11.7) definiert ist, wird verwendet, um die GitLab -API -URL herauszufinden.
Alternativ kann auch GITLAB_API definiert werden. In diesem Fall wird es Vorrang vor CI_API_V4_URL haben.
$ 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-Befehl ähnelt dem GitLab-MR-Diskussion-Reporter, meldet jedoch die Ergebnisse für jeden Commit in Gitlab MergeRequest.
GitLab-MR-Diskussion wird empfohlen, aber Sie können den GitLab-MR-Commit-Reporter verwenden, wenn Ihre GitLab-Version unter v10.8.0 liegt.
$ export REVIEWDOG_GITLAB_API_TOKEN= " <token> "
$ reviewdog -reporter=gitlab-mr-commitGerrit-Change-Review-Reporter meldet Ergebnisse, die Gerrit unter Verwendung von Gerrit Rest-APIs ändern.
Der Reporter unterstützt grundlegende Authentifizierung und Git-Cookie-basierte Authentifizierung für die Berichterstattung.
Setzen Sie die Umgebungsvariablen GERRIT_USERNAME und GERRIT_PASSWORD für die grundlegende Authentifizierung und setzen Sie GIT_GITCOOKIE_PATH für die auf Git Cookie-basierte Authentifizierung.
$ 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 generiert den kommentierten Bitbucket-Code-Insights-Bericht.
Im Moment wird nur der no-filter -Modus unterstützt, sodass das gesamte Projekt bei jedem Lauf gescannt wird. Berichte werden pro Komitee gespeichert und können pro Commit von Bitbucket Pipelines UI oder in Pull -Anfrage angesehen werden. In der Pull Request UI werden im Diff -Annotation die von der UI betroffene Code -Zeilen angezeigt, und Sie können die Annotationen durch diese Pull -Anfrage oder alles filtern.
Wenn Sie aus Bitbucket -Pipelines ausgeführt werden, ist keine zusätzliche Konfiguration erforderlich (auch Anmeldeinformationen). Wenn Sie lokal oder aus einem anderen CI -System ausgeführt werden, müssen Sie Bitbucket -API -Anmeldeinformationen bereitstellen:
BITBUCKET_USER und BITBUCKET_PASSWORDBITBUCKET_ACCESS_TOKEN festlegen $ export BITBUCKET_USER= " my_user "
$ export BITBUCKET_PASSWORD= " my_password "
$ reviewdog -reporter=bitbucket-code-report Um einen Bericht an den Bitbucket -Server zu veröffentlichen, verwenden Sie die 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-reportBeispiel: .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
Nur github-check Reporter kann auch auf dem Push-Event ausgeführt werden.
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 Sie können öffentliche Github -Aktionen verwenden, um mit Leichtigkeit ReviewDog zu verwenden! ?
Dockerfile aus..env Dateien aus.... und mehr über Github Marketplace.
Fehlende Aktionen? Schauen Sie sich ReviewDog/Action-Template an und erstellen Sie eine neue RezensionDog-Aktion!
Bitte öffnen Sie eine Pull -Anfrage, um Ihre erstellten Überprüfungsdogaktionen hier hinzuzufügen. Ich kann Ihre Repositorys auch in Rezensiondog org und den Co-Acaint the Acts einsetzen. Beispiel: Action-Tflint.
GITHUB_TOKEN für Pull -Anfragen von einem Forked -Repository hat weder Schreibzugriff, um API zu überprüfen, noch die API zu überprüfen, da GitHub -Aktionen einschränken.
Stattdessen verwendet ReviewDog Protokollierungsbefehle von GitHub-Aktionen, um Ergebnisse als Anmerkungen zu veröffentlichen, die dem github-pr-check -Reporter ähneln.
Beachten Sie, dass es eine Einschränkung für Annotationen gibt, die durch Protokollierungsbefehle wie maximale Annotationen pro Lauf erstellt werden. Sie können das GitHub -Aktionsprotokoll überprüfen, um in solchen Fällen die vollständigen Ergebnisse zu sehen.
Als Unterstützung github-check Reporter, die im Commit ausgeführt werden, können wir das Ergebnis des Master Commit beispielsweise über das Ergebnis von Master Commit überprüfen. ?
Beispiel:
<!-- Replace <OWNER> and <REPOSITORY>. It assumes workflow name is "reviewdog" -->
[](https://github.com/<OWNER>/<REPOSITORY>/actions?query=workflow%3Areviewdog+event%3Apush+branch%3Amaster)
Wenn Sie -Reporter = github-pr-Check in Travis CI verwenden, müssen Sie REVIEWDOG_TOKEN nicht festlegen.
Beispiel:
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 Speichern Sie Github API -Token durch Travis -Verschlüsselungsschlüssel.
$ gem install travis
$ travis encrypt REVIEWDOG_GITHUB_API_TOKEN= < token > --add env.globalBeispiel:
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-reviewBeispiele
Speichern Sie REVIEWDOG_GITHUB_API_TOKEN (oder REVIEWDOG_TOKEN für github-pre-Check) in Umgebungsvariablen-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 in GitLab CI -Variable.
reviewdog :
script :
- reviewdog -reporter=gitlab-mr-discussion
# Or
- reviewdog -reporter=gitlab-mr-commitEs ist keine zusätzliche Konfiguration erforderlich.
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-reportSie können RezensionDog verwenden, um Überprüfungskommentare von überall mit den folgenden Umgebungsvariablen zu veröffentlichen.
| Name | Beschreibung |
|---|---|
CI_PULL_REQUEST | Pull -Anforderungsnummer (z. B. 14) |
CI_COMMIT | SHA1 für den aktuellen Build |
CI_REPO_OWNER | Repository -Eigentümer (z. B. "ReviewDog" für https://github.com/reviewdog/Errorformat) |
CI_REPO_NAME | Repository -Name (z. B. "ERRAGEFORMAT" für https://github.com/reviewdog/Errorformat) |
CI_BRANCH | [optional] Zweig des Commits |
$ export CI_PULL_REQUEST=14
$ export CI_REPO_OWNER=haya14busa
$ export CI_REPO_NAME=reviewdog
$ export CI_COMMIT= $( git rev-parse HEAD )und setzen Sie bei Bedarf ein Token.
$ REVIEWDOG_TOKEN= " <token> "
$ REVIEWDOG_GITHUB_API_TOKEN= " <token> "
$ REVIEWDOG_GITLAB_API_TOKEN= " <token> " Wenn ein CI -Dienst keine Informationen wie Pull Request ID angibt, kann man es mit einem Zweignamen erraten und SHA begehen. Gib einfach die Flagge 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 Standardmäßig ( -fail-level=none ) reviewDog wird 0 als Exit -Code zurückgegeben, auch wenn er Fehler findet. ReviewDog beendet Code 1 mit -fail-level=[any,info,warning,error] Flag, wenn es mindestens 1 Probleme mit Schweregrad über oder gleich der angegebenen Ebene findet. Dies kann hilfreich sein, wenn Sie es als Schritt in Ihrer CI -Pipeline verwenden und den Schritt markieren möchten, wenn ein Fehler, der durch einen Strinter gefunden wurde, fehlgeschlagen ist.
Sie können auch -level -Flag verwenden, um die Standard -Berichts -Revel zu konfigurieren.
Überprüfen Sie die Ergebnisse des Filters nach Diff und Sie können steuern, wie überprüft wird, wie die Ergebnisse des Filters nach -filter-mode -Flag Ergebnissen ergeben. Die verfügbaren Filtermodi finden Sie unten.
added (Standard)Filterergebnisse durch hinzugefügte/modifizierte Zeilen filtern.
diff_contextFilterergebnisse nach Diff -Kontext. IE änderte Zeilen +-n-Zeilen (n = 3 zum Beispiel).
fileFilterergebnisse nach hinzugefügter/geänderter Datei. IE ReviewDog meldet die Ergebnisse, solange sie in der hinzugefügten/modifizierten Datei sind, auch wenn die Ergebnisse nicht in der tatsächlichen Diff der Fall sind.
nofilterFiltern Sie keine Ergebnisse. Nützlich, um Ergebnisse als Kommentare so weit wie möglich zu veröffentlichen und gleichzeitig andere Ergebnisse in der Konsole zu überprüfen.
-fail-on-error arbeitet auch mit jedem Filtermodus und kann alle Ergebnisse von Lintern mit nofilter -Modus erfassen.
Beispiel:
$ reviewdog -reporter=github-pr-review -filter-mode=nofilter -fail-on-error Beachten Sie, dass nicht alle Reporter aufgrund der API -Einschränkung den Filtermodus voll und ganz unterstützen. EG github-pr-review Reporter verwendet die GitHub-Überprüfungs-API. Diese API unterstützt jedoch keine Posten von Kommentaren außerhalb des Diff-Kontextes. ÜberprüfungDog verwendet die Überprüfung der Annotation als Fallback, um diese Kommentare zu veröffentlichen [1].
-reporter -filter-mode | added | diff_context | file | nofilter |
|---|---|---|---|---|
local | OK | OK | OK | OK |
github-check | OK | OK | OK | OK |
github-pr-check | OK | OK | OK | OK |
github-pr-review | OK | OK | Teilweise unterstützt [1] | Teilweise unterstützt [1] |
github-pr-annotations | OK | OK | OK | OK |
gitlab-mr-discussion | OK | OK | OK | Teilweise unterstützt [2] |
gitlab-mr-commit | OK | Teilweise unterstützt [2] | Teilweise unterstützt [2] | Teilweise unterstützt [2] |
gerrit-change-review | OK | OK? [3] | OK? [3] | Teilweise unterstützt? [2] [3] |
bitbucket-code-report | Nein [4] | Nein [4] | Nein [4] | OK |
gitea-pr-review | OK | OK | Teilweise unterstützt [2] | Teilweise unterstützt [2] |
Verwenden Sie die Flagge -tee , um Debug -Informationen zu zeigen.
reviewdog -filter-mode=nofilter -teeHaya14busa
Werden Sie GitHub -Sponsor für jeden Mitwirkenden oder ein Unterstützer oder Sponsor von OpenCollective.
