The vips build is untested, and CI's libvips is not the one we ship #3746

Two gaps that reinforce each other.

Nothing tests the vips build. make test runs go test -tags '$(TAGS)' with TAGS empty, and no pipeline step passes the tag either, so every file behind //go:build enable_vips is compiled by the image build and by nothing else: preprocessor_vips.go, encoding_vips.go, generator_vips.go, mimetypes_vips.go. The images build with ENABLE_VIPS=true, so the resize path that ships is the one no test ever exercises, while the tests cover the pure Go path that ships nowhere.

The libvips in CI is not the libvips we ship. The runtime image is alpine:3.24 with apk add vips, the test image is quay.io/opencloudeu/golang-ci:1.26. Same version, different loaders:

# quay.io/opencloudeu/golang-ci:1.26
vips-8.18.2
vips -l | grep -c magick   ->  7      (VipsForeignLoadMagick7)

# alpine:3.24 + apk add vips
vips-8.18.2
vips -l | grep -c magick   ->  0

So even once the vips path is tested, testing it in the CI image measures format support the product does not have.

What that combination hides today, vips copy <file> out.v in both images:

libvips reads BMP and ICO only through the ImageMagick loader. image/bmp and image/x-ms-bmp are in SupportedMimeTypes in both builds, and preprocessor.ForType sends them to ImageDecoder, which hands the raw bytes to vips.NewImageFromReader. In the shipped container there is no loader for them, so a BMP thumbnail cannot work there, although the service advertises the type and the pure Go build handles it. Measured on the loader level and read off the code path, not yet reproduced through a running server.

Ways out, not decided:

• install a libvips with ImageMagick support in the runtime image. Note that apk add vips-magick alone is not enough: it pulls only imagemagick-libs, and ImageMagick then answers NoDecodeDelegateForThisImageFormat for both files. The CI image additionally carries imagemagick and its coder subpackages (jpeg, tiff, webp, jp2, svg, openexr, pango), which is where its BMP and ICO support comes from
• run the vips tests in an image whose libvips matches the runtime image, so what CI measures is what ships
• decode the formats the shipped libvips cannot read in Go before handing them over, and keep SupportedMimeTypes to what the shipped build really reads