|
| 1 | +# Elasticsearch |
| 2 | + |
| 3 | +## Toolchain Snapshot |
| 4 | +- **Java**: JDK 25 via `JAVA_HOME`; use the bundled Gradle wrapper (`./gradlew`). |
| 5 | +- **Build tooling**: Gradle composite build with `build-conventions`, `build-tools`, and `build-tools-internal`; Docker is required for some packaging/tests. |
| 6 | +- **OS packages**: Packaging and QA jobs expect ephemeral hosts; do not run packaging suites on your workstation. |
| 7 | +- **Security**: Default dev clusters enable security; use `elastic-admin:elastic-password` or disable with `-Dtests.es.xpack.security.enabled=false`. |
| 8 | +- **Cursor/Copilot rules**: None provided in repo; follow this guide plus CONTRIBUTING.md. |
| 9 | + |
| 10 | +## Build & Run Commands |
| 11 | +- Refer to CONTRIBUTING.md & TESTING.asciidoc for comprehensive build/test instructions. |
| 12 | + |
| 13 | +## Verification & Lint Tasks |
| 14 | +- `./gradlew spotlessJavaCheck` / `spotlessApply` (or `:server:spotlessJavaCheck`): enforce formatter profile in `build-conventions/formatterConfig.xml`. |
| 15 | + |
| 16 | +## Project Structure |
| 17 | +The repository is organized into several key directories: |
| 18 | +* `server`: The core Elasticsearch server. |
| 19 | +* `modules`: Features shipped with Elasticsearch by default. |
| 20 | +* `plugins`: Officially supported plugins. |
| 21 | +* `libs`: Internal libraries used by other parts of the project. |
| 22 | +* `qa`: Integration and multi-version tests. |
| 23 | +* `docs`: Project documentation. |
| 24 | +* `distribution`: Logic for building distribution packages. |
| 25 | +* `x-pack`: Additional code modules and plugins under Elastic License. |
| 26 | +* `build-conventions`, `build-tools`, `build-tools-internal`: Gradle build logic. |
| 27 | + |
| 28 | +## Testing Cheatsheet |
| 29 | +- Standard suite: `./gradlew test` (respects cached results; add `-Dtests.timestamp=$(date +%s)` to bypass caches when reusing seeds). |
| 30 | +- Single project: `./gradlew :server:test` (or other subproject path). |
| 31 | +- Single class: `./gradlew :server:test --tests org.elasticsearch.package.ClassName`. |
| 32 | +- Single package: `./gradlew :server:test --tests 'org.elasticsearch.package.*'`. |
| 33 | +- Single method / repeated runs: `./gradlew :server:test --tests org.elasticsearch.package.ClassName.methodName -Dtests.iters=N`. |
| 34 | +- Deterministic seed: append `-Dtests.seed=DEADBEEF` (each method uses derived seeds). |
| 35 | +- JVM tuning knobs: `-Dtests.jvms=8`, `-Dtests.heap.size=4G`, `-Dtests.jvm.argline="-verbose:gc"`, `-Dtests.output=always`, etc. |
| 36 | +- Debugging: append `--debug-jvm` to the Gradle test task and attach a debugger on port 5005. |
| 37 | +- CI reproductions: copy the `REPRODUCE WITH` line from CI logs; it includes project path, seed, and JVM flags. |
| 38 | +- Yaml REST tests: `./gradlew ":rest-api-spec:yamlRestTest" --tests "org.elasticsearch.test.rest.ClientYamlTestSuiteIT.test {yaml=<relative_test_file_path>}"` |
| 39 | +- Use the Elasticsearch testing framework where possible for unit and yaml tests and be consistent in style with other elasticsearch tests. |
| 40 | +- Use real classes over mocks or stubs for unit tests, unless the real class is complex then either a simplified subclass should be created within the test or, as a last resort, a mock or stub can be used. Unit tests must be as close to real-world scenarios as possible. |
| 41 | +- Ensure mocks or stubs are well-documented and clearly indicate why they were necessary. |
| 42 | + |
| 43 | +### Test Types |
| 44 | +- Unit Tests: Preferred. Extend `ESTestCase`. |
| 45 | +- Single Node: Extend `ESSingleNodeTestCase` (lighter than full integ test). |
| 46 | +- Integration: Extend `ESIntegTestCase`. |
| 47 | +- REST API: Extend `ESRestTestCase` or `ESClientYamlSuiteTestCase`. **YAML based REST tests are preferred** for integration/API testing. |
| 48 | + |
| 49 | +## Dependency Hygiene |
| 50 | +- Never add a dependency without checking for existing alternatives in the repo. |
| 51 | + |
| 52 | +## Formatting & Imports |
| 53 | +- Absolutely no wildcard imports; keep existing import order and avoid reordering untouched lines. |
| 54 | + |
| 55 | +## Types, Generics, and Suppressions |
| 56 | +- Prefer type-safe constructs; avoid raw types and unchecked casts. |
| 57 | +- If suppressing warnings, scope `@SuppressWarnings` narrowly (ideally a single statement or method). |
| 58 | +- Document non-obvious casts or type assumptions via Javadoc/comments for reviewers. |
| 59 | + |
| 60 | +## Naming Conventions |
| 61 | +- REST handlers typically use the `Rest*Action` pattern; transport-layer handlers mirror them with `Transport*Action` classes. |
| 62 | +- REST classes expose routes via `RestHandler#routes`; when adding endpoints ensure naming matches existing REST/Transport patterns to aid discoverability. |
| 63 | +- Transport `ActionType` strings encode scope (`indices:data/read/...`, `cluster:admin/...`, etc.); align new names with these conventions to integrate with privilege resolution. |
| 64 | + |
| 65 | +## Logging & Error Handling |
| 66 | +- Elasticsearch should prefer its own logger `org.elasticsearch.logging.LogManager` & `org.elasticsearch.logging.Logger`; declare `private static final Logger logger = LogManager.getLogger(Class.class)`. |
| 67 | +- Always use parameterized logging (`logger.debug("operation [{}]", value)`); never build strings via concatenation. |
| 68 | +- Wrap expensive log-message construction in `() -> Strings.format(...)` suppliers when logging at `TRACE`/`DEBUG` to avoid unnecessary work. |
| 69 | +- Log levels: |
| 70 | + - `TRACE`: highly verbose developer diagnostics; usually read alongside code. |
| 71 | + - `DEBUG`: detailed production troubleshooting; ensure volume is bounded. |
| 72 | + - `INFO`: default-enabled operational milestones; prefer factual language. |
| 73 | + - `WARN`: actionable problems users must investigate; include context and, if needed, exception stack traces. |
| 74 | + - `ERROR`: reserve for unrecoverable states (e.g., storage health failures); prefer `WARN` otherwise. |
| 75 | +- Only log client-caused exceptions when the cluster admin can act on them; otherwise rely on API responses. |
| 76 | +- Tests can assert logging via `MockLog` for complex flows. |
| 77 | + |
| 78 | +## Javadoc & Comments |
| 79 | +- New packages/classes/public or abstract methods require Javadoc explaining the "why" rather than the implementation details. |
| 80 | +- Avoid documenting trivial getters/setters; focus on behavior, preconditions, or surprises. |
| 81 | +- For tests, Javadoc can describe scenario setup/expectations to aid future contributors. |
| 82 | +- Do not remove existing comments from code unless the code is also being removed or the comment has become incorrect. |
| 83 | + |
| 84 | +## License Headers |
| 85 | +- Default header (outside `x-pack`): Elastic License 2.0, SSPL v1, or AGPL v3—they are already codified at the top of Java files; copy from existing sources. |
| 86 | +- Files under `x-pack` require the Elastic License 2.0-only header; IDEs configured per CONTRIBUTING.md can insert correct text automatically. |
| 87 | + |
| 88 | +## Best Practices for Automation Agents |
| 89 | +- Never edit unrelated files; keep diffs tightly scoped to the task at hand. |
| 90 | +- Prefer Gradle tasks over ad-hoc scripts. |
| 91 | +- When scripting CLI sequences, leverage `gradlew` task. |
| 92 | +- Unrecognized changes: assume other agent; keep going; focus your changes. If it causes issues, stop + ask user. |
| 93 | +- Do not add "Co-Authored-By" lines to commit messages. commit messages should adhere to the 50/72 rule: use a maximum of 50 columns for the commit summary |
| 94 | + |
| 95 | +## Backwards compatibility |
| 96 | +- For changes to a `Writeable` implementation (`writeTo` and constructor from `StreamInput`), add a new `public static final <UNIQUE_DESCRIPTIVE_NAME> = TransportVersion.fromName("<unique_descriptive_name>")` and use it in the new code paths. Confirm the backport branches and then generate a new version file with `./gradlew generateTransportVersion`. |
| 97 | + |
| 98 | +Stay aligned with `CONTRIBUTING.md`, `BUILDING.md`, and `TESTING.asciidoc`; this AGENTS guide summarizes—but does not replace—those authoritative docs. |
0 commit comments