Uso de macros para criar verbos personalizados

Informar um problema Acessar a origem

A interação do dia a dia com o Bazel acontece principalmente por meio de alguns comandos: build, test e run. Às vezes, no entanto, isso pode parecer limitado: você pode querer enviar pacotes para um repositório, publicar documentação para usuários finais ou implantar um aplicativo com o Kubernetes. Mas o Bazel não tem um comando publish ou deploy. Onde essas ações se encaixam?

O comando "bazel run"

O foco do Bazel em hermética, reprodutibilidade e incrementabilidade significa que os comandos build e test não são úteis para as tarefas acima. Essas ações podem ser executadas em um sandbox, com acesso limitado à rede, e não têm garantia de serem executadas novamente a cada bazel build.

Em vez disso, confie no bazel run, o mecanismo de trabalho para tarefas que você quer que tenham efeitos colaterais. Os usuários do Bazel estão acostumados com regras que criam executáveis e os autores de regras podem seguir um conjunto comum de padrões para estender isso para "verbos personalizados".

Na prática: rules_k8s

Por exemplo, considere rules_k8s, as regras do Kubernetes para o Bazel. Suponha que você tenha a seguinte meta:

# BUILD file in //application/k8s
k8s_object(
    name = "staging",
    kind = "deployment",
    cluster = "testing",
    template = "deployment.yaml",
)

A regra k8s_object cria um arquivo YAML padrão do Kubernetes quando bazel build é usado no destino staging. No entanto, os destinos adicionais também são criados pela macro k8s_object com nomes como staging.apply e :staging.delete. Esses scripts de build para executar essas ações e, quando executados com bazel run staging.apply, se comportam como nossos próprios comandos bazel k8s-apply ou bazel k8s-delete.

Outro exemplo: ts_api_guardian_test

Esse padrão também pode ser visto no projeto Angular. A macro ts_api_guardian_test produz dois destinos. O primeiro é um destino nodejs_test padrão, que compara alguma saída gerada com um arquivo "golden" (ou seja, um arquivo contendo a saída esperada). Isso pode ser criado e executado com uma invocação bazel test normal. Em angular-cli, é possível executar um desses destinos com bazel test //etc/api:angular_devkit_core_api.

Com o tempo, talvez seja necessário atualizar este arquivo golden por motivos legítimos. A atualização manual é tediosa e propensa a erros. Portanto, essa macro também fornece um destino nodejs_binary que atualiza o arquivo dourado, em vez de fazer uma comparação com ele. Efetivamente, o mesmo script de teste pode ser escrito para execução no modo "verificar" ou "aceitar" com base em como é invocado. Isso segue o mesmo padrão que você já aprendeu: não há um comando bazel test-accept nativo, mas o mesmo efeito pode ser alcançado com bazel run //etc/api:angular_devkit_core_api.accept.

Esse padrão pode ser bastante poderoso e acaba sendo muito comum quando você aprende a reconhecê-lo.

Como adaptar suas próprias regras

As macros são o centro desse padrão. As macros são usadas como regras, mas podem criar vários destinos. Normalmente, eles criam um destino com o nome especificado que executa a ação de compilação principal. Talvez ele crie um binário normal, uma imagem do Docker ou um arquivo de código-fonte. Nesse padrão, destinos adicionais são criados para produzir scripts que executam efeitos colaterais com base na saída do destino principal, como publicar o binário resultante ou atualizar a saída de teste esperada.

Para ilustrar isso, una uma regra imaginária que gera um site com o Sphinx (link em inglês) com uma macro para criar outro destino que permita ao usuário publicá-lo quando estiver pronto. Considere a seguinte regra para gerar um site com o Sphinx:

_sphinx_site = rule(
     implementation = _sphinx_impl,
     attrs = {"srcs": attr.label_list(allow_files = [".rst"])},
)

Em seguida, considere uma regra como a seguinte, que cria um script que, quando executado, publica as páginas geradas:

_sphinx_publisher = rule(
    implementation = _publish_impl,
    attrs = {
        "site": attr.label(),
        "_publisher": attr.label(
            default = "//internal/sphinx:publisher",
            executable = True,
        ),
    },
    executable = True,
)

Por fim, defina a macro a seguir para criar destinos para as duas regras acima juntas:

def sphinx_site(name, srcs = [], **kwargs):
    # This creates the primary target, producing the Sphinx-generated HTML.
    _sphinx_site(name = name, srcs = srcs, **kwargs)
    # This creates the secondary target, which produces a script for publishing
    # the site generated above.
    _sphinx_publisher(name = "%s.publish" % name, site = name, **kwargs)

Nos arquivos BUILD, use a macro como se ela apenas criasse o destino principal:

sphinx_site(
    name = "docs",
    srcs = ["index.md", "providers.md"],
)

Neste exemplo, um destino "docs" é criado, como se a macro fosse uma regra única e padrão do Bazel. Quando criada, a regra gera uma configuração e executa o Sphinx para produzir um site HTML pronto para inspeção manual. No entanto, outro destino "docs.publish" também é criado, o que cria um script para publicar o site. Depois de verificar a saída do destino principal, você pode usar bazel run :docs.publish para publicá-lo para consumo público, assim como um comando bazel publish imaginário.

Não é imediatamente óbvio como pode ser a implementação da regra _sphinx_publisher. Muitas vezes, ações como essa gravam um script de shell da tela de início. Esse método normalmente envolve o uso de ctx.actions.expand_template para criar um script de shell muito simples. Nesse caso, invocar o binário do editor com um caminho para a saída do destino principal. Dessa forma, a implementação do editor pode permanecer genérica, a regra _sphinx_site pode apenas produzir HTML, e esse pequeno script é tudo o que é necessário para combinar os dois juntos.

Em rules_k8s, é isso que .apply faz: expand_template escreve um script Bash muito simples, baseado em apply.sh.tpl, que executa kubectl com a saída do destino principal. Esse script pode ser criado e executado com bazel run :staging.apply, fornecendo efetivamente um comando k8s-apply para destinos k8s_object.