LEMON: Pipeline Runs data should have endpoint returning Plotly data format

[pedroMendesR]

In order to display the graphs of the execution's report in citrus, the data (GET stand/pipeline-runs) should be processed in the backend and putted in the right format to display it:

1. Pie chart: two lists, one containing the labels and the other the frequency of each label, e.g. ['RUNNING','WAITING'...,'COMPLETED'] and [20,15,...,36].

Ps.: These two values above are the mandatory, but more graph configurations can be sent back to user, like "caipirinha/visualizations" does, e.g:

"title": "Teste com plotly",
    "data": [
        {
            "values": [
                277,
                1,
                323,
                708
            ],
            "labels": [
                "2nd",
                null,
                "1st",
                "3rd"
            ],
            "marker": {
                "colors": [
                    "#506FBB",
                    "#3FA8AD",
                    "#71AD3F",
                    "#FFCA5C"
                ]
            },
            "type": "pie",
            "hole": 0.6
        }
    ],
    "layout": {
        "title": {
            "text": "Teste"
        },
        "autosize": true,
        "height": 450
    },

[waltersf]

Please, test the endpoint in the dev environment:

/api/v1/stand/pipeline-runs/summary?type=line /api/v1/stand/pipeline-runs/summary?type=pie

The first one may return few results because there are only 3 jobs (others may be created during tests), You can inform other filters, such as start and end dates (format: yyyy-mm-dd).

[pedroMendesR]

Please, add a granularity filter for "type=line", so the data can be grouped by hours, days, weeks, months.

[pedroMendesR]

@waltersf tenho duas questões referentes aos gráficos:

Atualmente, os gráficos de pizza e de série temporal das execuções estão funcionando corretamente, porém preciso de duas novas features.

1. Como havia proposto, ainda preciso do atributo de controle do intervalo de tempo usado para agrupar as execuções no endpoint "api/v1/stand/pipeline-runs/summary?type=line", estou fazendo a chamada no front como "timeInterval=['hour','daily','weekly','monthly']". Um exemplo:

"/api/v1/stand/pipeline-runs/summary?type=line&timeInterval=hour"

Obs.: não é necessário esta adaptação no caso do gráfico de pizza.

2. Como mostrei na última reunião, quero implementar o gŕafico de série temporal agrupando os status de cada execução, desta maneira:

Neste caso, preciso de um novo endpoint (por exemplo, "/api/v1/stand/pipeline-runs/summary?type=histogram") para retornar 8 valores de "y" e 1 valor de "x" (8 status que compartilham o mesmo eixo temporal, ou 8 duplas de valores "x" e "y" se for mais trivial), exemplo:

{
    'x': ['2024-09-01','2024-09-02',...'2024-09-09']
    'WAITING':{
        y: [1,0,...,6]
    },
    'COMPLETED': {
        y: [2,1,...,0]    
    },
    ...
}

Seria interessante este novo gráfico também ter o atributo de "timeInterval" para mexer na granularidade do eixo temporal.

Perceba que este é um gráfico de série temporal mais detalhado que o anterior, também mostrando as informações totais, portanto se achar desnecessário ainda termos o primeiro depois de implementar este, podemos deprecá-lo.

[waltersf]

Sobre os intervalos: ok, só mudei de hour para hourly, para ficar consistente com os demais nomes.

Sobre o histogram, para ficar consistente, é melhor ter o nível "y" irmão do "x" e então os statuses, além de ser mais fácil para eu gerar:

{
    "x": [
        "2024-10-20T00:00:00",
        "2024-10-27T00:00:00"
    ],
    "y": [
        {
            "COMPLETED": 0,
            "ERROR": 0,
            "INTERRUPTED": 0,
            "PENDING": 0,
            "RUNNING": 0,
            "WAITING": 0,
            "CANCELED": 0,
            "WAITING_INTERVENTION": 0
        },
        {
            "COMPLETED": 0,
            "ERROR": 0,
            "INTERRUPTED": 0,
            "PENDING": 0,
            "RUNNING": 0,
            "WAITING": 0,
            "CANCELED": 0,
            "WAITING_INTERVENTION": 0
        }
    ]
}```

por favor, teste

[pedroMendesR]

Adaptação do código no citrus

Adaptei o código da branch "lemon_ploty" no Citrus pra receber os dados do histograma neste formato. Também adaptei o request com "hourly". Estas alterações foram pra pull request da branch.

Testes no endpoint

Porém, testando o endpoint, percebi está dando Internal Server Error com alguns parâmetros enviados, no contexto do type="line" ou type="histogram". O comportamento está bem estranho, observe os testes que fiz (vou mostrar o exemplo com type="line", mas acontece a mesma coisa com "histogram"):

PARÂMETROS DEFAULT

OK | /api/v1/stand/pipeline-runs/summary?type=line retorna hora a hora desde "2024-10-26T00:00:00" (está retornando desde esta data por default)

PARÂMETROS CUSTOMIZADOS

// adicionando data de start OK | /api/v1/stand/pipeline-runs/summary?type=line&start=2024-10-21 retorna hora a hora desde "2024-10-21T00:00:00"

Este exemplo acima funciona, mas nenhuma data de 'start' abaixo de 2024-10-21 funciona:

ERRO | /api/v1/stand/pipeline-runs/summary?type=line&start=2024-10-20 Internal Server Error

Curiosamente, adicionar o parâmetro 'name' com alguns nomes faz com que a busca com 'start' funcione com qualquer data, mesmo que antes de 2024-10-21, teste com name="testes" e name="test":

OK | /api/v1/stand/pipeline-runs/summary?type=line&start=2024-05-05&name=testes retorna hora a hora desde "2024-05-05T00:00:00"

ERRO | /api/v1/stand/pipeline-runs/summary?type=line&start=2024-05-05&name=test Internal Server Error

Por fim, utilizar "timeInterval" algumas vezes também está quebrando, mas está com o mesmo comportamento que o "start", utilizar alguns "name" específicos faz funcionar:

ERRO | /api/v1/stand/pipeline-runs/summary?type=line&timeInterval=monthly Internal Server Error

OK | /api/v1/stand/pipeline-runs/summary?type=line&timeInterval=monthly&name=testes retorna o agrupamento do mês de outubro (perceba que por default está retornando dados desde 2024-10-26 como foi mostrado anteriormente)