This folder contains various useful scripts for developers, mostly related to releasing new versions of Solr and testing those.
Python scripts require Python 3.6 or above. To install necessary python modules, please run:
pip3 install -r requirements.txt
Used to validate new release candidates (RC). The script downloads an RC from a URL or local folder, then runs a number of sanity checks on the artifacts, and then runs the full tests.
usage: smokeTestRelease.py [-h] [--tmp-dir PATH] [--not-signed] [--local-keys PATH] [--revision REVISION] [--version X.Y.Z(-ALPHA|-BETA)?] [--test-alt-java TEST_ALT_JAVA] [--download-only] [--dev-mode] url ...
Utility to test a release.
positional arguments:
url Url pointing to release to test
test_args Arguments to pass to gradle for testing, e.g. -Dwhat=ever.
options:
-h, --help show this help message and exit
--tmp-dir PATH Temporary directory to test inside, defaults to /tmp/smoke_solr_$version_$revision
--not-signed Indicates the release is not signed
--local-keys PATH Uses local KEYS file instead of fetching from https://archive.apache.org/dist/solr/KEYS
--revision REVISION GIT revision number that release was built with, defaults to that in URL
--version X.Y.Z(-ALPHA|-BETA)?
Version of the release, defaults to that in URL
--test-alt-java TEST_ALT_JAVA
Path to Java alternative home directory, to run tests with if specified
--download-only Only perform download and sha hash check steps
--dev-mode Enable dev mode, will not check branch compatibility
Example usage:
python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/solr/solr-10.0.0-RC1-rev-c7510a0...
The Release Wizard guides the Release Manager through the release process step by step, helping you to to run the right commands in the right order, generating e-mail templates with the correct texts, versions, paths etc, obeying the voting rules and much more. It also serves as a documentation of all the steps, with timestamps, preserving log files from each command etc, showing only the steps and commands required for a major/minor/bugfix release. It also lets you generate a full Asciidoc guide for the release. The wizard will execute many of the other tools in this folder.
usage: releaseWizard.py [-h] [--dry-run] [--init]
Script to guide a RM through the whole release process
optional arguments:
-h, --help show this help message and exit
--dry-run Do not execute any commands, but echo them instead. Display
extra debug info
--init Re-initialize root and version
Go push that release!
usage: buildAndPushRelease.py [-h] [--no-prepare] [--local-keys PATH] [--push-local PATH] [--sign FINGERPRINT]
[--sign-method-gradle] [--gpg-pass-noprompt] [--gpg-home PATH] [--rc-num NUM]
[--root PATH] [--logfile PATH] [--dev-mode]
Utility to build, push, and test a release.
optional arguments:
-h, --help show this help message and exit
--no-prepare Use the already built release in the provided checkout
--local-keys PATH Uses local KEYS file to validate presence of RM's gpg key
--push-local PATH Push the release to the local path
--sign FINGERPRINT Sign the release with the given gpg key. This must be the full GPG fingerprint, not just the
last 8 characters.
--sign-method-gradle Use Gradle built-in GPG signing instead of gpg command for signing artifacts. This may require
--gpg-secring argument if your keychain cannot be resolved automatically.
--gpg-pass-noprompt Do not prompt for gpg passphrase. For the default gnupg method, this means your gpg-agent needs
a non-TTY pin-entry program. For gradle signing method, passphrase must be provided in
gradle.properties or by env.var/sysprop. See ./gradlew helpPublishing for more info
--gpg-home PATH Path to gpg home containing your secring.gpg Optional, will use $HOME/.gnupg/secring.gpg by
default
--rc-num NUM Release Candidate number. Default: 1
--root PATH Root of Git working tree for solr. Default: "." (the current directory)
--logfile PATH Specify log file path (default /tmp/release.log)
--dev-mode Enable development mode, which disables some strict checks
Example usage for a Release Manager:
python3 -u dev-tools/scripts/buildAndPushRelease.py --push-local /tmp/releases/6.0.1 --sign 3782CBB60147010B330523DD26FBCC7836BF353A --rc-num 1
usage: addVersion.py [-h] [-l LUCENE_VERSION] version Add a new version to CHANGES, to Version.java, build.gradle and solrconfig.xml files positional arguments: version New Solr version optional arguments: -h, --help show this help message and exit -l LUCENE_VERSION Optional lucene version. By default will read gradle/libs.versions.toml
usage: reproduceJenkinsFailures.py [-h] [--no-git] [--iters N] URL Must be run from a Solr git workspace. Downloads the Jenkins log pointed to by the given URL, parses it for Git revision and failed Solr tests, checks out the Git revision in the local workspace, groups the failed tests by module, then runs 'ant test -Dtest.dups=%d -Dtests.class="*.test1[|*.test2[...]]" ...' in each module of interest, failing at the end if any of the runs fails. To control the maximum number of concurrent JVMs used for each module's test run, set 'tests.jvms', e.g. in ~/lucene.build.properties positional arguments: URL Points to the Jenkins log to parse optional arguments: -h, --help show this help message and exit --no-git Do not run "git" at all --iters N Number of iterations per test suite (default: 5)
usage: githubPRs.py [-h] [--json] [--token TOKEN] Find open Pull Requests that need attention optional arguments: -h, --help show this help message and exit --json Output as json --token TOKEN Github access token in case you query too often anonymously
Scaffold a new module and include it into the build. It will set up the folders and all for you, so the only thing you need to do is add classes, tests and test-data.
usage: scaffoldNewModule.py [-h] name full_name description
Scaffold new module into solr/modules/<name>
positional arguments:
name code-name/id, e.g. my-module
full_name Readable name, e.g. "My Module"
description Short description for docs
optional arguments:
-h, --help show this help message and exit
Example: ./scaffoldNewModule.py foo "My Module" "Very Useful module here"
Migrates the legacy CHANGES.txt file format to the new logchange YAML-based format. This script parses the monolithic CHANGES.txt file and generates individual YAML files for each changelog entry, organized by version (v10.0.0/, v9.9.0/, etc.).
Each YAML file complies with the schema outlined in dev-docs/changelog.adoc.
usage: changes2logchange.py [-h] [-o OUTPUT_DIR] [--last-released VERSION] changes_file
Positional arguments:
changes_file Path to the CHANGES.txt file to migrate
Optional arguments:
-h, --help Show this help message and exit
-o OUTPUT_DIR, --output-dir OUTPUT_DIR
Output directory for changelog structure (default: ./changelog)
--last-released VERSION Override auto-detected latest released version (e.g., 9.5.0)
Versions newer than this will be routed to unreleased/ folder
Example usage:
# Default behavior
python3 dev-tools/scripts/changes2logchange.py solr/CHANGES.txt
Validates changelog folder structure and feature distribution across development branches (main, stable, release). See dev-docs for more.
Extracts unique author names from all YAML changelog files in a version folder and outputs them as a comma-separated list sorted alphabetically. Used by RM to assemble release notes.
usage: parseContributorsFromChanges.py <version> # Example: Extract contributors for version 9.10.0 python3 dev-tools/scripts/parseContributorsFromChanges.py 9.10.0
TBD
Usage: dev-tools/scripts/cherrypick.sh [<options>] <commit-hash> [<commit-hash>...] -b <branch> Sets the branch(es) to cherry-pick to, typically branch_Nx or branch_x_y -s Skips precommit test. WARNING: Always run precommit for code- and doc changes -t Run the full test suite during check, not only precommit -n Skips git pull of target branch. Useful if you are without internet access -a Enters automated mode. Aborts cherry-pick and exits on error -r <remote> Specify remote to push to. Defaults to 'origin' -p Push to remote. Only done if both cherry-pick and tests succeeded WARNING: Never push changes to a remote branch before a thorough local test Simple script for aiding in back-porting one or more (trivial) commits to other branches. On merge conflict the script will run 'git mergetool'. See 'git mergetool --help' for help on configuring your favourite merge tool. Check out Sublime Merge (smerge). Example: # Backport two commits to both stable and release branches dev-tools/scripts/cherrypick.sh -b branch_9x -b branch_9_0 deadbeef0000 cafebabe1111