Folha de referência de sinalização do Bazel

Informar um problema Ver fonte Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

Navegar pela extensa lista de flags de linha de comando do Bazel pode ser um desafio. Esta página se concentra nas flags mais importantes que você precisa conhecer.

Dica:selecione o nome da flag na tabela para navegar até a entrada dela na referência da linha de comando.

Opções gerais úteis

As flags a seguir precisam ser definidas explicitamente na linha de comando.

Sinalização	Descrição
--config	É possível organizar flags em um arquivo .bazelrc em configurações, como para depuração ou builds de lançamento. Outros grupos de configuração podem ser selecionados com --config=<group>.
--keep_going	O Bazel precisa tentar ao máximo continuar com a execução de build e teste. Por padrão, o Bazel falha imediatamente.
--remote_download_outputs	Ao usar a execução ou o armazenamento em cache remoto (disco e remoto), você pode sinalizar ao Bazel que quer baixar todos os artefatos de build (intermediários) da seguinte maneira: --remote_download_outputs=all Por padrão, o Bazel baixa apenas artefatos de nível superior, como o binário final, e artefatos intermediários necessários para ações locais.
--stamp	Adiciona informações de build (usuário, carimbo de data/hora) aos binários. Observação:como isso aumenta o tempo de build, ele só é destinado a builds de lançamento.

Descobrir problemas de build e teste

As flags a seguir podem ajudar você a entender melhor os erros de build ou teste do Bazel.

Sinalização	Descrição
--announce_rc	Mostra quais flags são definidas implicitamente por arquivos .bazelrc definidos pelo usuário, pela máquina ou pelo projeto.
--auto_output_filter	Por padrão, o Bazel tenta evitar o spam de registros e só imprime avisos do compilador e saída de depuração do Starlark para pacotes e subpacotes solicitados na linha de comando. Para desativar toda a filtragem, defina --auto_output_filter=none.
--sandbox_debug	Permite detalhar erros de sandbox. Para saber por que o Bazel usa sandbox em builds por padrão e o que é colocado em sandbox, consulte nossa documentação sobre sandbox. Dica:se você acha que o erro pode ser causado pelo sandbox, tente desativar temporariamente. Para fazer isso, adicione --spawn_strategy=standalone ao comando.
--subcommands (-s)	Mostra uma lista abrangente de todos os comandos que o Bazel executa durante um build, independente de ele ser concluído ou falhar.

Inicialização

Atenção: as flags de inicialização precisam ser transmitidas antes do comando e causam uma reinicialização do servidor. Ative essas flags com cuidado.

Sinalização	Descrição
--bazelrc	É possível especificar opções padrão do Bazel em arquivos .bazelrc. Se houver vários arquivos .bazelrc, adicione --bazelrc=<path to the .bazelrc file> para selecionar qual deles será usado. Dica:--bazelrc=dev/null desativa a pesquisa por arquivos .bazelrc. Isso é ideal para cenários em que você quer garantir um ambiente de build limpo, como builds de lançamento, e evitar mudanças de configuração não intencionais de arquivos .bazelrc.
--host_jvm_args	Limita a quantidade de RAM usada pelo servidor do Bazel. Por exemplo, o seguinte limita o tamanho do heap do Bazel a 3 GB: --host_jvm_args=-Xmx3g Observação:-Xmx é usado para definir o tamanho máximo da heap para a máquina virtual Java (JVM). O heap é a área da memória em que os objetos são alocados. O formato correto para essa opção é -Xmx<size>, em que <size> é o tamanho máximo do heap, especificado com uma unidade como: m para megabytes g para gigabytes k para kilobytes
--output_base	Controla a árvore de saída do Bazel. O Bazel não armazena saídas de build, incluindo registros, na própria árvore de origem. Em vez disso, ele usa uma árvore de saída distinta para essa finalidade. Dica:usar várias bases de saída em um espaço de trabalho do Bazel permite executar vários servidores do Bazel simultaneamente. Isso pode ser útil para evitar thrashing de análise. Para mais informações, consulte Escolher a base de saída.

Testes do Bazel

As flags a seguir estão relacionadas ao teste do Bazel

Sinalização	Descrição
--java_debug	Faz com que os testes Java aguardem uma conexão de depurador antes de serem executados.
--runs_per_test	O número de vezes que os testes serão executados. Por exemplo, para executar testes N vezes, adicione --runs_per_test=N. Isso pode ser útil para depurar testes instáveis e verificar se uma correção faz com que um teste seja aprovado de forma consistente.
--test_output	Especifica o modo de saída. Por padrão, o Bazel captura a saída do teste em arquivos de registro locais. Ao iterar em um teste com falha, geralmente é recomendável usar --test_output=streamed para ver a saída do teste em tempo real.

Execução do Bazel

As flags a seguir estão relacionadas à execução do Bazel.

Sinalização	Descrição
--run_under	Muda a forma como os executáveis são invocados. Por exemplo, --run_under="strace -c" é usado com frequência para depuração.

Opções de bazelrc específicas do usuário

As flags a seguir estão relacionadas a opções específicas do usuário em .bazelrc.

Sinalização	Descrição
--disk_cache	Um caminho para um diretório em que o Bazel pode ler e gravar ações e saídas de ações. Se o diretório não existir, ele será criado. É possível compartilhar artefatos de build entre várias ramificações ou espaços de trabalho e acelerar os builds do Bazel adicionando --disk_cache=<path> ao comando.
--jobs	O número de jobs simultâneos a serem executados. Isso geralmente só é necessário ao usar a execução remota, em que um cluster de build remoto executa mais jobs do que você tem núcleos localmente.
--local_resources	Limita a quantidade de CPU ou RAM consumida por ações executadas localmente. Observação:isso não afeta a quantidade de CPU ou RAM que o servidor do Bazel consome para tarefas como análise e orquestração de build.
--sandbox_base	Permite que o sandbox crie diretórios abaixo desse caminho. Por padrão, o Bazel executa ações locais em sandbox, o que adiciona alguma sobrecarga ao build. Dica:especifique um caminho em tmpfs, por exemplo, /run/shm, para melhorar muito o desempenho quando seu build ou testes tiverem muitos arquivos de entrada.

Opções de bazelrc específicas do projeto

As flags a seguir estão relacionadas a opções específicas do projeto .bazelrc.

Sinalização	Descrição
--flaky_test_attempts	Repita cada teste até o número especificado de vezes em caso de falha. Isso é especialmente útil na integração contínua. Os testes que exigem mais de uma tentativa para serem aprovados são marcados como IRREGULAR no resumo do teste.
--remote_cache	Um URI de um endpoint de cache. Configurar o cache remoto pode ser uma ótima maneira de acelerar as versões do Bazel. Ele pode ser combinado com um cache de disco local.
--remote_download_regex	Força o download de saídas de build remoto cujo caminho corresponda a esse padrão, independente da configuração --remote_download_outputs. É possível especificar vários padrões repetindo essa flag.
--remote_executor	HOST ou HOST:PORT de um endpoint de execução remota. Transmita isso se estiver usando um serviço de execução remota. Muitas vezes, é necessário adicionar --remote_instance_name=<name>.
--remote_instance_name	O valor a ser transmitido como instance_name na API de execução remota.
--show-timestamps	Se especificado, um carimbo de data/hora será adicionado a cada mensagem gerada pelo Bazel, especificando o momento em que ela foi exibida. Isso é útil em sistemas de CI para entender rapidamente quanto tempo cada etapa levou.
--spawn_strategy	Mesmo com a execução remota, executar algumas ações de build localmente pode ser mais rápido. Isso depende de fatores como a capacidade do cluster de build, a velocidade da rede e os atrasos na rede. Dica:para executar ações local e remotamente e aceitar o resultado mais rápido, adicione --spawn_strategy=dynamic ao comando de build.