Pragiva — Tecnologia na prática

Compilar AdvPL e TLPP pela linha de comando: do arquivo ao teste

Compilar AdvPL e TLPP pela linha de comando: o modo cli do TDS-LS lê um arquivo de ações, e o código de saída não é a última conferência.

Desenvolvimento Tutorial 3 min de leitura

Assista o vídeo

Resposta rápida

Ferramenta
advpls.exe (TDS-LS) no modo cli.
Entrada
um .ini com seções em ordem: autenticar, compilar.
Destino
servidor, porta e ambiente escritos no arquivo.
Evidência
código de saída, capturado na hora, e o log.

compilar sem erro não testa a regra de negócio.

Nesta página7 seções

Antes de começar

  • O TDS-LS instalado (vem com a extensão TDS-VSCode) e o caminho do advpls.exe anotado.
  • Um AppServer de homologação, com o nome do ambiente como está no arquivo do servidor.
  • Um usuário autorizado a compilar nesse ambiente e a pasta de includes compatível com o RPO.
  • Um fonte de demonstração, em pasta local, fora de qualquer pasta sincronizada.

Compilar pela linha de comando faz sentido quando você precisa repetir a mesma operação, registrar os parâmetros dela ou encaixá-la num processo de entrega. O ganho está em tornar a sequência explícita. Um comando curto que esconde o ambiente e escolhe arquivos por acidente só muda a interface do problema.

Separe os modos do executável

O TDS-LS documenta os modos language-server, appre, cli e a opção de compatibilidade tds-cli. Têm propósitos diferentes. Aqui o foco é cli com um arquivo de ações.

O pré-processador appre ajuda a investigar includes e diretivas, mas o resultado dele não é RPO atualizado. Da mesma forma, subir o servidor de linguagem não é rodar um lote de compilação.

Anote o caminho do executável e a versão do pacote antes de montar a automação. Com mais de uma extensão instalada, não pegue a primeira que aparecer sem saber qual delas vai ser usada.

Prepare quatro informações antes do script

Destino, credencial autorizada, includes compatíveis e a lista exata de fontes. Anote também o ponto de retorno: qual revisão anterior existe caso seja preciso desfazer a entrega.

O nome do ambiente é o que o AppServer reconhece. O apelido criado na IDE pode ser outro. Confirme também se o ambiente compartilha o RPO com outras sessões antes de tratar a execução como isolada.

Para o primeiro teste, um único fonte de demonstração em pasta local. Não introduza ao mesmo tempo lista dinâmica, caminho sincronizado e fluxo de autenticação complexo.

O arquivo de ações

O formato oficial usa seções, executadas na ordem em que aparecem. Os marcadores entre <> são resolvidos na hora da execução, num ambiente controlado:

INI
logToFile=C:/pragiva-lab/logs/compilacao.log
showConsoleOutput=true

[Autenticar]
action=authentication
server=<HOST>
port=<PORTA>
secure=<0_OU_1_CONFORME_O_SERVIDOR>
build=AUTO
environment=<AMBIENTE>
user=<USUARIO>
psw=<SEGREDO_INJETADO_SO_NA_EXECUCAO>

[Compilar]
action=compile
programList=C:/pragiva-lab/fontes.txt
recompile=T
includes=C:/pragiva-lab/includes

secure acompanha a configuração do servidor; não é uma preferência a desligar para o comando passar. O manual orienta usar program ou programList, nunca os dois na mesma seção.

A lista tem um caminho por linha:

TEXT
C:/pragiva-lab/fontes/PGV001.tlpp

É a fronteira entre a lista de entrega e a configuração de conexão. Leia a lista final antes de rodar, não só o script que a gera.

Cuide dos bytes e do segredo

O manual exige ANSI/CP1252 para o arquivo de execução. Os fontes também precisam estar no encoding que o compilador espera. Converter um arquivo que já está em CP1252 como se fosse UTF-8 corrompe os acentos, e o fonte compila assim mesmo. O erro só aparece na tela do usuário.

O arquivo pode conter a senha em texto claro. Gere-o fora do repositório e de pastas sincronizadas, com acesso restrito, e apague-o ao terminar, inclusive quando o processo falhar.

Apagar o arquivo não apaga cópias já sincronizadas, o log nem o histórico do terminal. O segredo não pode aparecer no comando exibido nem no registro produzido pelo executor.

Execute e capture o resultado imediatamente

A invocação documentada é:

TEXT
advpls.exe cli C:/pragiva-lab/execucao-temporaria.ini

Em PowerShell, leia $LASTEXITCODE logo depois do processo nativo, antes de chamar qualquer outro executável. Guarde a saída e o log da mesma tentativa.

Defina um limite de duração. Um processo esperando entrada ou resposta de rede não pode ficar pendurado sem conclusão. Ao estourar o limite, registre a etapa observada e olhe o estado do servidor antes de repetir.

Confira mais que o retorno do processo

Leia o fim do log e confirme que todos os arquivos previstos foram processados. User authenticated successfully aparece numa tentativa que falhou depois. O código de saída serve para a automação, mas é interpretado junto com o comportamento documentado da versão.

Se houve interrupção ou mensagem conflitante, não assuma que repetir é inofensivo. Identifique quais ações chegaram a ocorrer e como o ambiente trata aquela falha.

Depois, o cenário funcional de demonstração. Ausência de erro de compilação não prova regra de negócio, disponibilidade de dado, chamada externa nem todos os caminhos de execução.

O registro de uma entrega reproduzível

Revisão dos fontes, lista processada, versão da ferramenta, destino, horário, código de saída, log sanitizado, teste funcional feito e resultado observado.

Com isso outra pessoa reconstrói a execução sem a sua senha e sem depender da sua memória. Quando o procedimento está claro, evoluir para lotes ou integração contínua é ampliar a mesma sequência.

Os erros que mais confundem esse processo estão em Oito armadilhas ao compilar AdvPL e TLPP fora do TDS.

Referências

  1. Outrogithub.com

    TOTVS — Manual do TDS CLI
  2. Outrogithub.com

    TOTVS — Formato do script de execução
  3. Outrogithub.com

    TOTVS — Compilação no TDS-VSCode

Continue por aqui