11The ES|QL documentation is composed of static content and generated content.
22The static content exists in this directory and can be edited by hand.
3- However, the sub-directories ` _snippets ` , ` images ` and ` kibana ` contain mostly
4- generated content.
3+ However, the subdirectories ` _snippets ` , ` images ` and ` kibana ` contain a mix
4+ of static and generated content, and so updating them is a bit more involved.
5+
6+ ## Static content
7+
8+ The root ` esql ` directory and the following two subdirectories contain static content:
9+ * ` commands ` - contains the static content for the ES|QL commands.
10+ This content will typically contain mostly ` include ` directives for content in the ` _snippets ` or ` images ` directories.
11+ * ` functions-operators ` - contains the static content for the ES|QL functions and operators.
12+ Again this will contain mostly ` include ` directives for content in the ` _snippets ` or ` images ` directories.
13+
14+ ## Mixed static and generated content
15+
16+ Generated content is created by running the ESQL tests in the ` x-pack/plugin/esql ` module.
17+ It will be written into three subdirectories of the ` esql ` directory:
518
619### _ snippets
720
8- In ` _snippets ` there are files that can be included within other files
9- using the [ File Inclusion] ( https://elastic.github.io/docs-builder/syntax/file_inclusion/ )
21+ In ` _snippets ` there are files that can be included within other files using the
22+ [ File Inclusion] ( https://elastic.github.io/docs-builder/syntax/file_inclusion/ )
1023feature of the Elastic Docs V3 system.
1124Most, but not all, files in this directory are generated.
1225In particular the directories ` _snippets/functions/* ` and ` _snippets/operators/* `
@@ -21,7 +34,7 @@ contain subdirectories that are mostly generated:
2134
2235Most functions can use the generated docs generated in the ` layout ` directory.
2336If we need something more custom for the function we can make a file in this
24- directory that can ` include:: ` any parts of the files above.
37+ directory that can ` include ` any parts of the files above.
2538
2639To regenerate the files for a function run its tests using gradle.
2740For example to generate docs for the ` CASE ` function:
@@ -34,17 +47,140 @@ To regenerate the files for all functions run all of ESQL's tests using gradle:
3447./gradlew :x-pack:plugin:esql:test
3548```
3649
50+ #### Lists
51+
52+ The ` _snippets/lists ` directory contains re-usable content for lists of commands, functions or operators.
53+ Whenever adding a command, function or operator, you usually need to add it to one of these lists.
54+ The lists should also match natural groupings of the commands, functions or operators.
55+ For example, when adding an aggregation function, add to the ` aggregation-functions.md ` file.
56+
57+ #### Commands
58+
59+ The ` _snippets/commands ` directory contains the content for the ES|QL commands.
60+ There are two subdirectories, one static and one generated:
61+ * ` layout ` - contains the static content for the ES|QL commands.
62+ The files in this directory are the main content for the documentation for the commands.
63+ They are not generated, and so this is the primary place to edit the content, or add new commands.
64+ * ` examples ` - contains the generated content for the ES|QL commands.
65+ The files in this directory are generated from the test ` CommandDocsTests ` in the ` x-pack/plugin/esql ` module.
66+ The structure of the subdirectories mimics the csv-spec files and test tags used in the tests.
67+
68+ Including generated examples in the command documentation is done by using the include directive.
69+
3770### images
3871
39- The ` images ` directory contains ` functions ` and ` operators ` sub-directories with
72+ The ` images ` directory contains ` functions ` and ` operators ` subdirectories with
4073the ` *.svg ` files used to describe the syntax of each function or operator.
4174These are all generated by the same tests that generate the functions and operators docs above.
4275
4376### kibana
4477
45- The ` kibana ` directory contains ` definition ` and ` docs ` sub-directories that are generated:
78+ The ` kibana ` directory contains ` definition ` and ` docs ` subdirectories that are generated:
4679
4780* ` kibana/definition ` - function definitions for kibana's ESQL editor
4881* ` kibana/docs ` - the inline docs for kibana
4982
5083These are also generated as part of the unit tests described above.
84+
85+ ## Under the hood
86+
87+ There are three overlapping mechanisms for generating the content:
88+ * The ` AbstractFunctionTestCase ` class generates the content for all the functions and most operators.
89+ This class makes use of the ` DocsV3Support ` class to generate the content.
90+ It uses the ` @FunctionInfo ` and ` @Param ` annotations on function and operator classes to know what content should be generated.
91+ All tests that extend this class will automatically generate the content for the functions they test.
92+ * Some operators do not have a clear class or test class, and so the content is generated by custom
93+ tests that do not extend the ` AbstractOperatorTestCase ` class. See, for example, operators such as ` Cast :: ` ,
94+ which uses ` CastOperatorTests ` to call directly into the ` DocsV3Support ` class to generate the content.
95+ * Commands do not have dedicated classes or test classes with annotation that can be used.
96+ For this reason, the command documentation is generated by the ` CommandDocsTests ` class.
97+ Currently, this only covers tested examples used in the documentation, and all other commands
98+ content is static.
99+ Since there are no annotations to mark which examples to use, the command documentation
100+ relies on the docs author providing the knowledge of which examples to use by creating subdirectories
101+ and examples files that match the csv-spec files and tags to include.
102+
103+ To help differentiate between the static and generated content, the generated content is prefixed with a comment:
104+ ```
105+ % This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it.
106+ ```
107+
108+ ## Tutorials
109+
110+ ### Adding a new command
111+
112+ When adding a new command, for example adding the ` CHANGE_POINT ` command, do the following:
113+ 1 . Create a new file in the ` _snippets/commands/layout ` directory with the name of the command, for example ` change_point.md ` .
114+ 2 . Add the content for the command to the file. See other files in this directory for examples.
115+ 3 . Add the command to the list in ` _snippets/lists/processing-commands.md ` .
116+ 4 . Add an include directive to the ` commands/processing-commands.md ` file to include the new command.
117+ 5 . Add tested examples to the ` _snippets/commands/examples ` directory. See below for details.
118+
119+ ### Adding examples to commands
120+
121+ When adding tested examples to a command, for example adding an example to the ` CHANGE_POINT ` command, do the following:
122+ * Make sure you have an example in an appropriate csv-spec file in the ` x-pack/plugin/esql/qa/testFixtures/src/main/resources/ ` directory.
123+ * Make sure the example has a tag that is unique in that file, and matches the intent of the test, or the docs reason for including that test.
124+ * If you only want to show the query, and no results, then do not tag the results table,
125+ otherwise tag the results table with a tag that has the same name as the query tag, but with the suffix ` -result ` .
126+ * Create a file with the name of the tag in a subdirectory with the name of the csv-spec file
127+ in the ` _snippets/commands/examples ` directory. While you could add the content to that file, it is not necessary, merely that the file exists
128+ * Run the test ` CommandDocsTests ` in the ` x-pack/plugin/esql ` module to generate the content.
129+
130+ For example, we tag the following test in change_point.csv-spec:
131+
132+ ```
133+ example for docs
134+ required_capability: change_point
135+
136+ // tag::changePointForDocs[]
137+ ROW key=[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25]
138+ | MV_EXPAND key
139+ | EVAL value = CASE(key<13, 0, 42)
140+ | CHANGE_POINT value ON key
141+ | WHERE type IS NOT NULL
142+ // end::changePointForDocs[]
143+ ;
144+
145+ // tag::changePointForDocs-result[]
146+ key:integer | value:integer | type:keyword | pvalue:double
147+ 13 | 42 | step_change | 0.0
148+ // end::changePointForDocs-result[]
149+ ;
150+ ```
151+
152+ Then we create the file ` _snippets/commands/examples/change_point.csv-spec/changePointForDocs.md ` with the content:
153+ ```
154+ This should be overwritten
155+ ```
156+
157+ Then we run the test ` CommandDocsTests ` in the ` x-pack/plugin/esql ` module to generate the content.
158+
159+ Now the content of the changePointForDocs.md file should have been updated:
160+
161+ ```
162+ % This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it.
163+
164+ \```esql
165+ ROW key=[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25]
166+ | MV_EXPAND key
167+ | EVAL value = CASE(key<13, 0, 42)
168+ | CHANGE_POINT value ON key
169+ | WHERE type IS NOT NULL
170+ \```
171+
172+ | key:integer | value:integer | type:keyword | pvalue:double |
173+ | --- | --- | --- | --- |
174+ | 13 | 42 | step_change | 0.0 |
175+ ```
176+
177+ Finally include this file in the ` CHANGE_POINT ` command file ` _snippets/commands/layout/change_point.md ` :
178+
179+ ```
180+ **Examples**
181+
182+ The following example shows the detection of a step change:
183+
184+ :::{include} ../examples/change_point.csv-spec/changePointForDocs.md
185+ :::
186+ ```
0 commit comments