l7r7/gitlab-ci-build-statuses

Get the statuses of the CI pipelines in a group in Gitlab CI and display them on an HTML page

gitlab-ci-build-statuses's Issues

Docker container doesn't shutdown gracefully

The executable doesn't seem to be the problem (it works without the docker container)

Improve the app architecture

• hexagonal architecture?
• pure core, impure shell?
• what does one do in Haskell?

Fetch the build statuses for the project's default branch instead of master

Right now, the build statuses that are shown represent the status of the latest pipeline of the master branch.
This should be more flexible. The simplest way to do that is probably to take the project's default branch (which is included in the API response for a single project) for determining the pipeline status

Better error reporting when config parsing fails

For example, if the Group ID is set, but can't be read, the error will say that the group ID is missing. This should be improved

App shouldn't be healthy if the thread for updating the build statuses dies

The app is updating the build statuses in a separate thread than the thread the HTTP service is served from.
Since the health endpoint will always return 200 OK, the app appears to be healthy as long as the web server is up and running. This means that if the thread for updating the statuses dies for some reason, the app will keep running with stale information.

To reflect this, the app should indicate that something is wrong when any of the threads are not running anymore

UI rehaul

Right now the UI is everything but fancy, but with my limited CSS skills it was the only way I found that fulfills all my requirements.

Requirements for the UI

• Basically, I'm looking for a layout with tiles that are squares
• Instead of resizing the tiles, the tiles should be rearranged on different rows and columns if possible (that's something I quite like about the current solution)
• The whole tile should be clickable, not only the text
• The page title (and maybe the favicon) could represent a summary of the build statuses (for example the UTF-8 checkmark when all pipelines are green or the number of broken pipelines if there are any)

Some ideas that sound good to me

• I'd like to have a bootstrap based UI. I kinda like the cards that it offers: https://getbootstrap.com/docs/4.0/components/card/
• I definitely prefer a very simple UI that ideally doesn't need any JS. Maybe it makes sense to add something that reloads the data regularly, but for now I found a JS-free way that works
• It would be nice to have some kind of footer at the bottom that contains metadata, like the timestamp of the last update

Consider moving the CI to Github Actions

Currently, I don't know if it really makes sense to invest time on this, but it seems to be a hot topic these days

Add a proper release concept

At the moment, the CI pipeline builds an image for every push to master. I think it would make sense to introduce a proper release cycle, where:

• every push to master is built, on a successful build a docker image is built and tagged with latest
• in addition to that, there should be regular releases that are stable, and where it's also clear which features got added

This is probably related to #5

Restructure the data storage

At the moment, the app's state is stored as a tuple (Maybe UTCTime, [Result]) inside an IORef, where:

• The first part stores the timestamp of the last successful update
• The second part stores the latest results

The timestamp is wrapped inside a Maybe to reflect that there might be no successful update yet, in which case the list of results should be empty. Although this hasn't too much impact, the invariant could be encoded more clearly: If there was no update yet, there is neither an timestamp nor a list of results.

The UI also should indicate whether there was no successful update yet or whether the are no results

Don't use network_mode: host in docker-compose

The docker-compose example uses network_mode: host multiple times and the different applications want to bind to all kinds of ports then. In an environment that already has many containers running this can produce many conflicts. It would be better if it was setup with docker networks and only had to use host ports which are actually required (e.g. the 8282 port binding for the actual app.)