fabjan / buildogram Goto Github PK

The rendered diagram has the most recent runs to the left, and older runs to the right. This may be a confusing default.

The default should be to sort oldest to the left and newest to the right.

The SVG image response does not provide cache headers.

This means services which cache images correctly might never fetch the latest version of a graph SVG.

To fix this it seems we need to at least have an ETag header: github/markup#224 (I think we can reuse the one we already have for the upstream API call).

When getting the workflow runs for diagramming, we currently get runs for all workflows.

It should be possible to get only the runs of a particular pipeline. They are identified by name.

When getting the workflow runs for diagramming, we currently get them for all branches.

It should be possible to get only the runs for a particular branch in order to get more specific diagrams, for the right things.

The code only handles conclusions "success" and "failure" (or nothing, i.e. still running).

If any other conclusion is seen, the diagram render crashes with a case clause. Due to gleam-lang/elli#13 these errors are not visible when they happen.

Case expressions are not checked for exhaustiveness in Gleam (yet).

The run number is reset when the workflow is renamed, so we can't use it to group attempts together.
The groups of stacked bars are meant to represent runs that have had to be retried.

We can instead build the groups while following the previous_attempt_url property to fetch them.

Will alleviate rate limits.

A simple solution: Set a max limit, throw away half the map when full before inserting.

Must clear etag cache at the same time, otherwise the 304 check flow will be broken when we start deleting cached items.

The updated_at timestamp cannot be used to estimate how long a workflow took to run, it changes when GitHub e.g. archives a run. See https://github.com/fabjan/buildogram/actions/runs/4038365177 for example.

To fix this we probably need to get the jobs inside each workflow run and compare their earliest started_at and latest completed_at timestamps.

Right now this series of runs:

100s, 100s, 50s, 50s, 50s, 50s, 50s, 50s, 50s, 50s, 10s, 10s, 10s, 10s, 10s, 10s, 10s, 10s

Results in a max of 100 and median of 50 seconds.

It would be more useful if it the median and max were calculated in segments or windows of configurable length. If the window size was 10, the runs above would be split in (windows are built from the end, the newest runs)

100s, 100s, 50s, 50s, 50s, 50s, 50s, 50s

max: 100, median: 50

50s, 50s, 10s, 10s, 10s, 10s, 10s, 10s, 10s, 10s

max: 50, median: 10