reviewdog
v0.20.3
O ReviewDog fornece uma maneira de publicar comentários para revisar os serviços de hospedagem de código, como o GitHub, automaticamente integrando -se com qualquer ferramenta de linter com facilidade. Ele usa uma saída de ferramentas de fiapos e as publica como um comentário se as descobertas estiverem no Diff of Patches para revisar.
O ReviewDog também suporta em execução no ambiente local para filtrar a saída de ferramentas de lint pelo Diff.
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]Você também pode usar o Nightly ReviewDog Release para experimentar as mais recentes melhorias no ReviewDog todos os dias!
$ 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]Você também pode instalar o ReviewDog usando o Brew:
$ brew install reviewdog/tap/reviewdog
$ brew upgrade reviewdog/tap/reviewdog > scoop install reviewdog
$ go install github.com/reviewdog/reviewdog/cmd/reviewdog@latestO ReviewDog aceita qualquer resultado do compilador ou linter do stdin e o analisa com o Scan-F como 'ErrorFormat' , que é a porta do recurso ErroFormat do VIM.
Por exemplo, se o formato de resultado for {file}:{line number}:{column number}: {message} , o erro deformat deve ser %f:%l:%c: %m e você pode passar como argumentos -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 "| nome | descrição |
|---|---|
| %f | Nome do arquivo |
| %l | Número da linha |
| %c | Número da coluna |
| %m | mensagem de erro |
| %% | o único personagem '%' |
| ... | ... |
Consulte ReviewDog/ErrorFormat e: H ErrorFormat se você deseja lidar com uma saída mais complexa. 'ErrorFormat' pode lidar com uma saída mais complexa, como uma mensagem de erro de várias linhas.
Você também pode tentar o ErrorFormat no playground!
Com esse recurso 'ErrorFormat', o ReviewDog pode suportar qualquer saída de ferramenta com facilidade.
Mas você não precisa escrever 'ErrorFormat' em muitos casos. O ReviewDog suporta o ErrorFormat predefinido para as principais ferramentas.
Você pode encontrar o nome do ErrorFormat disponível por reviewdog -list e pode usá -lo com -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 "Você pode adicionar 'ErrorFormat' predefinido suportado contribuindo para o ReviewDog/ErrorFormat
O ReviewDog suporta o Formato de Diagnóstico do ReviewDog (RDFFORMAT) como um formato de diagnóstico genérico e suporta formatos RDJSON e RDJSONL.
Este rdformat suporta recursos ricos, como comentários à distância multilina, gravidade, código de regras com URL e sugestões de código.
$ < linter > | < convert-to-rdjson > | reviewdog -f=rdjson -reporter=github-pr-review
# or
$ < linter > | < convert-to-rdjsonl > | reviewdog -f=rdjsonl -reporter=github-pr-review
Você pode usar o ESLint-formatter-rdjson para gerar rdjson como formato de saída ESLint.
$ npm install --save-dev eslint-formatter-rdjson
$ eslint -f rdjson . | reviewdog -f=rdjson -reporter=github-pr-reviewOu você também pode usar o ReviewDog/Action-eslint para ações do GitHub.
O ReviewDog suporta DIFF (Formato Unificado) como um formato de entrada especialmente útil para sugestões de código. O ReviewDog pode se integrar a quaisquer ferramentas ou formatados de sugestões de código para relatar sugestões.
-f.diff.strip : opção para -f=diff : tira num componentes principais dos nomes de arquivos diff (equivalente a 'patch -p') (o padrão é 1 para o git diff) (padrão 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 você também pode usar o ReviewDog/Action-sugestester para ações do GitHub.
Se as ferramentas de diagnóstico suportarem o formato de saída diff, você poderá tubar o diferencial diretamente.
$ gofmt -s -d . | reviewdog -name= " gofmt " -f=diff -f.diff.strip=0 -reporter=github-pr-review
$ shellcheck -f diff $( shfmt -f . ) | reviewdog -f=diffO ReviewDog também aceita o formato XML de estilo de seleção também. Se o linter suportar o formato de estilo de verificação como formato de relatório, você poderá usar -f = checkstyle em vez de usar '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-checkAlém disso, se você quiser passar por outro formato JSON/XML/etc ... para revisar, pode escrever um conversor.
$ < linter > | < convert-to-checkstyle > | reviewdog -f=checkstyle -name= " <linter> " -reporter=github-pr-checkO ReviewDog suporta o formato Sarif 2.1.0 JSON. Você pode usar o ReviewDog com -f = Sarif.
# Local
$ eslint -f @microsoft/eslint-formatter-sarif . | reviewdog -f=sarif -diff= " git diff "
O REVISTDOG suporta o recurso de sugestões de código com a entrada RDFormat ou DIFF. Você também pode usar o ReviewDog/Action-sugestester para ações do GitHub.
O ReviewDog pode sugerir alterações de código, juntamente com os resultados de diagnóstico se uma ferramenta de diagnóstico suportar dados de sugestões de código. Você pode integrar o ReviewDog com qualquer ferramenta de fixação de código e qualquer formatador de código com entrada de diff também.
Observe que nem todos os repórteres fornecem suporte para sugestões de código.
-reporter | Suporte de sugestão |
|---|---|
local | Não [1] |
github-check | Não [2] |
github-pr-check | Não [2] |
github-pr-review | OK |
gitlab-mr-discussion | OK |
gitlab-mr-commit | Não [2] |
gerrit-change-review | Não [1] |
bitbucket-code-report | Não [2] |
gitea-pr-review | Não [2] |
O ReviewDog também pode ser controlado pelo arquivo de configuração .reviewDog.yml em vez de argumentos "-f" ou "-efm".
Com .reviewDog.yml, você pode executar os mesmos comandos para o serviço de IC e o ambiente local, incluindo integração do editor com facilidade.
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-checkO formato de saída para a execução baseado no projeto é um dos seguintes formatos.
<file>: [<tool name>] <message><file>:<lnum>: [<tool name>] <message><file>:<lnum>:<col>: [<tool name>] <message>O ReviewDog pode relatar resultados no ambiente local e revisar os serviços como integração contínua.
O ReviewDog pode encontrar descobertas recentemente introduzidas filtrando os resultados do linhador usando o DIFF. Você pode passar o comando diff como -diff arg.
$ golint ./... | reviewdog -f=golint -diff= " git diff FETCH_HEAD "
O Github-Pr-Check Reporter relata os resultados das verificações do GitHub.
Você pode alterar o nível de relatório para este campo de repórter por level no arquivo de configuração ou sinalizador -level . Você pode controlar os resultados do status do GitHub com esse recurso. (Padrão: erro)
| Nível | Status do github |
|---|---|
info | neutro |
warning | neutro |
error | falha |
Existem duas opções para usar este repórter.
Exemplo: .github/workflows/reviewdog.yml
- name : Run reviewdog
env :
REVIEWDOG_GITHUB_API_TOKEN : ${{ secrets.GITHUB_TOKEN }}
run : |
golint ./... | reviewdog -f=golint -reporter=github-pr-checkVeja a seção Ações do GitHub também. Você também pode usar as ações do Public ReviewDog GitHub.
O ReviewDog CLI envia uma solicitação para o ReviewDog Github App Server e os resultados do servidor Post como verificações do GitHub, porque a API de verificação é suportada apenas para ações do aplicativo e Github do GitHub.
REVIEWDOG_TOKEN ou Run ReviewDog CLI em provedores de CI confiáveis.https://reviewdog.app/gh/{owner}/{repo-name} . $ export REVIEWDOG_TOKEN= " <token> "
$ reviewdog -reporter=github-pr-checkNOTA: O token não é necessário se você executar o ReviewDog em Travis ou AppVeyor.
Cuidado
Conforme descrito acima, o repórter do Github-Pr-Ver-CHECK com a opção 2 depende do servidor de aplicativos do ReviewDog Github. O servidor está em execução com o dinheiro do Haya14busa por enquanto e posso quebrar as coisas, por isso não posso garantir que o servidor esteja em execução 24h e 365 dias.
ATUALIZAÇÃO: Começou a obter suporte do OpenCollective e GitHub Patrocinator. Consulte o suporte do ReviewDog
Você pode usar o repórter do Github-Pr-Review ou usar o Run ReviewDog em ações do GitHub se não quiser depender do servidor ReviewDog.
É basicamente o mesmo que -reporter=github-pr-check exceto que funciona não apenas para solicitação de tração, mas também para comprometer.
Você pode criar o crachá do ReviewDog para este repórter.
O Github-Pr-Review Review relata os resultados dos comentários do GitHub PullRequest usando o token de acesso da API pessoal do GitHub. O GitHub Enterprise também é suportado.
repo de repositórios privados ou public_repo para repositórios públicos. $ export REVIEWDOG_GITHUB_API_TOKEN= " <token> "
$ reviewdog -reporter=github-pr-reviewPara o GitHub Enterprise, defina o terminal da API por uma variável de ambiente.
$ export GITHUB_API= " https://example.githubenterprise.com/api/v3/ "
$ export REVIEWDOG_INSECURE_SKIP_VERIFY=true # set this as you need to skip verifying SSLConsulte a seção Ações do GitHub também se você puder usar ações do GitHub. Você também pode usar as ações do Public ReviewDog GitHub.
O Github-Pr-Annatações usa o formato de anotação de ações do github para gerar erros e avisos para stdout , por exemplo,
::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"}
Este repórter exige um token da API do GitHub válido para gerar um diferencial, mas não usará o token para relatar erros.
Versão GitLab necessária:> = v10.8.0
O GitLab-Mr-Discussion Reporter relata resultar em discussões do GitLab Mergerequest usando o token de acesso da API pessoal do GitLab. Obtenha o token com o escopo api em https://gitlab.com/profile/personal_access_tokens.
$ export REVIEWDOG_GITLAB_API_TOKEN= " <token> "
$ reviewdog -reporter=gitlab-mr-discussion A variável de ambiente CI_API_V4_URL , definida automaticamente pelo GitLab CI (v11.7), será usada para descobrir o URL da API GitLab.
Como alternativa, GITLAB_API também pode ser definido; nesse caso, terá precedência sobre 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 SSLO GITLAB-MR-Commit é semelhante ao repórter de discussão do GitLab-Mr, mas relata resulta em cada compromisso no Gitlab Mergerequest.
Recomenda-se a discussão do GitLab-Mr, mas você pode usar o GITLAB-MR-COMMIT Reporter se sua versão do GitLab estiver no V10.8.0.
$ export REVIEWDOG_GITLAB_API_TOKEN= " <token> "
$ reviewdog -reporter=gitlab-mr-commitGerrit-Review Review Reports Resultados para alterações do Gerrit usando as APIs REST GERRIT.
O repórter suporta autenticação básica e autenticação baseada no Git-Cookie para relatar resultados.
Defina as variáveis de ambiente GERRIT_USERNAME e GERRIT_PASSWORD para obter autenticação básica e coloque GIT_GITCOOKIE_PATH para autenticação baseada em cookie 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
O relatório do código Bitbucket gera o relatório Annotated Bitbucket Code Insights.
Por enquanto, apenas o modo no-filter é suportado, para que todo o projeto seja digitalizado em todas as execuções. Os relatórios são armazenados por compromisso e podem ser visualizados de acordo com a UI do Bitbucket Pipelines ou na solicitação de tração. Na solicitação de tração, as linhas de código afetadas pela interface do usuário serão anotadas no DIFF, assim como você poderá filtrar as anotações por essa solicitação de tração ou tudo .
Se estiver executando a partir de pipelines do Bitbucket, nenhuma configuração adicional é necessária (mesmo credenciais). Se executar localmente ou de algum outro sistema de IC, você precisará fornecer credenciais da API Bitbucket:
BITBUCKET_USER e BITBUCKET_PASSWORDBITBUCKET_ACCESS_TOKEN $ export BITBUCKET_USER= " my_user "
$ export BITBUCKET_PASSWORD= " my_password "
$ reviewdog -reporter=bitbucket-code-report Para postar um relatório no servidor Bitbucket, use BITBUCKET_SERVER_URL Variável:
$ export BITBUCKET_USER= " my_user "
$ export BITBUCKET_PASSWORD= " my_password "
$ export BITBUCKET_SERVER_URL= " https://bitbucket.my-company.com "
$ reviewdog -reporter=bitbucket-code-reportExemplo: .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
Somente github-check Reporter também pode ser executado no evento 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 Você pode usar ações públicas do GitHub para começar a usar o ReviewDog com facilidade! ?
Dockerfile ..env .... e mais no mercado do Github.
Ações ausentes? Confira o ReviewDog/Action-Template e crie uma nova ação do ReviewDog!
Por favor, abra uma solicitação de tração para adicionar suas ações de revisão criadas aqui. Também posso colocar seus repositórios em ReviewDog Org e co-mantiver as ações. Exemplo: Action-tflint.
GITHUB_TOKEN para solicitações de tração de um repositório bifurcado não tem acesso de gravação para verificar a API nem revisar a API devido à restrição de ações do GitHub.
Em vez disso, o ReviewDog usa os comandos de log de ações do GitHub para publicar resultados como anotações semelhantes ao repórter github-pr-check .
Observe que há uma limitação para anotações criadas pelos comandos de log, como o máximo de anotações por execução. Você pode verificar o log do GitHub Ações para ver os resultados completos nesses casos.
Como suporte a repórter github-check em execução no Commit, podemos criar crachá de ação do ReviewDog Github para verificar o resultado contra o Mestre Commit, por exemplo. ?
Exemplo:
<!-- Replace <OWNER> and <REPOSITORY>. It assumes workflow name is "reviewdog" -->
[](https://github.com/<OWNER>/<REPOSITORY>/actions?query=workflow%3Areviewdog+event%3Apush+branch%3Amaster)
Se você usa -Reporter = Github-pr-check no Travis CI, não precisará definir REVIEWDOG_TOKEN .
Exemplo:
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 Armazene o token API do GitHub por teclas de criptografia Travis.
$ gem install travis
$ travis encrypt REVIEWDOG_GITHUB_API_TOKEN= < token > --add env.globalExemplo:
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-reviewExemplos
Armazenar REVIEWDOG_GITHUB_API_TOKEN (ou REVIEWDOG_TOKEN para github-pr-check) em variáveis de ambiente-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 Armazene REVIEWDOG_GITLAB_API_TOKEN na variável Gitlab CI.
reviewdog :
script :
- reviewdog -reporter=gitlab-mr-discussion
# Or
- reviewdog -reporter=gitlab-mr-commitNenhuma configuração adicional é necessária.
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-reportVocê pode usar o ReviewDog para publicar comentários de revisão de qualquer lugar com as seguintes variáveis de ambiente.
| nome | descrição |
|---|---|
CI_PULL_REQUEST | Pull Número da solicitação (por exemplo, 14) |
CI_COMMIT | Sha1 para a construção atual |
CI_REPO_OWNER | Proprietário do repositório (por exemplo, "ReviewDog" para https://github.com/reviewdog/erRorformat) |
CI_REPO_NAME | Nome do repositório (por exemplo, "ErrorFormat" para https://github.com/reviewdog/ERRORFORMAT) |
CI_BRANCH | [opcional] ramo do commit |
$ export CI_PULL_REQUEST=14
$ export CI_REPO_OWNER=haya14busa
$ export CI_REPO_NAME=reviewdog
$ export CI_COMMIT= $( git rev-parse HEAD )e defina um token, se necessário.
$ REVIEWDOG_TOKEN= " <token> "
$ REVIEWDOG_GITHUB_API_TOKEN= " <token> "
$ REVIEWDOG_GITLAB_API_TOKEN= " <token> " Se um serviço de IC não fornecer informações como o Pull Solicle ID - ReviewDog poderá adivinhar por um nome de ramificação e cometer sha. Basta passar guess da bandeira:
$ 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 Por padrão ( -fail-level=none ) ReviewDog retornará 0 como código de saída, mesmo que encontre erros. O ReviewDog sairá com o Código 1 com -fail-level=[any,info,warning,error] Sinalizador se encontrar pelo menos 1 problema com gravidade maior ou igual ao nível fornecido. Isso pode ser útil quando você o estiver usando como uma etapa no seu pipeline de CI e deseja marcar a etapa falhada se algum erro encontrado pelo Linter.
Você também pode usar o sinalizador -level para configurar o relatório padrão Revel.
ReviewDog Filter Resultados por DIFF e você pode controlar como os resultados do filtro de revisão -DOG por sinalizador -filter-mode . Os modos de filtro disponíveis são os abaixo.
added (padrão)Resultados do filtro por linhas adicionadas/modificadas.
diff_contextFiltro Resultados pelo contexto DIF. ou seja, linhas alteradas +-n linhas (n = 3 por exemplo).
fileResultados do filtro pelo arquivo adicionado/modificado. O IE ReviewDog reportará os resultados desde que estejam no arquivo adicionado/modificado, mesmo que os resultados não estejam no Diff real.
nofilterNão filtre nenhum resultado. Útil para publicar resultados como comentários o máximo possível e verifique outros resultados no console ao mesmo tempo.
-fail-on-error também funciona com qualquer modo de filtro e pode capturar todos os resultados de quaisquer linters com o modo nofilter .
Exemplo:
$ reviewdog -reporter=github-pr-review -filter-mode=nofilter -fail-on-error Observe que nem todos os repórteres fornecem suporte total ao modo de filtro devido à limitação da API. Por exemplo, o repórter github-pr-review usa a API de revisão do GitHub, mas esta API não suporta postar comentários fora do contexto DIFF, portanto, o ReviewDog usará a anotação de verificação como fallback para publicar esses comentários [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 | Parcialmente suportado [1] | Parcialmente suportado [1] |
github-pr-annotations | OK | OK | OK | OK |
gitlab-mr-discussion | OK | OK | OK | Parcialmente suportado [2] |
gitlab-mr-commit | OK | Parcialmente suportado [2] | Parcialmente suportado [2] | Parcialmente suportado [2] |
gerrit-change-review | OK | OK? [3] | OK? [3] | Parcialmente suportado? [2] [3] |
bitbucket-code-report | Não [4] | Não [4] | Não [4] | OK |
gitea-pr-review | OK | OK | Parcialmente suportado [2] | Parcialmente suportado [2] |
Use o sinalizador -tee para mostrar informações de depuração.
reviewdog -filter-mode=nofilter -teehaya14busa
Torne -se patrocinador do GitHub para cada colaborador ou torne -se um patrocinador ou patrocinador da OpenCollective.
