|
| 1 | +<!-- |
| 2 | + Licensed to the Apache Software Foundation (ASF) under one or more |
| 3 | + contributor license agreements. See the NOTICE file distributed with |
| 4 | + this work for additional information regarding copyright ownership. |
| 5 | + The ASF licenses this file to You under the Apache License, Version 2.0 |
| 6 | + the "License"); you may not use this file except in compliance with |
| 7 | + the License. You may obtain a copy of the License at |
| 8 | +
|
| 9 | + http://www.apache.org/licenses/LICENSE-2.0 |
| 10 | +
|
| 11 | + Unless required by applicable law or agreed to in writing, software |
| 12 | + distributed under the License is distributed on an "AS IS" BASIS, |
| 13 | + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 14 | + See the License for the specific language governing permissions and |
| 15 | + limitations under the License. |
| 16 | + --> |
| 17 | +# AGENTS.md for Apache Solr |
| 18 | + |
| 19 | +While README.md and CONTRIBUTING.md are mainly written for humans, this file is a condensed knowledge base for LLM coding agents on the Solr codebase. See https://agents.md for more info and how to make various coding assistants consume this file. Also see `dev-docs/how-to-contribute.adoc` for some guidelines when using genAI to contribute to Solr. |
| 20 | + |
| 21 | +## Licensing and Dependencies |
| 22 | + |
| 23 | +- Follow Apache Software Foundation licensing rules, avoid adding a dependency with a banned license |
| 24 | +- Always apply the Apache License to new source files |
| 25 | +- All versions must be delcared in `gradle/libs.versions.toml`, never build.gradle files |
| 26 | +- Try first declaring a dependency without a version (the version might already be in a BOM); and if fails to resolve _then_ specify a version |
| 27 | +- The build may complain with "Dependency analysis found issues.", a category like "usedUndeclaredArtifacts", and a dependency list. Declare or undeclare these dependencies, as the category will imply. The special 'permit*' configurations are a choice of last resort. |
| 28 | +- Always run `gradlew updateLicenses resolveAndLockAll --write-locks` after adding or changing a dependency. See `dev-docs/gradle-help/dependencies.txt` for more info |
| 29 | + |
| 30 | +## Build and Development Workflow |
| 31 | + |
| 32 | +- When done or preparing to commit changes to java source files, be sure to run `gradlew tidy` to format the code |
| 33 | +- Always run `gradlew check -x test` before declaring a feature done |
| 34 | + |
| 35 | +## Code Quality and Best Practices |
| 36 | + |
| 37 | +- Use the project's custom `EnvUtils` to read system properties. It auto converts env.var SOLR_FOO_BAR to system property solr.foo.bar |
| 38 | +- Be careful to not add non-essential logging! If you add slf4j log calls, make sure to wrap debug/trace level calls in `logger.isXxxEnabled()` clause |
| 39 | +- Validate user input. For file paths, always call `myCoreContainer.assertPathAllowed(myPath)` before using |
| 40 | + |
| 41 | +## Testing |
| 42 | + |
| 43 | +- When adding a test to an existing suite/file, keep the same style / design choices |
| 44 | +- When adding a *new* Java test suite/file: |
| 45 | + - Subclass SolrTestCase, or if SolrCloud is needed then SolrCloudTestCase |
| 46 | + - If SolrTestCase and need to embed Solr, use either EmbeddedSolrServerTestRule (doesn't use HTTP) or SolrJettyTestRule if HTTP/Jetty is relevant to what is being tested. |
| 47 | + - Avoid SolrTestCaseJ4 for new tests |
| 48 | + |
| 49 | +- See `dev-docs/gradle-help/tests.txt` for hints on running tests |
| 50 | + |
| 51 | +## Documentation |
| 52 | + |
| 53 | +- For major or breaking changes, add a prominent note in reference guide major-changes-in-solr-X.adoc |
| 54 | +- Always consider whether a reference-guide page needs updating due to the new/changed features. Target audience is end user |
| 55 | +- For changes to build system and other developer-focused changes, consider updating or adding docs in dev-docs/ folder |
| 56 | +- Keep all documentation including javadoc concise |
| 57 | +- New classes should have some javadocs |
| 58 | +- Changes should not have code comments communicating the change, which are instead great comments to leave for code review / commentary |
| 59 | + |
| 60 | +## Changelog |
| 61 | + |
| 62 | +- We use the "logchange" tooling to manage our changelog. See `dev-docs/changelog.adoc` for details and conventions |
| 63 | +- To scaffold a new changelog entry, run `gradlew writeChangelog`, and then edit the new file located in `changelog/unreleased/`. |
| 64 | +- Do not add a changelog entry before a JIRA issue or a Github PR is assigned, as one is required. |
0 commit comments