LMSTestingDocker

Builds the Koha LMSCloud packages (koha-common, koha-l10n) and the container images built from them.

Why

Upstream Koha Testing Docker (KTD) installs koha-common from the community apt repository. We run Koha-LMSCloud, our fork, so the packages and the images have to come from our code. Every set we hand to hosts must be traceable to the exact commits it was built from, and tested the way hosts use it: as an upgrade, with only the dependencies the package declares.

What

Koha-LMSCloud checkout ──┐
koha-l10n checkout ──────┼─ Phase A ─▶ out/debian/   koha-common + koha-l10n .debs
                         │                           + build-manifest.txt
                         │      │
                         │      ├─▶ CI image        both packages on plain Debian,
                         │      │                    one set-up instance; used by
                         │      │                    the checks below
                         │      └─▶ Phase B         KTD dev image with koha-common

• Phase A (tools/build-package.sh) builds the packages in a pinned builder image from a throwaway clone of your local checkout. It builds what is committed on the branch, so nothing needs to be pushed first.
• The CI image (tools/build-ci-image.sh) is a fresh host with the set installed. The dependency check runs in it, and the next release's upgrade test starts from it.
• Phase B (tools/build-ktd-image.sh) is the KTD image for development. It is not part of a release.

How

A release, for N = the next unused counter (a version is never reused; see docs/release.md):

export LMSC_SYNC_REPO=/path/to/Koha-LMSCloud
export L10N_REPO=/path/to/koha-l10n
CI=ghcr.io/lmscloudpauld/lmscloud-koha-ci

# 1. build both packages
./tools/build-package.sh --koha-version 25.11.10lmscloudN --koha-branch master --with-l10n
# 2. CI image from the set
./tools/build-ci-image.sh
# 3. dependency check and upgrade test
./tools/test-modules.sh --image $CI:25.11.10-lmscloudN
./tools/test-upgrade.sh --from $CI:25.11.10-lmscloud<N-1>
# 4. copy out/debian/ somewhere else: the next build empties it

Then upload the two .debs with their sha256 sums, and push the CI image tags. Every script takes --help.

For a KTD dev image instead:

./tools/build-image.sh --koha-version <X.Y.Z>lmscloud<N> --koha-branch <branch> \
  --ktd-branch 25.11 --platforms linux/arm64

Docs

• docs/release.md: versions, each release step, the build manifest, rebuilding a set, unreleased security fixes
• docs/packages.md: what the packages contain, and installing them on instance hosts
• docs/images.md: image tags, running the KTD image, its environment variables, git worktrees
• docs/pbuilder.md: building the packages with pbuilder instead of Phase A

Layout

tools/build-image.sh          Orchestrator: Phase A, then Phase B
tools/build-package.sh        Phase A: Koha packages from a Koha-LMSCloud branch
tools/build-l10n-package.sh   koha-l10n package from the koha-l10n fork
tools/build-ci-image.sh       CI image from a Phase A set
tools/test-modules.sh         Dependency check in a CI image
tools/test-upgrade.sh         Upgrade test from the previous release's CI image
tools/build-ktd-image.sh      Phase B: KTD image with the koha-common package
tools/container/              Scripts the tools/ scripts run inside containers
tools/patches/                Koha-source and per-branch Dockerfile patches
tools/builder/                Dockerfile of the koha-builder image
tools/install-node-modules.sh Install node_modules via a Linux Node container
dists/lmscloud/files/run.sh   KTD entrypoint with LMS-specific hooks
docker-compose-lmscloud.yml   Compose overlay for dev use
docker-compose.worktree.yml   Compose overlay: use a git worktree as sync repo
out/debian/                   Package build output (git-ignored)

For the old rsync-based 22.11 workflow, check out the 22.11 branch and follow its README; the tooling here does not apply.