dev: ci: build Docker images

[cardoe]

Uses the existing in-tree Dockerfile to build Docker images when a release is made and everytime there is a merge to master. Publishes the images to the GitHub Container Registry as well. Heavily based on https://docs.docker.com/build/ci/github-actions/examples/

[cardoe]

While I know that https://hub.docker.com/r/dastapov/hledger exists, it does seem like a bit of a manual process. I'm not necessarily sure if that's your Docker Hub or not but if it is this could publish there by default. The goal of this change was to hopefully make the release process for you slightly easier. As well as to get more Linux platforms covered by the Docker images (specifically linux/arm64).

[simonmichael]

@cardoe: thanks! Let's see if @dastapov has any thoughts.

I would probably avoid running it on every push to master, personally.

[adept]

I think that I wrote the original Dockerfile that is in the hledger repo, and I think it did not see a whole lot of action - or changes - over time. As such, I think it could benefit from not running everything as root, from a better start-up script for hedger-web, and possibly other small fixes that went into https://github.com/adept/hledger-docker (I don't remember all of them off the top of my head).

Re local building vs actions: I toyed with the building through both GitHub actions and docker hub actions, but ultimately abandoned it, as both routes (last time I tried them, which was probably ~2 years ago) were much much slower than building locally, hard to debug if anything goes wrong, and rather brittle (builds were breaking for me quite often). The workflow of pushing the change and then being notified of the failure 3-5 hours later got old pretty fast for me ... @cardoe , if by any chance you've already tried this in your local clone for any length of time (say 1-2 month), how was your experience?

It does not burden me greatly to keep building docker images, and I would probably keep building them for my own use regardless (esp. sincle they include hledger-interest and hledger-iadd).

[cardoe]

There's certainly something to be said for having a quick feedback loop on issues and depending on your workflow using a container is going to slow things down. Also using and relying on GitHub Actions is not gonna be quick at all.

I'm fine dropping this. What I was really after was getting multi-platform images getting built. I didn't actually know where the source to your Dockerfile was. For reference: https://docs.docker.com/build/building/multi-platform/

[simonmichael]

I'm pretty clueless about Docker, and against burdening our regular CI with unjustified extra carbon emissions, but very much for making life easier for packagers (and thereby, getting hledger packaged widely and making installation easier for users). I'll gladly go with what you two recommend, but it sounds to me like adding this workflow, on push to a docker branch (but perhaps not master), so that I could trigger it at release time, might be quite helpful to reduce toil and help docker images to appear quickly on the install page.

[cardoe]

So personally for me I use a build a container workflow in many of my projects. I don't do Haskell however so I'm not sure of the pain points of building Haskell projects. (Mostly Rust and Python projects for me now days). As a maintainer of software I try to reduce my own toil and do things automatically for myself so I've been using GitHub Actions to build things for me automatically. e.g. tagging a PR with a label and letting it bump the version from a pre-release version to the release, generate the changelog entry, tag the release, push it to crates.io (Rust's package repo) and build the containers.

I'm really just looking for up to date releases with more arches covered than just x86_64 for Linux. I'll close this PR and share another approach.

[cardoe]

So I took @adept's repo and added GitHub actions to build the containers and push them on a matching tag (e.g. v1.28 would build and push his hledger containers as Docker tag 1.28). But alas the compilation time exceeded the max 2 hour run time. You can see my config here: https://github.com/cardoe/hledger-docker/blob/containers/.github/workflows/ci.yml

Looks like I won't be able to get what I'm looking for through GitHub Actions.

[simonmichael]

As it stands, I think this PR provides a new github workflow that builds docker images for linux/amd64 and linux/arm64, containing the three main hledger tools, and pushes them to GitHub Container Registry. This sounds worth merging, though I would not run it on every push to master.

Is amd64 different from the "-x64" binaries we provide in github releases ?

Is Github Container Registry as easy for users to install from as docker hub ?

What do you think is best for this PR @cardoe ?

[simonmichael]

If we built these images at release time, what would be the corresponding requirements and install procedure or command that we would show on https://hledger.org/install ?