Debian builds actually based upon Alpine

[ravngr]

I was experiencing an issue similar #68, getting TLS to work with MQTT. I'd previously had issues with the Alpine container and had switched to the Debian-based builds to get everything working. The issue linked to by @metrafonic had a few hints on checking the SSL library, which I tried to double checked only to find that apt was missing from the Debian builds. Doing a sanity check revealed the *-debian-* images are actually based on Alpine:

user@hostname:/path$ docker run --rm -it --entrypoint /bin/sh ghcr.io/hertzg/rtl_433_docker:22.11-debian-bullseye
Unable to find image 'ghcr.io/hertzg/rtl_433_docker:22.11-debian-bullseye' locally
22.11-debian-bullseye: Pulling from hertzg/rtl_433_docker
7264a8db6415: Already exists 
1bbc95af9f57: Pull complete 
4f4fb700ef54: Pull complete 
41f9d701da10: Pull complete 
Digest: sha256:3c1c545a350b71cbf84804ba97719372c5e460ff5374ef899d084834f4c73f67
Status: Downloaded newer image for ghcr.io/hertzg/rtl_433_docker:22.11-debian-bullseye
~ # cat /etc/os-release 
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.18.3
PRETTY_NAME="Alpine Linux v3.18"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
~ # 

The current tags for 22.11-debian-bullseye¹ and 22.11-debian-bookworm² likewise share the base layer 4693057ce2364720d39e57e85a5b8e0bd9ac3573716237736d6470ec5b7b7230, which is an Alpine base.

A recent GitHub action log also indicates that the Alpine configuration is being pulled at runtime to build the *-debian-* images:

I'm not familiar with TypeScript or the build process used by the project, but I think the offending lines were introduced in 62d7991, meaning all the builds since May have been based on the wrong image. I think this could help explain some other recent issues, like #83.

rtl_433_docker/src/debian.config.ts

Lines 78 to 79 in cf023df

	context: "./images/alpine/build-context",
	file: "./images/alpine/build-context/Dockerfile",

I can submit a PR just changing those lines, but without being more familiar with the build system I'm not sure if I can accurately test it.

Footnotes

1. ghcr.io/hertzg/rtl_433_docker@sha256:3c1c545a350b71cbf84804ba97719372c5e460ff5374ef899d084834f4c73f67 ↩

2. ghcr.io/hertzg/rtl_433_docker@sha256:75c23722d3b83748ab1d581db5b2f94b4657ec55f4b3652b2f349e3d18acf96a ↩

[hertzg]

Hey @ravngr, definitely a bug! Great spot 🦅 👁️ and a very good writeup with supporting facts!

And yes that would be the offending line, the build system is pretty simple most of the logic is in those .config.ts files.
You can run deno run src/main.ts and look at the output (it will ask for some permissions interactively).

Feel free to submit a PR happy to get it reviewed and merged

EDIT: Submitted a PR, once merged and the builds finish would be nice if you can have a look and confirm it's fixed.

[hertzg]

Should be fixed once these jobs pass https://github.com/hertzg/rtl_433_docker/actions/runs/6038184653
I'll be re-running the failed ones as the rate-limits cause pushes or cache pushes to fail causing the task to fail as well.

[ravngr]

Awesome! Green ticks across the board. The logs and /etc/os-release look good and I'm passed the TLS error... into a different one but I'll figure it out 😅

Thanks for the patch/container/ongoing maintenance @hertzg 😁

Edit: Resolved the issue I was having (bad auth) and it's been ticking away happily all day 👌