docker: Add official local docker support

[oliv3r]

Lets add our own docker container and use github actions to build and push it.

For now, only the alpine container is built and pushed, but we can very easily add a matrix entry for a debian container if there's enough demand.

@@ -25,21 +25,24 @@
         include:
           - container: ./dist/Containerfile
             autotag: auto
+          - container: ./dist/Containerfile.debian
+            autotag: false
+            suffix: -debian

But the build is done for multiple architectures, so there's that.

Best to reduce the amount of configurations we offer, as it also means more that can break.

Note, that there's a good chance tagged-builds will fail, because this repository is using so called 'lightweight' tags, instead of properly 'annotated' tags! See https://git-scm.com/book/en/v2/Git-Basics-Tagging for more details. This also could be the reason some additional complexity is added to the git get tags cmake stuff.

A nice addition could be to also run the tests as part of the build process, but I already saw that it's not as simple as make test so I figured better keep the current CI way of testing :)

Note, that I've pushed this code to my personal master branch and this shows how releases would look like here https://github.com/oliv3r/rtl_433/pkgs/container/rtl_433.

[zuckschwerdt]

Thanks! Did you see https://github.com/hertzg/rtl_433_docker/ ? It's well maintained and around for 4 years, so quiet stable I guess.

[gdt]

I guess there is a big question if things should stay separate. I see docker as one mechanism, and it appears not particularly portable. I'd lean to letting others provide containers/packaging and not integrate it into the project and list containerization projects along with packaging.

[oliv3r]

t appears not particularly portable

What makes you say that? I think it's more portable then the binaries produced from this repo. One can run docker/podman with qemu (and binfmt-misc) and run any architecture binary on any host. Granted, docker/podman support is required, but I think on all major operating systems this is available. And in comparison to different distro's it's even more portable, because it doesn't matter. It doesn't need to be packaged, it doesn't need to be installed. So from a portability point of view, it's far more portable.

As for 'packaging for everything everywhere' I fully agree, distro's should be responsible for their own packaging. But this isn't packing per-say. This is just a binary build, in a different format if you will.

Anyway, Yes! I was fully aware of https://github.com/hertzg/rtl_433_docker/ repo, which should be visible in the actual code-change :p but there's multiple reasons for including it here. First, when looking 'hey, is there a docker container for this' (it wasn't packaged for archlinux, only as an aur), I found it 'on the hub' but was not sure if I could trust the source. It wasn't from merbanan or from rtl_433 or something recognizable. So there's a trust issue.

After going to this repo, I found the link to the container, and figured 'ok this should be ok'. But since it was only a link to a git repo (which I followed) I only got confused. Why is there typescript files? Why are their build files? What's going on here? Where's the Containerfile, what is happening here?

Anyway, I pulled the container, and wanted to enter to container to run rtl_433 from within. This wasn't possible, because the container didn't adhere to the official image consistency guidelinehttps://github.com/docker-library/official-images#consistency). Granted, there's no rule that must be followed here, but from a users point of view, this was rather annoying (work-arounds certainly possible of course, e.g. --entrypoint).

Next, I wanted to build the container, or rather compile the source code using the container, and had to spend some time to find the actual Dockerfile, because it was hidden somewhere deep, under a root dir called images which I figured where about screenshots :p but finally having found the container, I was struck with some really really poor understanding on how to user Docker layering. Randomly put commands into place, or so it seemed.

Regardless, another 'issue' is, that the container is not automatically build upon a commit to master it seems (or it's not obvious and I've missed it?). The repo is untagged and unversioned.

So by bringing the container build into this project itself, we can at least build containers for every (master) commit, meaning it becomes super easy to run 'whatever is on master today'. Also (properly) tagged releases are also build, so version pinning is trivial and logical (though this is certainly also possible in the other repo). But there's also the trust issue, by having an official release from this repo, means people should be able to blindly trust things.

For me, my main trigger was, as I wrote above, I wanted to change the source, compile and run it; without having to setup a build environment and installing binaries that do not come from my package manager. This was now trivial (due to docker build; docker run from within the very same repo.

One thing I purposely didn't do, is do builds for many different kind of versions of operating systems (alpine-X, debian-Y) which I find not very useful. This is the same reason packaging for all distro combo's shouldn't be done here.

P.S. I'd like to mention I did the same for a few other projects as well; for example clamav or tvheadend. It's not very unusual :)