-
Notifications
You must be signed in to change notification settings - Fork 2
Description
O que aconteceu:
Ao tentar utilizar a action da STK CLI em um job do Github actions, tive problemas pois a ferramenta não está conseguindo criar volumes relacionados ao path da task. Tal feature foi testada em mais de uma máquina e acredita-se que o problema está relacionado a permissionamento de leitura e escrita no SO da runner.
O que você esperava que acontecesse:
Ao importar a stack e tentar utilizar a task, o comportamento esperado era que a task conseguisse realizar o pull da imagem docker configurada (ok), montar alguns volumes relacionados a arquivos contidos na task (not ok) e no repositório (ok) e executar a aplicação (not ok).
Como reproduzi-lo (o mínimo e preciso possível):
- Passo 1: Criar uma task docker utilizando qualquer imagem base
- Passo 2: Criar algum script/package na raiz da task;
- Passo 3: Configurar no arquivo task.yaml a montagem de um volume que viabilize a utilização do script/package criado no Passo 2 de dentro do container da task;
- Passo 4: Criar um workflow do Github Actions para executar os comandos necessários para execução da task docker;
- Passo 5: Executar o workflow e verificar que o script não será encontrado de dentro do container.
Algo mais que precisamos saber?
Alguns detalhes sobre o problema que tive e um workaround que apliquei para conseguir utilizar a task.
A task está commitada no diretório do seguinte repositório: https://github.com/stack-spot/data-stack/tree/main/tasks/generate-avro-schema-from-json
Essa task foi criada utilizando docker justamente por se tratar de um tipo de aplicação que demanda um pouco mais de tempo para execução e isso prejudicaria um pouco a experiencia do usuário se ele fosse executar localmente. Por isso, colocamos a execução nesta pipeline.
A aplicação que é executada trata-se de um job Apache Spark utilizado para a criação de schemas avro a partir da amostra de eventos das aplicações do usuário.
Sendo assim, foi necessário criar uma pasta com a package Python (app/src, o job Spark pode ser escrito em Python utilizando a biblioteca PySpark), outra para arquivos de configuração (app/conf) e outra para binários necessários ao job (app/jars).
Dessa forma, os volumes necessários para a execução da task foram configurados conforme imagem a seguir:

Ao executar a task no workflow, houve falha com a mensagem de que o script principal da aplicação Spark não foi encontrado dentro do container:

Em uma tentativa de entender melhor o ocorrido, foram colocadas algumas linhas de comandos para tentar entender o porque de o arquivo não estar presente no container docker e pode-se observar que as pastas src e jars não foram montadas pelo volume.

Para tentar não ficar travado por esse problema, foi realizado um workaround da seguinte forma:
O repositório da stack foi clonado diretamente para uma pasta dentro do workspace da runner, pois o path da stack ao ser importada estava no diretório /home/runner/.stk/stacks/data-stack e os arquivos do diretório que não tiveram problema de montagem de volume estavam no diretório /runner/_work/stackspot-data-platform-pipeline
Ao realizar o clone da stack para a pasta /runner/_work/data-stack e passar a flag task_path no momento da execução da task fez com que o comportamento esperado ocorresse.
O objetivo desta issue é abrir espaço para a discussão do problema apresentado e tentar encontrar possíveis soluções para que os usuários da cli consigam utilizar esta action sem a necessidade de se preocupar com problemas em tasks que precisarão criar volumes relacionados ao path do próprio componente.
Ambiente:
- Versão do projeto: N/A
- Sistema operacional: Linux
- Outros: N/A
