You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered:
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):
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.
https://github.com/stack-spot/stackspot-data-platform-pipeline/blob/1872cb80aa8ce27a417438a5dc61a8442b867dc1/.github/workflows/stk.yaml#L95
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:
The text was updated successfully, but these errors were encountered: