h2. Analysis of PR [xwiki/xwiki-docker#37|https://github.com/xwiki/xwiki-docker/pull/37] (branch {{feat/solr-dockerfile}}, by GridexX)
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.
h3. 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/}}.
h3. 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 fetches the two core artifacts with {{curl}} and 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.
h3. 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. {{<version>/solr/}}) rather than {{<version>/<db>-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).
h3. 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.)_
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
