Add MistServer 3.9

[junojense]

Checklist for Review

NOTE: This checklist is intended for the use of the Official Images maintainers both to track the status of your PR and to help inform you and others of where we're at. As such, please leave the "checking" of items to the repository maintainers. If there is a point below for which you would like to provide additional information or note completion, please do so by commenting on the PR. Thanks! (and thanks for staying patient with us ❤️)

• associated with or contacted upstream?
  • repo under https://github.com/DDVTECH (https://github.com/DDVTECH/mistserver is upstream)
• available under an OSI-approved license?
  • "unlicense" (public domain)
• does it fit into one of the common categories? ("service", "language stack", "base distribution")
  • service
• is it reasonably popular, or does it solve a particular use case well?
• does a documentation PR exist? (should be reviewed and merged at roughly the same time so that we don't have an empty image page on the Hub for very long)
  • Add MistServer 3.9 documentation docs#2640
• official-images maintainer dockerization review for best practices and cache gotchas/improvements (ala the official review guidelines)?
• 2+ official-images maintainer dockerization review?
• existing official images have been considered as a base? (ie, if foobar needs Node.js, has FROM node:... instead of grabbing node via other means been considered?)
• if FROM scratch, tarballs only exist in a single commit within the associated history?
• passes current tests? any simple new tests that might be appropriate to add, assuming this image has any other images it might be interchangeable with?

Extra Information

I am associated with upstream, the forked repository is contained in the official MistServer organisation. Our software is public domain, and is "licensed" under the unlicense. The current image on Docker hub builds off alpine and can be found here. The tests seem to be passing. I have also created a documentation PR which passes the markdown formatter.

[github-actions]

Diff for c2b3bb3:

diff --git a/_bashbrew-arches b/_bashbrew-arches
index 8b13789..e85a97f 100644
--- a/_bashbrew-arches
+++ b/_bashbrew-arches
@@ -1 +1,2 @@
-
+amd64
+arm64v8
diff --git a/_bashbrew-cat b/_bashbrew-cat
index bdfae4a..eae212c 100644
--- a/_bashbrew-cat
+++ b/_bashbrew-cat
@@ -1 +1,10 @@
-Maintainers: New Image! :D (@docker-library-bot)
+Maintainers: Jaron Viëtor <[email protected]> (@Thulinma), Marco van Dijk <[email protected]> (@stronk-dev), Carina van der Meer <[email protected]> (@thoronwen), Balder Viëtor <[email protected]> (@Rokamun), Ramkoemar Bhoera <[email protected]> (@ramkoemar), Juno Jense <[email protected]> (@junojense)
+GitRepo: https://github.com/DDVTECH/mistserver-docker-builder.git
+GitFetch: refs/heads/main
+GitCommit: a0d4de02e3f9c3044a652cf6cbd56d4aba8c0315
+Builder: buildkit
+
+Tags: latest, 3.9.2
+Architectures: amd64, arm64v8
+Directory: 3.9.2
+File: Dockerfile.mistserver
diff --git a/_bashbrew-list b/_bashbrew-list
index e69de29..59cbf92 100644
--- a/_bashbrew-list
+++ b/_bashbrew-list
@@ -0,0 +1,2 @@
+mistserver:3.9.2
+mistserver:latest
diff --git a/_bashbrew-list-build-order b/_bashbrew-list-build-order
index e69de29..4e2ea6f 100644
--- a/_bashbrew-list-build-order
+++ b/_bashbrew-list-build-order
@@ -0,0 +1 @@
+mistserver:3.9.2
diff --git a/mistserver_3.9.2/Dockerfile.mistserver b/mistserver_3.9.2/Dockerfile.mistserver
new file mode 100644
index 0000000..eb2147a
--- /dev/null
+++ b/mistserver_3.9.2/Dockerfile.mistserver
@@ -0,0 +1,28 @@
+FROM alpine AS mist_build
+
+# Pull in build requirements
+RUN apk add --no-cache git patch meson ninja gcc g++ linux-headers pigz curl cjson pkgconfig
+
+# Fetch MistServer from version-pinned source
+RUN curl -fsSL -o /tmp/src.tar.gz "https://github.com/DDVTECH/mistserver/archive/refs/tags/3.9.2.tar.gz" && mkdir /src && tar -xzf /tmp/src.tar.gz --strip-components=1 -C /src && rm -f /tmp/src.tar.gz
+
+# Install mbedtls
+RUN mkdir -p /deps/build/mbedtls && curl -fsSL -o /tmp/mbedtls-3.6.5.tar.bz2 "https://github.com/Mbed-TLS/mbedtls/releases/download/mbedtls-3.6.5/mbedtls-3.6.5.tar.bz2" && tar -xjf /tmp/mbedtls-3.6.5.tar.bz2 -C /deps && rm -f /tmp/mbedtls-3.6.5.tar.bz2
+RUN cp /src/subprojects/packagefiles/mbedtls/meson.build /deps/mbedtls-3.6.5/ && cp /src/subprojects/packagefiles/mbedtls/include/mbedtls/mbedtls_config.h /deps/mbedtls-3.6.5/include/mbedtls/ && cd /deps/build/mbedtls/ && meson setup /deps/mbedtls-3.6.5 -Dstrip=true && meson install
+
+# Build MistServer
+ARG MIST_OPTS
+ARG DEBUG=3
+ARG VERSION=3.9.2
+ARG TARGETPLATFORM
+ARG RELEASE=Docker_${TARGETPLATFORM}
+RUN mkdir /build/ && cd /build && meson setup /src -DDOCKERRUN=true -DNOUPDATE=true -DDEBUG=${DEBUG} -DVERSION=${VERSION} -DRELEASE=${RELEASE} -Dstrip=true ${MIST_OPTS} && ninja install
+
+# Expose MistServer
+FROM alpine
+RUN apk add --no-cache libstdc++ cjson
+COPY --from=mist_build /usr/local/ /usr/local/
+LABEL org.opencontainers.image.authors="Jaron Viëtor <[email protected]>"
+EXPOSE 4242 8080 1935 5554 8889/udp 18203/udp
+ENTRYPOINT ["MistController"]
+HEALTHCHECK CMD ["MistUtilHealth"]

[junojense]

Using a Docker-specific repository now that contains Dockerfiles for different versions, instead of directly including the source leading to jobs failing. The PR should be ready for review.

[junojense]

Hi again, can this PR be looked at?

[tianon]

I've taken a first pass at review, and these are my very high-level notes from it:

At first glance, the multi-stage build doesn't seem to be one of the cases in https://github.com/docker-library/faq#multi-stage-builds (using apk add --virtual and something like scanelf to find the runtime deps and keep them afterwards would probably work really well).

That's a lot of ARG - are all these really meaningful? Should their values be documented better? (Our build tooling won't ever use them, so they're mostly just noise here.)

Explicitly using Builder: buildkit isn't really necessary (the TARGETPLATFORM value it seems to be used to get isn't something we recommend relying on, preferring instead to see userspace/runtime detection based off things like apk --print-arch).

Building mbedtls from source is a little eyebrow-raising -- Alpine contains the same version 3.6.5, is there a reason it isn't used? (https://pkgs.alpinelinux.org/package/v3.23/main/x86_64/mbedtls-dev)

Having such long single-line RUN lines is really hard to read/review -- those should be split up with \ and newlines.

Using FROM alpine with no specific version is going to have a large tendency to break when the "square wheel" rolls, so we highly recommend pinning to an explicit release of Alpine like FROM alpine:3.23 so that you can more directly control/manage the rolling of that wheel (and the breakage that may or may not come from it).

Using LABEL is not recommended, as the inheritance behavior of it is really poor; see #3540, especially #3540 (comment) (our build system automatically adds appropriate similar annotations).

Using HEALTHCHECK is also not something I'd personally recommend setting on the image (https://github.com/docker-library/faq#healthcheck) -- perhaps this command should be included in the documentation instead, so that users who want its behavior can get it easily? (in either a healthcheck in Docker or an appropriate probe in Kubernetes, for example, which won't read HEALTHCHECK metadata anyways)

Ideally the download of the source code would have some kind of verification, but that's a little hard with the source code tarball being generated by GitHub directly. 😔