| = Dependency upgrades |
| // Licensed to the Apache Software Foundation (ASF) under one |
| // or more contributor license agreements. See the NOTICE file |
| // distributed with this work for additional information |
| // regarding copyright ownership. The ASF licenses this file |
| // to you under the Apache License, Version 2.0 (the |
| // "License"); you may not use this file except in compliance |
| // with the License. You may obtain a copy of the License at |
| // |
| // http://www.apache.org/licenses/LICENSE-2.0 |
| // |
| // Unless required by applicable law or agreed to in writing, |
| // software distributed under the License is distributed on an |
| // "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| // KIND, either express or implied. See the License for the |
| // specific language governing permissions and limitations |
| // under the License. |
| |
| Solr has lots of 3rd party dependencies, defined mainly in `versions.props`. |
| Keeping them up-to-date is crucial for a number of reasons: |
| |
| * minimizing the risk of critical CVE vulnerabilities by staying on a recent and supported version |
| * avoiding "dependency hell", that can arise from falling too far behind |
| |
| Read the https://github.com/apache/solr/blob/main/help/dependencies.txt[help/dependencies.txt] file for an in-depth explanation of how gradle is deployed in Solr, using |
| https://github.com/palantir/gradle-consistent-versions[Gradle consistent-versions] plugin. |
| |
| == Manual dependency upgrades |
| In order to upgrade a dependency, you need to run through a number of steps: |
| |
| 1. Identify the available versions from e.g. https://search.maven.org[Maven Central] |
| 2. Update the version in `versions.props` file |
| 3. Run `./gradlew --write-locks` to re-generate `versions.lock`. Note that this may cause a cascading effect where |
| the locked version of other dependencies also change. |
| 4. Run `./gradlew updateLicenses` to re-generate SHA1 checksums of the new jar files. |
| 5. Once in a while, a new version of a dependency will transitively bring in brand-new dependencies. |
| You'll need to decide whether to keep or exclude them. See `help/dependencies.txt` for details. |
| |
| == Renovate bot Pull Requests |
| A member of the Solr community operates a Github bot running https://github.com/renovatebot/renovate[Renovate], which |
| files Pull Requests to Solr with dependency upgrade proposals. The PRs are labeled `dependencies` and do include |
| changes resulting from `gradle --write-locks` and `updateLicenses`. |
| |
| Community members and committers can then review, and if manual changes are needed, help bring the PR to completion. |
| For many dependencies, a changelog is included in the PR text, which may help guide the upgrade decision. |
| |
| The scans are run on a schedule. New PRs are filed every Sunday, and only dependency versions that are at least |
| 5 days old are suggested, to guard against bad apples. If a new *major* version of a dependency is available, |
| that will get its own separate Pull Request, so you can choose. |
| |
| If an upgrade is decided, simply merge (and backport) the PR. To skip an upgrade, close the PR. If a PR is left open, |
| it will be re-used and auto updated whenever a newer patch- or minor version gets available. Thus, one can reduce |
| churn from frequently-updated dependencies by delaying merge until a few weeks before a new release. One can also |
| choose to change to a less frequent schedule or disable the bot, by editing `renovate.json` |
| |
| === Configuring renovate.json |
| While the bot runs on a https://github.com/solrbot/renovate-github-action[GitHub repo external to the project], |
| the bot behavior can be tailored by editing `.github/renovate.json` in this project. |
| See https://docs.renovatebot.com[Renovatebot docs] for available options. |
