Estação de teste OmniLab para Android

O OmniLab ATS é uma ferramenta de teste que desenvolvedores e engenheiros de teste do Android podem usar para empregar uma interface do usuário para executar conjuntos de testes padrão do Android, como o Android Compatibility Test Suite (CTS). Essa ferramenta funciona como uma interface da Web para vários frameworks de teste, como Trade Federation (TF) e Google Mobly, permitindo que você execute testes CTS e multidispositivos em um conjunto de dispositivos de teste com configuração mínima, além de estabelecer uma programação para executar testes continuamente.

Configurar o OmniLab ATS

Esta seção explica como instalar e configurar o OmniLab ATS.

O OmniLab ATS usa o código-fonte destes locais:

• Código-fonte do OmniLab ATS
• Código-fonte do TradeFed Cluster

Instalar o OmniLab ATS

Siga todos os requisitos de hardware e software dos conjuntos de testes executados.

Os requisitos do CTS estão disponíveis em source.android.com.

Não há requisitos de hardware adicionais para o OmniLab ATS, mas recomendamos usar o requisito de host do CTS como ponto de partida.

Há duas maneiras de instalar o OmniLab ATS:

• Execute o programa de instalação.
• Instale manualmente, o que exige a instalação de vários programas e recursos.

Instalar com o programa de instalação

No Ubuntu 20.04 e versões mais recentes, o programa de instalação instala e configura todos os programas e recursos necessários para executar o OmniLab ATS.

Para usar o programa de instalação:

1. Execute o programa de instalação:

   curl https://storage.googleapis.com/android-mtt.appspot.com/prod/install.sh | bash
   

2. Execute mtt version para verificar a versão instalada da CLI OmniLab ATS.

Instalar manualmente

Instalar o Docker

1. Siga as instruções para instalar o Docker Community Edition (CE) na sua máquina Linux.

2. Siga as etapas pós-instalação para gerenciar o Docker como um usuário não raiz.

3. Talvez seja necessário reiniciar a janela do terminal ou sair e fazer login novamente para que as mudanças de permissão entrem em vigor.

Instalar o Python 3

A CLI ATS OmniLab é verificada nas versões 3.7 a 3.11 do Python.

Para o Ubuntu 16.04 ou versões anteriores, primeiro adicione o repositório para Python 3 fazendo uma das seguintes ações:

• Execute este comando:

  sudo add-apt-repository ppa:deadsnakes/ppa
  

• Crie e instale o repositório da origem.

Para instalar o Python 3, execute estes comandos:

sudo apt-get update
sudo apt install python3 python3-distutils

Para instalar uma versão específica do Python 3 (por exemplo, 3.10), execute estes comandos:

sudo apt-get update
sudo apt install python3.10 python3.10-distutils

Instalar a CLI do OmniLab ATS

Faça o download do pacote da interface de linha de comando (CLI) aqui.

Iniciar o OmniLab ATS

Inicie o OmniLab ATS com o seguinte comando:

mtt start

Na primeira vez que a interface é iniciada, pode levar alguns minutos para que ela apareça. A CLI mostra um URL da Web para acessar a interface em um navegador. Por padrão, o URL da Web é localhost:8000. Se necessário, você pode mudar a porta padrão na inicialização com a flag --port.

Se uma versão mais recente estiver disponível, você poderá atualizar para a versão atual. Consulte as notas da versão para conferir as versões mais recentes.

Para atualizar para a versão atual, execute:

mtt start --force_update

Para interromper o app, execute:

mtt stop

Para conferir uma lista de outros comandos, use:

mtt --help

Fazer backup e restaurar o banco de dados

Para fazer backup do banco de dados do OmniLab ATS, interrompa o app e execute o comando a seguir, que faz backup do banco de dados atual em um arquivo TAR chamado mtt-backup.tar no diretório principal:

docker run --rm --mount source=mtt-data,target=/data -v ~:/out ubuntu bash -c "cd /data && tar cvf /out/mtt-backup.tar ."

Para restaurar, execute o seguinte comando antes de iniciar o app:

docker run --rm --mount source=mtt-data,target=/data -v ~:/out ubuntu bash -c "cd /data && tar xvf /out/mtt-backup.tar"

Assistente de configuração

Depois de instalar e executar o OmniLab ATS pela primeira vez, o assistente de configuração vai ajudar você a personalizar a ferramenta para seu ambiente. Todas as mudanças feitas aqui podem ser reconfiguradas mais tarde na página "Configurações".

Restaurar um backup de configuração

Se você tiver um arquivo de configuração com backup de outro host do OmniLab ATS, faça o upload do arquivo para copiar as configurações modificadas desse host clicando no botão Upload File.

Figura 1. Restauração de um backup de configuração.

Definir a conta de serviço padrão

É possível definir uma conta de serviço que o OmniLab ATS usa por padrão ao acessar seus recursos (por exemplo, Google Cloud Storage, Google Drive). Para autenticar sua conta de serviço, clique em Fazer upload da chave da conta de serviço e selecione o arquivo de chave JSON da sua conta de serviço.

Figura 2. Configurar a conta de serviço.

Quando a conta de serviço é autenticada, o endereço de e-mail da conta aparece no canto superior direito da página. Para mudar a conta de serviço, clique no nome da conta, remova a conta padrão atual e faça o upload de uma nova chave.

Figura 3. Mudar a conta de serviço.

Importar conjuntos de configuração

Um conjunto de configurações é um pacote de configurações para executar pacotes de testes, incluindo ações de dispositivo relacionadas e canais de build. Os conjuntos de configuração são hospedados em um bucket específico do Google Cloud Storage (GCS). Depois de autenticar o canal de build do GCS com sua Conta do Google, você verá uma lista de todos os conjuntos de configuração disponíveis.

Selecione os conjuntos de configuração que você quer adicionar ao host da Test Station e clique em Import Selected.

Figura 4. Importação de um conjunto de configurações.

Incluir configurações de Wi-Fi

Alguns testes de CTS exigem que seu dispositivo se conecte a um ponto de acesso Wi-Fi. Para selecionar sua rede Wi-Fi, digite o SSID do Wi-Fi e o PSK do Wi-Fi (opcional).

Figura 5. Configurações do ponto de acesso Wi-Fi.

Depois de concluir o assistente de configuração, a página será recarregada com as novas configurações aplicadas.

Conectar dispositivo

A depuração USB precisa estar ativada para usar um dispositivo para testes. Para ativar a depuração:

1. Siga as instruções em Ativar opções do desenvolvedor e depuração.

2. Se você planeja usar builds de teste do Android pré-carregados com chaves ADB personalizadas, coloque os arquivos .adb_key personalizados no diretório ~/.android/.

   Os arquivos são carregados automaticamente e transmitidos ao ADB para ativar automaticamente a depuração USB depois que o dispositivo é atualizado para dispositivos que executam esses builds.

3. Conecte o dispositivo à máquina host usando USB.

   O dispositivo aparece na guia "Dispositivos ATS do OmniLab" em até um minuto após atualizar a interface da Web. Também é possível conferir o estado dos dispositivos nessa guia.

   

   Figura 6. Conectando um dispositivo.

Os diferentes estados do dispositivo são:

• Disponível: o dispositivo está conectado e pronto para executar um teste.
• Alocado: o dispositivo está conectado e executando um teste. Cada dispositivo pode executar apenas um teste por vez. Portanto, ele precisa concluir o teste atual antes de executar um novo.

Executar um teste

Selecionar um teste

O OmniLab ATS vem com um conjunto de configurações de CTS pré-empacotadas. Para executar um desses testes, acesse a guia "Pacotes de testes" e clique em Executar teste no teste selecionado.

Figura 7. Como selecionar um teste.

Para editar ou adicionar novos testes, consulte Como adicionar testes.

Configurar a execução do teste

Edite os parâmetros que serão usados nessa execução de teste específica. A maioria dos parâmetros é preenchida com valores definidos na configuração de teste selecionada.

Essa etapa pode ser concluída usando os valores padrão, mas você pode mudar qualquer um dos parâmetros, como Tentativa máxima e Comando, para atender às suas necessidades.

Figura 8. Como configurar uma execução de teste.

Os parâmetros da execução de teste são:

• Nome: nome do pacote de testes que você quer executar.
• Run Count: o número de vezes que esse teste precisa ser executado quando programado. As execuções de teste são programadas usando a Federação comercial, que executa até 20 execuções de teste em paralelo, se houver capacidade para isso.
• Tentativa máxima: número máximo de vezes que uma execução de teste pode ser repetida se pelo menos um teste falhar. Isso geralmente é definido como 4 a 6 novas tentativas para que uma execução completa do CTS processe testes instáveis.
• Tempo limite da fila: se uma execução de teste permanecer no estado Em fila por muito tempo, ela será cancelada automaticamente. Especifique o tempo de espera antes do cancelamento aqui. O padrão é 24 horas.

• Comando: o comando para executar o conjunto de testes. É possível inserir outros argumentos da linha de comando aqui. Por exemplo, execute um módulo específico no CTS 8.1 com:

  cts-suite -m ShortModuleName
  

• Comando "retry": o comando para tentar novamente um conjunto de testes. É possível adicionar outros argumentos da linha de comando aqui. Por exemplo, para tentar novamente apenas um módulo específico no CTS 8.1, use:

  cts --retry 0 -m ShortModuleName
  

  Os argumentos de nova tentativa podem ser diferentes daqueles disponíveis com o comando inicial. Portanto, verifique os parâmetros compatíveis no site oficial do pacote de testes selecionado.

• Execução de teste anterior: se você quiser executar novamente uma execução de teste anterior, faça o seguinte:

  • Local: se a execução foi iniciada no host atual, insira o ID que aparece ao visualizar os detalhes da execução do teste.

    

    Figura 9. Execução anterior de teste local.

  • Remoto: se a execução foi iniciada em um host diferente, faça upload do arquivo de resultados do teste selecionando Remoto, clicando em Fazer upload do arquivo de resultados do teste e selecionando um arquivo no armazenamento local.

    

    Figura 10. Execução remota de teste anterior.

Selecione os dispositivos

Clique nas caixas de seleção para selecionar os dispositivos a serem alocados para executar o pacote de testes. A contagem de fragmentos vai mudar automaticamente para corresponder ao número de dispositivos selecionados.

Figura 11. Seleção de dispositivos.

Para selecionar dispositivos por atributos diferentes dos números de série, insira manualmente "Especificações do dispositivo". Por exemplo, para selecionar três dispositivos com o nome do produto "bramble", insira o seguinte:

product:bramble;product:bramble;product:bramble

Os atributos aceitos são:

• build_id
• série_dispositivo
• device_type
• nome do host
• produto
• product_variant
• sim_state

Todos os dispositivos selecionados precisam estar no estado Disponível para executar a execução de teste. Todos eles mudam para o estado Alocado quando a execução de teste é executada. Uma execução de teste fica no estado Em fila enquanto aguarda a disponibilidade dos dispositivos.

Adicionar ações do dispositivo

As ações do dispositivo são scripts que podem ser executados antes de cada teste. Algumas ações do dispositivo já vêm configuradas, como atualizar e reiniciar. Para criar novas ações de dispositivo, consulte Criar uma nova ação de dispositivo.

Figura 12. Ações do dispositivo.

Para adicionar uma ação do dispositivo a uma execução de teste, clique em Add new action, marque as caixas de seleção das ações a serem adicionadas e clique em Add Action(s). As ações do dispositivo são realizadas sequencialmente. Você pode arrastar as ações para reordená-las.

Figura 13. Reordenar ações.

Definir recursos de teste

Os recursos de teste são arquivos necessários para executar uma execução de teste. Por exemplo, a execução do CTS requer um arquivo android-cts*.zip, e atualizar um dispositivo exige que você forneça a imagem do build.

O URL de download do arquivo ZIP do pacote de testes deve ser padrão para os links do Google Drive fornecidos aos parceiros. Para selecionar outro arquivo, clique em Procurar. Na janela pop-up, insira um link de download de arquivo, use um arquivo de um canal de build autenticado ou faça upload de um arquivo para usar do armazenamento local.

Figura 14. Testar recursos.

Confira abaixo a janela pop-up para selecionar um recurso de teste por um URL da Web. Você pode digitar o link do URL de download e clicar no botão Select para confirmar a seleção.

Figura 15. Seletor de recursos de teste: URL da Web.

Se você tiver feito o upload de recursos para o Google Grive, o Google Cloud Storage (GCS) ou outros canais, também poderá navegar até a guia do canal específico e selecionar os recursos. Este é um exemplo de seleção de um recurso do Google Drive.

Figura 16. Seletor de recursos de teste: Google Drive.

Além de selecionar arquivos, os caracteres curinga também são aceitos no campo Filename. Confira a documentação neste link.

Figura 17. Teste do seletor de recursos: suporte a padrões de caractere curinga.

Também é possível selecionar um arquivo do armazenamento local do OmniLab ATS. É possível fazer upload de arquivos para esse armazenamento ou usar arquivos e diretórios locais diretamente.

Figura 18. Seletor de recursos de teste: armazenamento local de arquivos.

Adicionar configurações de nova execução

É possível programar execuções que começam após a conclusão da execução principal e carregar os resultados, mas pode usar dispositivos, ações ou recursos diferentes.

Figura 19. Como adicionar configurações de nova execução.

Iniciar uma execução de teste

Depois de inserir as informações necessárias para a execução do teste, clique em Start Test Run. Se todas as informações forem válidas, a execução do teste vai começar, e você será redirecionado para uma página para conferir os detalhes e o progresso da execução do teste.

Figura 20. Iniciando uma execução de teste.

Criar um plano de teste

Os planos de teste são usados para criar execuções de teste programadas. Por exemplo, executando o CTS 9.0 todos os dias às 17h. Para criar um novo plano de teste, clique em Criar um novo plano de teste.

Figura 21. Criação de um plano de teste.

Configurar plano de teste

Digite o nome do plano de teste e os rótulos que você quer adicionar. Em seguida, selecione uma programação para usar.

• Manual: o plano de teste cria execuções de teste somente quando um usuário clica em Executar plano de teste na página de lista de planos de teste.
• Periódico: o plano de teste programa automaticamente as execuções de teste na programação periódica selecionada. Por exemplo, programar um teste todos os dias às 17h.
• Personalizado: o plano de teste programa automaticamente as execuções de teste com base na expressão cron inserida. Por exemplo, para programar uma execução de teste todos os dias às 17h, a expressão cron é 0 17 * * *.

Figura 22. Como configurar um plano de teste.

Adicionar pacotes de testes

Adicione os pacotes de testes que você quer programar pelo plano de teste clicando em + Adicionar configuração de execução de teste. Selecione um conjunto de testes no menu suspenso Name e clique em Next step. Em seguida, selecione os dispositivos em que você quer executar o teste e clique em Adicionar configuração. É possível adicionar várias configurações para cada plano de teste.

Figura 23. Como configurar uma execução de teste.

Adicionar ações do dispositivo

Adicione as ações do dispositivo que você quer que sejam executadas antes de cada teste. Consulte Como adicionar ações de dispositivos para mais detalhes.

Figura 24. Adicionar ações do dispositivo.

Definir recursos de teste

Adicionar recursos de teste a planos de teste é o mesmo que adicioná-los a execuções de teste individuais. Consulte Como definir recursos de teste para mais detalhes.

Figura 25. Configurar recursos de teste.

Conferir execuções de teste

Lista de execuções de teste

Veja a lista de execuções de teste programadas na página "Execuções de teste". Clique em Visualizar para ver mais detalhes sobre uma execução de teste.

Também é possível filtrar a lista inserindo uma string na barra de filtro e pressionando a tecla Enter. É possível usar vários filtros separando-os por vírgula. O filtro retorna todas as linhas que contêm o texto exato (sem correspondência de substring) em qualquer coluna, exceto Status e Criado.

Um filtro vazio retorna todas as linhas. No momento, não há como filtrar linhas com valores vazios.

Figura 26. Lista de execução de teste.

Detalhes da execução do teste

Aqui você pode conferir os detalhes de uma execução de teste, como o status, os registros e os resultados.

Figura 27. Detalhes da execução do teste.

Status da execução do teste

O progresso de uma execução de teste é mostrado na seção "Status". Se houver uma mensagem relacionada, como progresso do download, motivo do cancelamento ou mensagem de erro, ela também será mostrada aqui.

Figura 28. Status da execução do teste.

Os estados de execução do teste são:

• Pendente: os recursos necessários estão sendo transferidos por download.
• Em fila: o teste está pronto para ser executado quando um dispositivo fica disponível.
• Executando: o teste está sendo executado em um dispositivo alocado.
• Concluído: o teste foi concluído e os resultados foram informados.
• Cancelado: o teste foi cancelado pelo usuário ou expirou ao tentar encontrar dispositivos disponíveis.
• Erro: ocorreu um erro que impediu a execução do teste.

Cancelar uma execução de teste

Se a execução de teste não tiver sido concluída, clique em Cancelar e em Sim na caixa de diálogo de confirmação para cancelar. As execuções de teste também são canceladas automaticamente se permanecerem no estado Enfileiradas por mais tempo do que o campo queue_timeout_seconds. O cancelamento de uma execução de teste no estado Running pode levar alguns minutos para entrar em vigor.

Figura 29. Cancelar uma execução de teste.

Resultados da execução de teste

Depois que uma execução de teste é concluída, os resultados são coletados e exibidos. Para conferir mais detalhes, clique na seta de cada execução. Clique em View Output Files para conferir os artefatos de teste coletados, como test_result.xml e test_result_failures.html.

Figura 30. Resultados da execução do teste.

É possível conferir os logs do host e do Tradefed ao vivo na guia "Logs".

Figura 31. Guia "Registros".

Os resultados de cada módulo estão na guia "Resultados do teste".

Figura 32. Guia "Resultados do teste".

Para fazer o download dos arquivos usados como recursos de teste, clique em Open na guia Test Resources.

Figura 33. Guia "Recursos de teste".

Para conferir os detalhes da execução do teste, como create_time, acesse a guia "Config".

Figura 34. Guia "Config".

Recursos avançados

Gerenciar arquivos de configuração

O OmniLab ATS usa arquivos de configuração escritos em YAML para carregar opções predefinidas, como testes, canais de build e ações do dispositivo. Confira um exemplo de arquivo de configuração:

// example_file.yaml
tests:
- id : android.cts.9_0.arm
  name: CTS 9.0 (ARM)
  test_resource_defs:
  - name: android-cts.zip
    default_download_url: https://dl.google.com/dl/android/cts/android-cts-9.0_r7-linux_x86-arm.zip
    test_resource_type: TEST_PACKAGE
  command: cts
  env_vars:
  - name: TF_PATH
    value: ${TF_WORK_DIR}/android-cts/tools:${TF_WORK_DIR}/android-cts/testcases
  - name: LD_LIBRARY_PATH
    value: ${TF_WORK_DIR}/android-cts/lib:${TF_WORK_DIR}/android-cts/lib64
  setup_scripts:
  output_file_patterns:
  - android-cts/logs/latest/.*
  - android-cts/results/latest/.*\.html
  - android-cts/results/latest/compatibility_result\..*
  - android-cts/results/latest/logo.png
  - android-cts/results/latest/test_result.xml
  result_file: test_result.xml
  java_properties:
  - name: CTS_ROOT
    value: ${TF_WORK_DIR}
  context_file_dir: android-cts/results/
  context_file_pattern: '[\d_\.]+\.zip'
  retry_command_line: retry --retry 0
  runner_sharding_args: --shard-count ${TF_SHARD_COUNT}

build_channels:
- id: google_drive
  name: Google Drive
  provider_name: Google Drive

device_actions:
- id: flash
  name: Flash
  test_resource_defs:
  - name: bootloader.img
    test_resource_type: DEVICE_IMAGE
  - name: radio.img
    test_resource_type: DEVICE_IMAGE
  - name: img.zip
    test_resource_type: DEVICE_IMAGE
  tradefed_target_preparers:
  - class_name: com.android.tradefed.targetprep.RunHostCommandTargetPreparer
    option_values:
    - name: work-dir
      values:
      - ${TF_WORK_DIR}
    - name: host-setup-command
      values:
      - adb -s $SERIAL reboot-bootloader
      - fastboot -s $SERIAL flash bootloader bootloader.img
      - fastboot -s $SERIAL flash radio radio.img
      - fastboot -s $SERIAL reboot-bootloader
      - fastboot -s $SERIAL -w update img.zip
      - adb -s $SERIAL wait-for-device
    - name: host-cmd-timeout
      values:
      - 10m

Quando você configura sua instância ATS OmniLab, pode compartilhar a configuração com outros usuários exportando-a como um arquivo. Para fazer isso, acesse a página "Configurações" e clique em Exportar no canto superior direito.

Figura 35. Gerenciamento de arquivos de configuração.

Depois de fazer o download do arquivo de configuração, compartilhe-o com outros usuários. Para adicionar o arquivo de configuração à instância do OmniLab ATS, clique em Import e selecione o arquivo de configuração.

Criar uma nova ação do dispositivo

As ações do dispositivo são usadas para automatizar o processo de configuração. As ações são scripts executados em cada dispositivo em que o teste está sendo executado antes de cada execução de teste, inclusive antes das tentativas. Para conferir uma lista de ações de dispositivo disponíveis, acesse a página "Configurações" e clique na guia "Ações de dispositivo". Várias ações do dispositivo já vêm configuradas, como reinicialização e flash.

Figura 36. Guia "Ações do dispositivo".

Adicionar uma nova ação de dispositivo

1. Clique em Ação de novo dispositivo.

   

   Figura 37. Botão de ação do novo dispositivo.

2. Digite um nome e uma descrição.

   

   Figura 38. Nome da ação do dispositivo.

3. Clique em Adicionar preparador de destino.

4. Insira o nome completo da classe do Preparador de segmentação da Trade Federation, por exemplo, com.android.tradefed.targetprep.RunHostCommandTargetPreparer.

   

   Figura 39. Adicionando um preparador de destino.

   Uma lista de preparadores de destino disponíveis pode ser encontrada na referência com.android.tradefed.targetprep.

   

   Figura 40. Lista de preparadores de destino.

5. Adicione as opções que serão usadas com o preparador de destino. Para conferir as opções disponíveis, confira targetprep para o código-fonte de cada preparador de destino no AOSP:

   

   Figura 41. Exemplo de opção de ação.

6. Para adicionar uma opção, clique em Adicionar opção de preparação de destino e insira os valores necessários.

   

   Figura 42. Exemplo de comando de ação.

7. Defina os recursos de teste necessários para executar a ação do dispositivo, por exemplo, criar imagens para atualizar. Para adicionar uma definição de recurso, clique em Adicionar recurso de teste e preencha os campos obrigatórios. Se você souber onde os arquivos estão localizados, clique em Procurar para fornecer um URL de download padrão. Se os preparadores de destino aceitarem o diretório como recurso de teste, selecione Descompactar. Em seguida, especifique o diretório de destino relativo no diretório de trabalho temporário e os nomes dos arquivos a serem descompactados. Se nenhum nome de arquivo for fornecido, todos os arquivos serão descompactados do recurso de teste.

   

   Figura 43. Recursos de teste de ação.

8. Clique em Atualizar.

   

   Figura 44. Ação de salvar mudanças.

Gerenciar testes

Editar um teste

Para editar um teste salvo, acesse a página "Testes" e clique em Editar na linha do teste que você quer modificar. Depois de mudar a configuração do teste, clique em Atualizar.

Figura 45. Editando um teste.

Adicionar um novo teste

Para adicionar um novo teste, acesse a página "Testes" e clique em Criar um novo teste. Insira as informações adequadas e clique em Criar.

Figura 46. Criação de um teste.

Figura 47. Copiando um teste.

Exportar configurações do host

Depois de configurar um host, você pode exportar as configurações dele para um arquivo. Você pode fazer upload desse arquivo para outros hosts para copiar as configurações salvas.

Para exportar as configurações de um host, acesse a página "Configurações" e clique em Exportar no canto superior direito.

Figura 48. Exportar uma configuração de host.

Para importar um arquivo de configuração do host, acesse a página "Configurações" e clique em Importar no canto superior direito.

Figura 49. Como importar uma configuração de host.

Usar arquivos e diretórios locais

A partir da versão R11, os arquivos no diretório $HOME/.ats_storage são acessíveis automaticamente no OmniLab ATS. Copie ou mova um arquivo para esse diretório e selecione-o na guia Local File ao programar uma execução de teste.

cp /path/to/file $HOME/.ats_storage

Figura 50. Seleção de um arquivo no diretório $HOME/.ats_storage.

É possível montar diretórios adicionais na loja de arquivos local com a flag --mount_local_path.

mtt start --mount_local_path=/path/to/dir1 --mount_local_path=/path/to/dir2:renamed_dir2

Figura 51. Diretórios adicionais montados no armazenamento de arquivos local.

Ativar o modo de vários hosts

Com o modo de vários hosts, os usuários podem usar um único host de controle do ATS para gerenciar os dispositivos e testes em vários hosts de trabalho do ATS.

Figura 52. Arquitetura do modo de vários hosts.

1. Para iniciar o controlador do ATS, use o seguinte comando:

   mtt start --operation_mode=ON_PREMISE
   

2. Verifique se o controlador está acessível em http://${CONTROLLER_HOSTNAME}:8000.

3. Para iniciar os workers, use o seguinte comando:

   mtt start --control_server_url=http://CONTROLLER_HOSTNAME:8000 --operation_mode=ON_PREMISE
   

Se a rede não permitir que os hosts se comuniquem entre si, você precisará seguir as instruções de configuração mais avançadas abaixo no worker do ATS.

1. Conecte os dois hosts usando túneis SSH. Selecione portas para as portas principais e do servidor de arquivos, por exemplo, 9000 e 9006.

   ssh -L ATS_PORT:localhost:8000 -L FS_PORT:localhost:8006 CONTROLLER_HOSTNAME
   

2. Configure e inicie o ATS.

   DOCKER_GATEWAY_IP_ADDRESS=$(ip -4 addr show dev docker0 | grep -Eo 'inet [.0-9]+/' | grep -Eo '[.0-9]+')
   socat tcp-listen:ATS_PORT,bind="${DOCKER_GATEWAY_IP_ADDRESS}",reuseaddr,fork tcp-connect:127.0.0.1:ATS_PORT &
   socat tcp-listen:FS_PORT,bind="${DOCKER_GATEWAY_IP_ADDRESS}",reuseaddr,fork tcp-connect:127.0.0.1:FS_PORT &
   mtt start --control_server_url=http://${DOCKER_GATEWAY_IP_ADDRESS}:ATS_PORT \
                   --control_file_server_url=http://${DOCKER_GATEWAY_IP_ADDRESS}:FS_PORT \
                   --operation_mode=ON_PREMISE
   

Limpador de arquivos

O limpador de arquivos é um job do cron executado a cada hora para limpar arquivos com base em configurações definidas pelo usuário. O ATS tem duas configurações padrão para arquivar resultados de execução de teste e excluir arquivos temporários. Neste guia, explicamos como personalizar as políticas e configurações para gerenciar os arquivos com eficiência.

Políticas

Uma política define a operação a ser executada nos arquivos ou diretórios e os critérios para selecionar destinos. As operações disponíveis são mostradas na tabela:

Tipo de operação	Parâmetros
ARCHIVE	remove_file: se true, remova o arquivo após o arquivamento.
DELETE

Os critérios são baseados em atributos de arquivo e informações do sistema. Os critérios disponíveis são mostrados na tabela:

Tipo de critério	Descrição	Parâmetros
LAST_MODIFIED_TIME	Filtrar arquivos com base na data e na hora da última modificação.	ttl: vários tipos de expressões de tempo são aceitos, por exemplo, 10m, 2h, 7 days, 4w. Consulte pytimeparse para saber quais formatos são aceitos.
LAST_ACCESS_TIME	Filtre arquivos com base na data e na hora do último acesso.	Igual a LAST_MODIFIED_TIME.
NAME_MATCH	Filtrar arquivos com base no nome usando uma expressão regular.	pattern: expressão regular, por exemplo, [a-f0-9]{8}-([a-f0-9]{4}-){3}[a-f0-9]{12}\.zip para corresponder aos códigos postais dos resultados.
SYSTEM_AVAILABLE_SPACE	Acionar ações com base no espaço disponível no sistema.	threshold: acionar uma ação quando o espaço disponível ficar abaixo do limite, por exemplo, 200(B), 200KB, 200MB, 200GB, 2TB.

Figura 53. Adicionar uma nova política de limpeza de arquivos.

Configs

Uma configuração combina uma ou mais políticas com diretórios específicos. Os arquivos e diretórios nos diretórios especificados são processados com base nas políticas definidas. As políticas são aplicadas na ordem em que aparecem na configuração.

Todos os diretórios de destino precisam estar localizados no diretório /data. Se a configuração especificar o diretório de destino como logs, ele será interpretado como /data/logs.

Figura 54. Edite a configuração do limpador de arquivos.

Redefinir

Clicar em Redefinir configurações reverte a configuração do limpador de arquivos para o estado padrão. Essa ação limpa TODOS os itens personalizados.

Figura 55. Redefinir as configurações do Limpador de arquivos.

Suporte

Relatórios de bugs

Sua contribuição para o OmniLab ATS ajuda a melhorar o desenvolvimento da ferramenta. Queremos sua opinião! Consulte as notas da versão do OmniLab ATS para conferir detalhes sobre a versão mais recente. Para informar bugs ou oferecer sugestões, envie um relatório do bug. Os parceiros devem informar bugs ou sugestões usando os canais de parceria.