Build the image in CI - #94
Merged
estebanzimanyi merged 1 commit intoAug 31, 2026
Merged
Conversation
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.
estebanzimanyi
force-pushed
the
ci/build-the-image
branch
from
August 31, 2026 21:47
926c741 to
b6124c0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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=ONturns on the H3 family, whichwants
libh3-dev, and Debian bookworm carries no such package, so configure endsH3=ON was requested but libh3 was not found. The image now builds on thedistribution MobilityDB's own
meos.ymlbuilds MEOS on, with the dependency setthat workflow installs: Ubuntu 24.04, which carries libh3-dev 4.1.0, plus geos,
proj, json-c, gdal, xml2 and zlib. A
-DMEOS=ONbuild needs neither the PostgreSQLserver headers nor GSL nor PostGIS, so none of the three is installed.
jmeos-core/pom.xmlnames${project.basedir}/src/libmeos.so, so the librarybelongs in the module's own
src/— the pathtools/regen-from-catalog.shand theCI build already copy it to. The image copied it to a top-level
src/this treedoes not have. Clearing
jar/goes with it:.dockerignorekeeps that directoryout of the context, as
.gitignorekeeps 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=ONcarries nots2cell_inand notposechain_in, while the surface generated from the catalog of master names both;temporal_mergeis the positive control, so a check reading the wrong file failsdifferently 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.