This Solr fork repository contains bugfixes and optimizations targeted for upstream Solr. It is our working repository to file pull requests against the upstream repo. It furthermore contains bugfixes and improvements that not yet made it to the upstream repository.
✅ checked issues have been successfully merged to upstream
⏳ waiting for approval
✨ new fix, needs to filed and pull requested
- ⏳ SOLR-10059 In SolrCloud, every
fq added via
<lst name="appends">
is computed twice. This breaks the collapse filter if configured. Our fix turns this in a different direction, and sanitizes macros in appended fq parameters - ⏳ SOLR-17187 Add the ability to
supply a custom poll interval
in the
updateHandler
. This is of interest for TLOG/PULL replica setups with longer commit intervals. - ✨ SOLR-17334 Minor bugs in Solr
dedicated coordinator mode. Fix access to the root resource and allow coordinator
requests outside of the
/select
handler - ✨ SOLR-17337 Show proper distributed stage id
- ⏳ SOLR-16497 Allow finer grained locking in SolrCores
- ✨ SOLR-xxxx Add an
instrumented
HttpShardHandlerFactory
- ✅ SOLR-17185 Open up
ValueAugmenterFactory.ValueAugmenter
for extension - ✅ SOLR-15377 Do not swallow exceptions thrown in replication
- ✅ SOLR-16489 CaffeineCache puts thread into infinite loop
- ✅ SOLR-16515 Remove synchronized access to cachedOrdMaps in SlowCompositeReaderWrapper
To incorporate the bugfixed sources and Java releases in your project, add the GitHub Maven Package Repository to your Maven or Gradle file.
<project>
<repositories>
<repository>
<id>otto-de-solr</id>
<name>Otto.de Solr Fork</name>
<url>https://maven.pkg.github.com/otto-de/solr</url>
</repository>
</repositories>
</project>
Docker images are published for both arm64
and amd64
architectures:
docker run -itp 8983:8983 ghcr.io/otto-de/solr:9.6.1
There is no
latest
tag available for the Docker images
Our goal is to get all improvements merged into upstream. We'll file all our pull requests based on this repository. Before doing any work, please familiarize yourself with the Solr CONTRIBUTING guidelines.
Do not pollute
.gitignore
settings with your local specialities. Use.git/info/exclude
for local git ignores
- If not yet present, open an issue in the Solr Jira Bugtracker. Use the issue number to label your branch and future commits.
- Create
feature/*
branch for your feature that forks off themain
branch - Add the branch-test.yaml Github Action Workflow to your new branch
- After finishing improving Solr, run
./gradlew tidy
to properly format your source code - Check all formalities via
./gradlew check
- Push your new branch
Clone the fork repository and prepare
the upstream
source git repository.
git remote -v
git remote add upstream https://github.com/apache/solr.git
git fetch upstream
sdk use java 11.0.21-tem
If you want to release a new bugfix version of a already existing Solr release
(say 9.6.0-otto-de.2
over 9.6.0-otto-de.1
), follow these steps.
- Locate the current release candidate branch. For Solr
9.6.x
this would becandidates/branch_9_6
- Sync the Apache Solr release branch
branch_9_6
using the GitHub UI - Rebase our release candidate branch onto the Apache Solr release branch and replay all Cherry Pick Commits. Force push our release candidate branch to GitHub
git checkout candidates/branch_9_6
git rebase branch_9_6 --reapply-cherry-picks
git push origin candidates/branch_9_6 --force
- Now cherry pick the new features/issues onto the candidate branch
- Run
./gradlew check
- Push changes to candidate branch
If you want to release a new bugfix version of a new Solr release
(say 9.6.0-otto-de.1
over 9.5.0-otto-de.5
), follow these steps.
- Fork the Solr minor version release branch, e.g.
branch_9_6
into our fork repository
$ git checkout branch_9_6
$ git push origin branch_9_6
- Create a bugfix branch
candiates/branch_9_6
branching off the Solr minor release branch
$ git checkout -b candidates/branch_9_6
- Add our test and relase Github Action Workflows to your
new branch. Run the
branch-test.yaml
GitHub Action manually after push to check the branches baseline.
$ curl -fsLo .github/workflows/branch-test.yaml \
"https://raw.githubusercontent.com/otto-de/solr/about-this-fork/.github/workflows/branch-test.yaml"
$ curl -fsLo .github/workflows/release.yaml \
"https://raw.githubusercontent.com/otto-de/solr/about-this-fork/.github/workflows/release.yaml"
$ git add .github/workflows/branch-test.yaml
$ git add .github/workflows/release.yaml
$ git commit -m "Add branch test and release action"
$ git push origin candidates/branch_9_6
- Cherry pick all fixes from the
features/**
branches to our candidate branch. For each fix, verify that they are still needed! Some may have been merged in the meantime! After each cherry-pick make sure things integrate well (via./gradlew check
).
# [SOLR-10059]
$ git cherry-pick a82b500d3c633621b0062698f540c2974a920fbb
# [SOLR-17187]
$ git cherry-pick 533950b0f58c44e86a38980685e267643a4be1a9
# instrumented shard handler
$ git cherry-pick 394fab8611d25f2568a86a11d584ee77af656907
# [SOLR-16497]
$ git cherry-pick 444e8eec26e45e7f5a128d97282cf4ffc47e8898
# [SOLR-17334]
$ git cherry-pick 57affd329770bdd7c2205e848ab23994750fe79d
# [SOLR-17337]
$ git cherry-pick 0a1bfd7cccd4640a1e1e6ca51982bf8042157cd8
- Push your changes to the candidate branch and trigger the Branch Test GitHub Action for your new release candidate branch.
- Trigger the Release GitHub Action to build and publish a new release