Analysis of PR xwiki/xwiki-docker#37

This is a review of the existing PR against this issue, captured so we can decide later what to do with it. It has been converted to an Improvement because the PR turned the original doc bug into a feature: shipping a new prebuilt XWiki Solr Docker image.

What the PR does

Instead of only fixing the broken contrib/solr/solr-init.sh process, the PR introduces a prebuilt XWiki Solr Docker image (template/solr/Dockerfile) that bakes the XWiki Solr cores in, so users no longer run manual steps. To wire it into the build it:
* Adds solr-tomcat as a 4th entry in the variants list in build.gradle.
* Adds solrCoreUrl / solrMinimalCoreUrl tokens to the 14 and 15 cycles.
* Deletes contrib/solr/solr-init.sh, updates README.md, and regenerates 14/solr-tomcat/ and 15/solr-tomcat/.

1) Is the PR correct/valid?

The concept is valid and endorsed. vmassol welcomed it, and the Docker official-images maintainer (tianon) accepted it conceptually in [docker-library/official-images#15069|https://github.com/docker-library/official-images/issues/15069]::] "Conceptually that sounds reasonable, although the Dockerfile/Dockerization will need to pass the same review."

But the implementation is not correct/mergeable as-is. Concrete problems:

Wrong integration model. vmassol explicitly said the Solr image should be built "only based on the version and not the DB". The PR instead makes it a DB variant (solr-tomcat). That is conceptually broken: variants are database choices, so a solr-tomcat variant generates a full XWiki+Tomcat+compose stack with no database at all. The Solr image needs to be a separate per-version build, not a member of the DB-variant matrix.

The generated compose file is broken. 15/solr-tomcat/docker-compose.yml has a db service that is completely empty (no image:/build:), and web points DB_HOST=xwiki-solr-db at a service that is never defined. It cannot start; the template's Solr scriptlet is incomplete.

No checksum verification in template/solr/Dockerfile: it {{curl}}s the two core artifacts with no sha256 check. vmassol flagged this directly ("I don't think this will pass validation... See the main Dockerfile"), and tianon confirmed the same review bar applies. Not addressed.

Untrusted/unpinned base images. FROM dockerqa/unzip:latest (a random third-party image) and curlimages/curl. Official-images review will not accept non-official/latest base images. Also FROM solr:8 is old/EOL and is not tied to the Solr version XWiki actually targets.

Deletes the old fallback prematurely. It removes contrib/solr/solr-init.sh while the new image is not published yet, leaving users with neither path until publishing is done.

No publishing wiring. There is no manifest change to docker-library/official-images library/xwiki and no CI/Gradle push logic for the new image (vmassol noted this too).

Note: two earlier review nits were fixed in the current diff: the license header and the OCI LABEL metadata are now present on template/solr/Dockerfile.

Mechanically it is also badly stale and currently in a CONFLICTING merge state:
* It edits tokens['14'] and tokens['15'], which no longer exist; master is now 16 / 17 / 18 / 18.4.
* It generates 14/... and 15/... dirs for dropped versions.
* The entrypoint remote-Solr logic it adds (INDEX_HOST/INDEX_PORT, solr.type=remote, solr.remote.url) is already in the current template, so that part is now redundant.

2) What is left to be done

The PR is effectively abandoned (substantive work dates from 2023) and needs a rework, not a touch-up:

• Decide the model (blocker): build the Solr image per XWiki version, decoupled from the DB variants, not as a variants entry. This likely means a separate generation path/output (e.g. /solr/) rather than /-tomcat/.
• Add sha256 verification for the downloaded Solr core artifacts (mirror the main Dockerfile), with the sha values held in build.gradle tokens.
• Use only official/pinned base images: drop dockerqa/unzip:latest; unzip within an official base (or the solr image itself). Pin the Solr base to the version XWiki uses.
• Rebase onto master: move the token changes from 14/15 to the current cycles (16/17/18 + the 18.4 intermediate), then run ./gradlew and commit the regenerated dirs (CI enforces a zero diff).
• Fix the generated compose: it needs a real Solr service definition and a real DB service, or a design that composes the XWiki Solr image alongside the normal DB variants.
• Keep contrib/solr/solr-init.sh (and the README section pointing to it) until the new image is actually published.
• Do the publishing work: add the entries to docker-library/official-images library/xwiki and the build/push pipeline; only then update README.md to the new process and remove the old one.
• Update README to document the new external-Solr process (and settle the earlier tabs/summary formatting question with the team).

Recommendation

The idea should live on, but PR #37 is too stale and structurally off (variant model, broken compose, no checksums, untrusted base image) to salvage by rebasing. Treat it as a design reference, get agreement on the "separate per-version Solr image" model first, then implement fresh against current master.

(Analysis produced with Claude Code.)