Pipelines duplicadas no Postgres
Description
CAPL - Bug default text according to the team DoR (Definition of Ready)
01 - PERSON OF CONTACT (PERSON THAT CAN ANSWER QUESTIONS ABOUT THE PROBLEM):
02 - PROBLEM (WHAT'S THE ISSUE?):
Ao fazer checkout de pipeline, não estamos validando se o campo sourceStagings está preenchido. Isso além de não fazer sentido para o negócio, tem causado duplicidades na nossa base de dados.
03 - STEPS TO REPRODUCE (STEP (1...N), VIDEO, SCREENSHOTS, LOGS FOLDER, HEARTBEAT, ETC. – IF IS NOT POSSIBLE TO REPRODUCE EXPLAIN THE REASON):
04 - LINKS (ADD A LINK TO THE BUG OR TO THE TENANT):
05 - EXPECTED BEHAVIOR (LIST THE EXPECTED BEHAVIORS TO CONSIDER THIS BUG AS DONE):
- Não é obrigatório a pipeline ter
Source Stagingsdentro do manifesto da pipeline. - Este card visa a limpeza dos dados inconsistentes:
- Pipelines duplicadas sem source stagings;
- A tabela pipeline precisa de um identificador único para não termos duplicidade em cenários de concorrência ou de inconsistência de validação. A sugestão são os campos:
carol_app_name,tenant_id,pipeline_name;- Carol_app_name e pipeline_name como chave da pipeline.
- Tenant_id: para suportar modelo da mesma pipeline na tenant unificada (representando produção) e tenant DEV (representando ambiente de desenvolvimento).
- Pipelines duplicadas com source stagings, analisar qual a versão manteremos junto a produto e DE.
- Priorizar pipeline com o mesmo source staging compativel com o manifesto.\
- Devemos permitir o campo sourceEntities vazio.
Activity
Show:
Details
Priority
HighestAssignee
Reinaldo Oliveira Machado Junior
Reporter
MARCOS STUMPF
Labels
CAROL_BACKLOG_REVIEWDEMOPLANNEDREADYREGRESSIONREVIEWEDSPRINT_GOAL
Due Date
27 May 2024
Fix versions
CAPL_4.04
Components
SQL_PIPELINES | DATA_PROCESSING
Created
27 March 2024, 16:41
Updated
10 June 2024, 18:41
More fields
Created: 27 March 2024, 20:41
Updated:
10 June 2024, 23:41
Esta issue foi automaticamente movida para REGRESSION, pois o PR foi mergeado na branch QA no Github.
Esta issue foi automaticamente movida para REGRESSION, pois o PR foi mergeado na branch QA no Github.
Esta issue foi automaticamente movida para TESTED & MERGED, pois o PR foi mergeado na branch Develop no Github. PR aprovado por rfschroeder,douglascoimbra.
Github usuário douglascoimbra aprovou um PR e foi adicionado como Shared Assignee nesta issue.
fix: https://totvsideia.atlassian.net/browse/CAPL-5707#icft=CAPL-5707 - Correção de pipelines duplicadas quando nao existe source stagings
Bom dia trazendo aqui na thread 2 topicos ao Shared Assignee referente ao card , antes de trazermos a produto. cc
:white_check_mark:Update: Topico resolvido, ambos os cenarios ja reproduzem na develop
• Voltado a pipelines sem o source entities, permitiremos tenants unified sem o source entities no manifesto da pipeline? Caso sim, como ficarah o copy data?
• Na branch do card, ao rodarmos tasks SQL apos um checkout, recebemos o erro na task: Esse erro so ocorre por que efetuamos a checagem por pipeline. Quando uma task eh executada, consequentemente apos o erro nao eh performado a eficiencia.
Mensagem editada no Slack - plataforma-carol-internal - Douglas Coimbra Lopes
PIPELINE DEDUPLICATED
Com ambos os topicos que bloqueavam o card ja confirmados de que ja ocorrem na develop e ja foram abertos cards para estudo dos cenarios ao time de produto, o card abaixo ja consta como validado. Aguardando apenas a fila de releases.
cc
Mensagem enviada pelo Slack - plataforma-carol-internal - Douglas Coimbra Lopes
Casos relatados por QA acontecem na develop, será tratado em outro card
Bom dia trazendo aqui na thread 2 topicos ao Shared Assignee referente ao card , antes de trazermos a produto. cc
• Voltado a pipelines sem o source entities, permitiremos tenants unified sem o source entities no manifesto da pipeline? Caso sim, como ficarah o copy data?
• Na branch do card, ao rodarmos tasks SQL apos um checkout, recebemos o erro na task: Esse erro so ocorre por que efetuamos a checagem por pipeline. Quando uma task eh executada, consequentemente apos o erro nao eh performado a eficiencia.
Mensagem editada no Slack - plataforma-carol-internal - Douglas Coimbra Lopes
Bom dia trazendo aqui na thread 2 topicos ao Shared Assignee referente ao card , antes de trazermos a produto. cc
• Voltado a pipelines sem o source entities, permitiremos tenants unified sem o source entities no manifesto da pipeline? Caso sim, como ficarah o copy data?
• Na branch do card, ao rodarmos tasks SQL apos um checkout, recebemos o erro na task: Esse erro so ocorre por que efetuamos a checagem por pipline.
Mensagem enviada pelo Slack - plataforma-carol-internal - Douglas Coimbra Lopes
@MARCOS STUMPF ,
@Gabriel DAmore Marciano , @Reinaldo Oliveira Machado Junior , @Renan Schroeder
Este issue foi planejada para ser entregue até 2024-05-27. Você pode confirmar consultando o campo Due Date desta issue.
Data já planejadas para esta issue: 2024-05-06, 2024-05-27
Se o campo External Issue Link estiver preenchido com o link de uma issue válida no Jira Produção o cliente também será notificado no Jira Produção.
Boa tarde pessaol. Um adendo voltado ao topico do card . cc
• Agora que efetuamos buscas por pipelines, o cenario que ocorre eh: Para pipelines que nao possuem source entity e o usuario efetua um checkout, um erro ocorre durante a execucao da task. Por conta de nao ocorrer na develop, o mesmo so replica-se na branch do card, por razoes da correcao. Corrigimos na branch atual ou abrimos um card para produto separado deste tema?
• GCP Error:
Mensagem enviada pelo Slack - back-end - Douglas Coimbra Lopes
@MARCOS STUMPF ,
@Reinaldo Oliveira Machado Junior , @Renan Schroeder
Flag foi removida, pois você acabou de alterar o status desta issue.
@Reinaldo Oliveira Machado Junior Segue logs e evidencias do erro de task voltado a checkout
https://totvssimpleprojel.qarol.ai/newdevtenantwork/carol-ui/tasks/activity/cb50437f-b7c4-409b-8017-409bd1d66ab3?p=1&ps=25&sort=dateUpdated&order=DESC&filters=%5B%7B%22hideInternal%22:%22false%22%7D%5D
https://cloudlogging.app.goo.gl/dF6icEr6WxNW8C6s8
:rotating_light: Cenario encontrado durante os testes do
• Uma vez obtendo pipelines duplicados e redeployando a sandbox para a respectiva branch `` , um erro ocorre nas tasks agendadas caso o usuario necessite efetuar um checkout
• Logs + sandbox e evidencias nos comments do card
•
Mensagem editada no Slack - plataforma-carol-internal - Douglas Coimbra Lopes
Cenario encontrado durante os testes do
• Uma vez obtendo pipelines duplicados e redeployando a sandbox para a respectiva branch `` , um erro ocorre nas tasks agendadas caso o usuario necessite efetuar um checkout
• Logs + sandbox e evidencias nos comments do card
•
Mensagem enviada pelo Slack - plataforma-carol-internal - Douglas Coimbra Lopes
PIPELINE DUPLICATED BEFORE THE DEPLOYMENT (SANDBOX DEVELOP)
UNIQUE PIPELINE AFTER DEPLOYMENT
Boa tarde pessoal, voltado aos testes/fix de pipelines duplicados no banco de dados do PG ( ) o fato de isso ocorrer com pipelines sem o sourceEntities: cc
• Significa que temos tenants unificadas sem o `sourceEntities`? Ou ocorria as duplicacoes apenas em processamentos em tenants de desenvolvimento?
• Caso o retorno seja sim, como esta sendo tratado a copia de dados? Pois creio que o copy data depende dessas informacoes no manifest da pipeline correto?
Mensagem editada no Slack - back-end - Douglas Coimbra Lopes
Boa tarde pessoal, voltado aos testes/fix de pipelines duplicados no banco de dados do PG ( ) o fato de isso ocorrer com pipelines sem o sourceEntities: cc
• Significa que temos tenants unificadas sem o `sourceEntities`? Ou ocorria as duplicacoes apenas em processamentos em tenants de desenvolvimento?
• Caso o retorno seja sim, como esta sendo tratado a copia de dados?
Mensagem enviada pelo Slack - back-end - Douglas Coimbra Lopes
Uma duvida, para o card abaixo, teremos de validar qdo a sandbox obtem pipelines duplicados e anteo redeployar na branch ou a limpeza sde pipelines duplicada serah feita antes do deploy da feature?
Mensagem enviada pelo Slack - plataforma-carol-internal - Douglas Coimbra Lopes
Esta issue foi automaticamente movimentada para QA REVIEW, pois o PR foi aprovado no Github.
Esta issue foi automaticamente movimentada para REVIEW, pois o PR (não DRAFT e não WIP) foi criado no Github.
fix: https://totvsideia.atlassian.net/browse/CAPL-5707#icft=CAPL-5707 - Correção de pipelines duplicadas quando nao existe source stagings
@MARCOS STUMPF ,
@Jonathan Willian Moraes , @Renan Schroeder
Este issue foi planejada para ser entregue até 2024-05-06. Você pode confirmar consultando o campo Due Date desta issue.
Data já planejadas para esta issue: 2024-05-06
Se o campo External Issue Link estiver preenchido com o link de uma issue válida no Jira Produção o cliente também será notificado no Jira Produção.
@MARCOS STUMPF ,
@Robson Thanael Poffo , @Renan Schroeder
Esta issue acabou de ser vinculada na(s) issue(s) https://totvsiddia.atlassian.net/browse/CAPL-5705#icft=CAPL-5705, conforme menções feitas no comentário anterior.
@Geny Isam Hamud Herrera , @MARCOS STUMPF , @Gabriel DAmore Marciano .
O resumo do que eu conversei com o Geny:
Resumo dos alinhamentos quanto a issue CAPL-5705:
Conforme o comportamento atual, devemos manter a configuração de sourceEntities (staging tables e data models) de forma opcional no manifesto de pipelines.
Ter os sourceEntities opcionais é devido ao fato do comportamento atual ser este (evitando quebra de contrato) e pelo fato de alguns use-cases rodarem criação de modelo de AI no BQ e estes não necessitarem o uso de sourceEntities.
As
functionsatualmente são tratadas através doprepareScripts, o KR-04 vai revisar as permissões ao rodar esse script para permitirCREATE FUNCTION, atualmente o script é executado pelo time Carol através da abertura de chamados.Desta forma o foco da issue é evitar gerar duplicidade das pipelines durante atualizações do manifest de pipelines.
@Robson Thanael Poffo Conforme conversamos você irá alinhar este tópico com o @Geny Isam Hamud Herrera em call para melhor entendimento sobre a questão levantada no refinamento.