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

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 na referência da linha de comando.

Opções gerais úteis

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

Sinalização	Descrição
--config	É possível organizar sinalizações em um arquivo .bazelrc em configurações, como as de depuração ou de lançamento de builds. Outros grupos de configuração podem ser selecionados com --config=<group>.
--keep_going	O Bazel precisa tentar o máximo possível continuar com a execução de build e teste. Por padrão, o Bazel falha rapidamente.
--remote_download_outputs	Ao usar a execução remota ou o armazenamento em cache (disco e remoto), é possível sinalizar para o Bazel que você quer fazer o download de todos os artefatos de build (intermediários) da seguinte maneira: --remote_download_outputs=all Por padrão, o Bazel só faz o download de 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) a binários. Observação:como isso aumenta o tempo de build, ele é destinado apenas 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, definidos pela máquina ou pelo projeto.
--auto_output_filter	Por padrão, o Bazel tenta evitar spam de registro e só imprime avisos do compilador e a 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 analisar erros de sandbox. Para saber por que o Bazel cria builds em sandbox por padrão e o que é colocado em sandbox, consulte nossa documentação de sandboxing. Dica:se você acha que o erro pode ser causado pelo sandboxing, tente desativar o sandboxing 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 ter sucesso ou falhar

Inicialização

Cuidado: as flags de inicialização precisam ser transmitidas antes do comando e causar uma reinicialização do servidor. Use essas flags com cuidado.

Sinalização	Descrição
--bazelrc	É possível especificar opções padrão do Bazel em arquivos .bazelrc. Se vários arquivos .bazelrc existirem, você pode selecionar qual .bazelrc é usado adicionando --bazelrc=<path to the .bazelrc file>. Dica:--bazelrc=dev/null desativa a pesquisa de 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 exemplo a seguir limita o tamanho do heap do Bazel a 3 GB: --host_jvm_args=-Xmx3g Observação:-Xmx é usado para definir o tamanho máximo de heap da máquina virtual Java (JVM). O heap é a área de 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:o uso de 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 ao tentar evitar a análise de thrashing. Para mais informações, consulte Como 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 esperem uma conexão de depurador antes de serem executados.
--runs_per_test	O número de vezes que os testes sã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_filter	Essa flag é particularmente útil ao iterar em um único método de teste, por exemplo, quando uma mudança que você fez quebra um teste. Em vez de executar novamente todos os métodos de teste no pacote de testes, concentre-se apenas nos testes específicos que falharam. Isso permite um feedback mais rápido e uma depuração mais eficiente. Essa flag é usada com frequência em conjunto com --test_output=streamed para a saída de teste em tempo real.
--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 corrompido, normalmente é necessário usar --test_output=streamed para conferir 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 do bazelrc específicas do usuário

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

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 normalmente 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 próprio servidor do Bazel consome para tarefas como análise e orquestração de build.
--sandbox_base	Permite que o sandbox crie os diretórios do sandbox abaixo desse caminho. Por padrão, o Bazel executa ações locais em sandbox, o que aumenta a sobrecarga do build. Dica:especifique um caminho no tmpfs, por exemplo, /run/shm, para melhorar bastante o desempenho quando o build ou os testes tiverem muitos arquivos de entrada.

Opções do bazelrc específicas do projeto

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

Sinalização	Descrição
--flaky_test_attempts	Tente novamente 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 FLAKY no resumo do teste.
--remote_cache	Um URI de um endpoint de armazenamento em cache. Configurar o armazenamento em cache remoto pode ser uma ótima maneira de acelerar as compilações do Bazel. Ele pode ser combinado com um cache de disco local.
--remote_download_regex	Forçar o download de saídas de build remoto cujo caminho corresponde a esse padrão, independente da configuração --remote_download_outputs. Vários padrões podem ser especificados repetindo essa flag.
--remote_executor	HOST ou HOST:PORT de um endpoint de execução remota. Transmita esse valor se estiver usando um serviço de execução remota. Muitas vezes, você vai precisar 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 é adicionado a cada mensagem gerada pelo Bazel, especificando o horário em que a mensagem foi exibida. Isso é útil em sistemas de CI para entender rapidamente qual etapa levou quanto tempo.
--spawn_strategy	Mesmo com a execução remota, a execução local de algumas ações de build pode ser mais rápida. Isso depende de fatores como a capacidade do cluster de build, a velocidade da rede e os atrasos da rede. Dica:para executar ações localmente e remotamente e aceitar o resultado mais rápido, adicione --spawn_strategy=dynamic ao comando de build.