Verificações e testes de pull request

Ao abrir um pull request (PR) no repositório opentelemetry.io, um conjunto de verificações é executado. As verificações garantem que:

• Você assinou o CLA
• Seu PR é implantado com sucesso através do Netlify
• Suas alterações estão em conformidade com nosso guia de estilo

Easy CLA

Esta verificação falha caso você ainda não tenha assinado o CLA.

Implantação com Netlify

Caso a implantação através do Netlify falhe, selecione Detalhes para mais informações.

Uma linha de status ?? some/path pouco antes de "build.command" failed, indicando um caminho que seu PR não altera, sugere que a compilação falhou por causa de um cache de compilação desatualizado do Netlify, e não por causa das suas alterações:

1. Peça a um mantenedor, por meio de um comentário no PR, para executar a compilação novamente sem o cache. Para o procedimento de limpeza do cache, consulte Gerenciamento de dependências.
2. Se a falha se repetir na nova execução sem cache, o cache não era a causa: alguma etapa da compilação está escrevendo nesse caminho, e suas alterações são as primeiras suspeitas.

GitHub PR checks

Para garantir que as contribuições sigam nosso guia de estilo, implementamos um conjunto de verificações que checam as regras do guia e falham caso encontrem algum problema.

As seções a seguir descrevem as verificações atuais e como corrigir os erros relacionados.

TEXT linter

Essa verificação garante que os termos e palavras específicas do OpenTelemetry sejam usados de forma consistente em todo o site.

Se forem encontrados problemas, anotações serão adicionadas aos seus arquivos na visualização arquivos alterados do PR. Corrija estes itens para que a verificação passe. Como alternativa, você pode executar npm run check:text -- --fix localmente para corrigir a maioria dos problemas. Depois, execute npm run check:text novamente e corrija manualmente o que restar.

MARKDOWN linter

Essa verificação garante que sejam aplicados os critérios de padronização e consistência dos arquivos Markdown.

Se forem encontrados problemas, execute npm run fix:markdown para resolver a maioria deles automaticamente. Para os problemas restantes, execute npm run check:markdown e aplique manualmente as alterações sugeridas.

SPELLING check

Essa verificação garante que todas as palavras estejam corretamente escritas em todos os idiomas.

Se a verificação falhar, execute npm run check:spelling localmente para listar os problemas. Para adicionar ou alterar palavras permitidas, consulte Verificação ortográfica no guia de estilo.

CSPELL check

Essa verificação garante que as listas cSpell:ignore do cSpell no front matter estejam normalizadas e que as listas de palavras em .cspell/*.txt estejam ordenadas (consulte npm run fix:dict).

Se essa verificação falhar, execute npm run fix:dict localmente e envie as alterações em um novo commit.

FILE FORMAT

Essa verificação garante que todos os arquivos estejam em conformidade com as regras de formatação do Prettier.

Se essa verificação falhar, execute npm run fix:format localmente e envie as alterações em um novo commit.

FILENAME check

Essa verificação garante que:

• Todos os nomes de arquivos estejam em kebab-case
• Não existam arquivos ou pastas obsoletos no repositório (consulte a lista abaixo)

Siga as orientações de cada anotação de erro. Para aplicar as correções localmente, execute npm run fix:filenames e envie as alterações em um novo commit.

Arquivos e pastas obsoletos

A verificação sinaliza os seguintes caminhos obsoletos:

• tools/ - removido quando as ferramentas de code-excerpts foram movidas para um pacote npm
• static/refcache.json - removido na migração para o Lychee. Se sua branch o restaurar, siga as instruções de atualização de branches desatualizadas.
• .lycheecache como arquivo rastreado - deixou de ser rastreado quando o cache de links versionado passou a ser link-cache.jsonc. Se sua branch ainda o versiona, siga as instruções de atualização.

BUILD e CHECK LINKS

Estas duas verificações compilam o site e verificam que seus links são válidos.

Corrigir erros 404

Você deve corrigir as URLs marcadas como inválidas (código HTTP 404) pelo verificador de links.

Lidando com links externos válidos

O verificador de links pode ocasionalmente obter um código de status HTTP diferente de 200 (sucesso) de servidores que bloqueiam verificadores. Esses servidores geralmente retornam um código de status HTTP na faixa de 400, como 401, 403 ou 406, que são os mais comuns. Alguns servidores, como o LinkedIn, reportam 999.

Se você validou manualmente um link externo que o verificador de links não está obtendo um status de sucesso, você pode adicionar o seguinte parâmetro de consulta à sua URL para fazer com que o verificador de links ignore ele: ?link-check=no, ou &link-check=no caso existam outros parâmetros de consulta. Por exemplo, as seguintes URLs serão ignoradas:

• https:/some-example.org?link-check=no
• https:/some-example.org?other-param=value&link-check=no

Ao adicionar link-check=no, registre a data da sua validação manual adicionando também o parâmetro last-validated=YYYY-MM-DD, por exemplo:

• https:/some-example.org?link-check=no&last-validated=2026-08-02

CHECK LINKS (production, internal)

Essa verificação falha quando uma página aponta para uma página em rascunho (draft) ou com data futura: essa página é exibida na pré-visualização da implantação, mas o site de produção a omite. Aponte para uma página publicada ou publique a página de destino primeiro. Se CHECK LINKS reportar a mesma página como ausente, ela não existe: corrija o link. Para saber o que essa verificação compila e cobre, consulte Links para páginas não publicadas.

CACHE updates committed?

Se você adicionou ou alterou um link externo, o verificador de links o registra no cache de links (link-cache.jsonc), e essa verificação falha até que o cache atualizado seja incluído em um commit.

Se sua branch é anterior ao link-cache.jsonc, primeiro atualize-a a partir da main; para saber como, incluindo como resolver um conflito no próprio arquivo de cache, consulte as instruções de atualização. Em seguida, escolha uma das opções:

• Comente /fix:link-cache no seu PR — o OpenTelemetry Bot atualiza o cache por você (em uma branch anterior ao link-cache.jsonc, o bot recusa e aponta para as mesmas instruções); ou
• Compile e verifique os links localmente: npm run install:safe e, em seguida, npm run check:links, que também atualiza o cache de links. Envie as alterações no cache de uma execução bem-sucedida em um novo commit.

WARNINGS in build log?

Se essa verificação falhar, revise o log BUILD, na etapa npm run log:build, para identificar possíveis problemas adicionais. Caso não tenha certeza de como resolver, peça ajuda aos mantenedores.

Sempre use um caminho para links locais do site

Ao criar links para páginas do site do OpenTelemetry, use caminhos locais em vez de links externos. A compilação emitirá um aviso caso você não faça isso.

Para resolver o aviso de compilação, mantenha apenas a parte do caminho da URL completa:

O uso de caminhos locais garante que:

• Páginas locais do site sejam abertas na mesma aba do navegador: links externos abrem em uma nova aba, o que não é o comportamento desejado para a navegação dentro do site
• O processamento de links de localização funcione como esperado: os links recebem automaticamente o prefixo do código de idioma apropriado
• Os caminhos locais sejam mais fáceis de verificar e não ocupem desnecessariamente o cache de links

Nunca marque uma página localizada como rascunho

A compilação emite um aviso sobre páginas localizadas marcadas como rascunho (draft). Para a regra e a solução, consulte Páginas em rascunho.

LOCALIZATION guidelines

Essa verificação aplica as diretrizes de localização que podem ser verificadas mecanicamente, como não copiar imagens e outros recursos entre localizações, e que ainda não são cobertas por outras verificações.

Se essa verificação falhar, execute npm run fix:l10n localmente e envie as alterações em um novo commit.

TEST (excluding test:base)

Executa npm run test:compound-tests, que executa os scripts NPM compostos test:*-* (por exemplo, testes de edge functions do Netlify). Ele não executa test:base.