From b6124c0156cfc1785a79e55fffe568060e5600cf Mon Sep 17 00:00:00 2001 From: Esteban Zimanyi Date: Mon, 31 Aug 2026 23:33:08 +0200 Subject: [PATCH] Build the image in CI MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Nothing in this repository builds the image, which is how it came to pin a JMEOS branch nobody updates, to clone a personal fork of MobilityDB, and to copy libmeos to a path the module layout does not have: no run ever executed those lines. Building it is the test, so a workflow does. It runs on a change to the image or to this workflow, on a push to main, and weekly — the weekly run is the one that matters, since the image tracks MobilityDB master and can start failing with nothing here having changed. Its first run is what the image needs. `-DALL=ON` turns on the H3 family, which wants `libh3-dev`, and Debian bookworm carries no such package, so configure ends `H3=ON was requested but libh3 was not found`. The image now builds on the distribution MobilityDB's own `meos.yml` builds MEOS on, with the dependency set that workflow installs: Ubuntu 24.04, which carries libh3-dev 4.1.0, plus geos, proj, json-c, gdal, xml2 and zlib. A `-DMEOS=ON` build needs neither the PostgreSQL server headers nor GSL nor PostGIS, so none of the three is installed. `jmeos-core/pom.xml` names `${project.basedir}/src/libmeos.so`, so the library belongs in the module's own `src/` — the path `tools/regen-from-catalog.sh` and the CI build already copy it to. The image copied it to a top-level `src/` this tree does not have. Clearing `jar/` goes with it: `.dockerignore` keeps that directory out of the context, as `.gitignore` keeps it out of the tree. A successful build still says nothing about which library the image holds, and jnr-ffi resolves lazily, so a library missing a symbol faults at the call rather than at load: no build and no link reports it. The job therefore asks the image. A libmeos configured without `-DALL=ON` carries no `ts2cell_in` and no `tposechain_in`, while the surface generated from the catalog of master names both; `temporal_merge` is the positive control, so a check reading the wrong file fails differently from one reading a narrow build. Built and probed locally, the image reads 2, 2 and 2 where a non-all-families libmeos reads 0, 0 and 2. --- .github/workflows/docker.yml | 51 ++++++++++++++++++++++++++++++++++++ Dockerfile | 24 +++++++++++------ 2 files changed, 67 insertions(+), 8 deletions(-) create mode 100644 .github/workflows/docker.yml diff --git a/.github/workflows/docker.yml b/.github/workflows/docker.yml new file mode 100644 index 000000000..b3822e3ab --- /dev/null +++ b/.github/workflows/docker.yml @@ -0,0 +1,51 @@ +name: Docker image + +# Nothing else in this repository builds the image, so its clone refs and its cmake +# flags go stale unnoticed — which is exactly how it came to pin a branch nobody +# updates. Building it IS the test. +# +# It runs on a change to the image or to this workflow, on a push to main, and +# weekly. The weekly run is the one that matters: the image tracks MobilityDB +# master, so it can start failing with nothing in this repository having changed. + +on: + pull_request: + paths: [Dockerfile, .dockerignore, .github/workflows/docker.yml] + push: + branches: [main] + paths: [Dockerfile, .dockerignore, .github/workflows/docker.yml] + schedule: + - cron: "17 5 * * 1" + workflow_dispatch: + +jobs: + image: + name: Build the image and check what it carries + runs-on: ubuntu-latest + # The image compiles MobilityDB from source with every family on. + timeout-minutes: 90 + + steps: + - uses: actions/checkout@v4 + + - name: Build the image + run: docker build --progress=plain -t jmeos-ci:${{ github.sha }} . + + # A build that succeeds still proves nothing about WHICH library the image + # holds, and a narrower one is the failure this guards: a libmeos configured + # without -DALL=ON carries no S2CELL and no POSECHAIN entry, while the jar + # generated from the catalog of master names both. `temporal_merge` is the + # positive control — were it missing too, the check would be reading the + # wrong file rather than a narrow build. + - name: The image carries the tree and an all-families libmeos + run: | + docker run --rm jmeos-ci:${{ github.sha }} bash -euc ' + test -f /usr/local/jmeos/pom.xml + test -f /usr/local/jmeos/jmeos-core/src/libmeos.so + L=/usr/local/lib/libmeos.so + for s in ts2cell_in tposechain_in temporal_merge; do + n=$(grep -ac "$s" "$L" || true) + echo "$s: $n" + [ "${n:-0}" -ge 1 ] || { echo "::error::$L carries no $s"; exit 1; } + done + ' diff --git a/Dockerfile b/Dockerfile index b3d57893e..312db7ab1 100644 --- a/Dockerfile +++ b/Dockerfile @@ -1,10 +1,17 @@ -FROM debian:bookworm-slim +FROM ubuntu:24.04 LABEL maintainer=nidhalmareghni8@gmail.com -# install corretto after verifying that the key is the one we expect. +# The MEOS build dependencies are the set MobilityDB's own MEOS workflow installs +# (.github/workflows/meos.yml), on the distribution it installs them on: `libh3-dev` +# is what -DALL=ON needs for the H3 family and Debian bookworm has no such package, +# while Ubuntu 24.04 carries it. A -DMEOS=ON build needs neither the PostgreSQL +# server headers nor GSL nor PostGIS, so none of the three is installed. +# +# Corretto is installed after verifying that the key is the one we expect. RUN apt-get update \ - && apt-get install -y git curl gnupg build-essential tree vim cmake postgresql-server-dev-15 libproj-dev libjson-c-dev libgsl-dev libgeos-dev postgis \ + && apt-get install -y git curl gnupg build-essential cmake \ + libgeos-dev libproj-dev libjson-c-dev libgdal-dev libh3-dev libxml2-dev zlib1g-dev \ && export GNUPGHOME="$(mktemp -d)" \ && curl -fL https://apt.corretto.aws/corretto.key | gpg --batch --import \ && gpg --batch --export '6DC3636DAE534049C8B94623A122542AB04F24E3' > /usr/share/keyrings/corretto.gpg \ @@ -41,11 +48,12 @@ RUN ln -s ${MAVEN_HOME}/bin/mvn /usr/bin/mvn # named here is one nothing updates. COPY . /usr/local/jmeos -# Copy libmeos.so to src/ (used by JarLibraryLoader on Linux) -RUN cp /usr/local/lib/libmeos.so /usr/local/jmeos/src/libmeos.so - -# Clear pre-built jars -RUN rm -f /usr/local/jmeos/jar/* +# Place libmeos where the build reads it: jmeos-core/pom.xml names +# ${project.basedir}/src/libmeos.so, so the module's own src/ is the destination, +# the same path tools/regen-from-catalog.sh and the CI build copy it to. +# JarLibraryLoader extracts it from the jar at run time, with LD_LIBRARY_PATH the +# fallback. +RUN cp /usr/local/lib/libmeos.so /usr/local/jmeos/jmeos-core/src/libmeos.so ENV LD_LIBRARY_PATH=/usr/local/lib