You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Use a conventional struct instead of a Tuple struct
The Response struct contains a reqwest::Request and a Method fields, and
accessing them by position may be a bit confusing. Giving an actual name
to the fields brings us the benefit of easily understanding the methods
we are reading, without the need to go to the top to remember which
field we are referring to.
Reference: https://doc.rust-lang.org/1.9.0/book/structs.html#tuple-structs
* Expose `bytes` to the Response object
This patch exposes the `Response::bytes`, which is basically a wrapper
on reqwest::Response::bytes().
* Add additional note on vm.max_map_count settings
Closes#160
Cargo make is used to define and configure a set of tasks, and run them as a flow. This helps with performing actions
32
+
Cargo make is used to define and configure a set of tasks, and run them as a flow. This helps with performing actions
33
33
such as starting an Elasticsearch instance for integration tests
34
-
34
+
35
35
Cargo make can be installed with
36
-
36
+
37
37
```sh
38
38
cargo install --force cargo-make
39
39
```
40
-
40
+
41
+
42
+
If you are running the tests in Docker, [set `vm.max_map_count` for your platform](https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html#_set_vm_max_map_count_to_at_least_262144) to allow Elasticsearch to start.
43
+
41
44
### Cargo make
42
45
43
46
Cargo make is used to define and configure a set of tasks, and run them as a flow. To see all of the Elasticsearch
@@ -64,7 +67,7 @@ The `Elasticsearch` category of steps are specifically defined for this project
64
67
65
68
- Run Elasticsearch package tests
66
69
67
-
Optionally pass
70
+
Optionally pass
68
71
69
72
-`STACK_VERSION`: Elasticsearch version like `7.9.0` or can be
70
73
a snapshot release like `7.x-SNAPSHOT`
@@ -75,12 +78,12 @@ The `Elasticsearch` category of steps are specifically defined for this project
75
78
76
79
- Run YAML tests
77
80
78
-
Optionally pass
81
+
Optionally pass
79
82
80
83
-`STACK_VERSION`: Elasticsearch version like `7.9.0` or can be
81
84
a snapshot release like `7.x-SNAPSHOT`
82
85
-`TEST_SUITE`: Elasticsearch distribution of `free` or `platinum`
83
-
86
+
84
87
```sh
85
88
cargo make test-yaml --env STACK_VERSION=7.9.0 --env TEST_SUITE=free
86
89
```
@@ -96,9 +99,9 @@ the root client, `Elasticsearch`, or on one of the _namespaced clients_, such as
96
99
are based on the grouping of APIs within the [Elasticsearch](https://github.com/elastic/elasticsearch/tree/master/rest-api-spec) and [X-Pack](https://github.com/elastic/elasticsearch/tree/master/x-pack/plugin/src/test/resources/rest-api-spec/api) REST API specs from which much of the client is generated.
97
100
All API functions are `async` only, and can be `await`ed.
98
101
99
-
-#### `api_generator`
102
+
-#### `api_generator`
100
103
101
-
A small executable that downloads REST API specs from GitHub and generates much of the client package from the specs.
104
+
A small executable that downloads REST API specs from GitHub and generates much of the client package from the specs.
102
105
The minimum REST API spec version compatible with the generator is `v7.4.0`.
103
106
104
107
The `api_generator` package makes heavy use of the [`syn`](https://docs.rs/syn/1.0.5/syn/) and [`quote`](https://docs.rs/quote/1.0.2/quote/) crates to generate Rust code from the REST API specs.
@@ -110,11 +113,11 @@ can be `to_string()`'ed and written to disk, and this is used to create much of
110
113
111
114
A small executable that downloads YAML tests from GitHub and generates client tests from the YAML tests. The
112
115
version of YAML tests to download are determined from the commit hash of a running Elasticsearch instance.
113
-
116
+
114
117
The `yaml_test_runner` package can be run with `cargo make test-yaml` to run the generated client tests,
115
118
passing environment variables `TEST_SUITE` and `STACK_VERSION` to control the distribution and version,
116
119
respectively.
117
-
120
+
118
121
### Design principles
119
122
120
123
1. Generate as much of the client as feasible from the REST API specs
@@ -124,8 +127,8 @@ can be `to_string()`'ed and written to disk, and this is used to create much of
124
127
- accepted HTTP methods e.g. `GET`, `POST`
125
128
- the URL query string parameters
126
129
- whether the API accepts a body
127
-
128
-
2. Prefer generation methods that produce ASTs and token streams over strings.
130
+
131
+
2. Prefer generation methods that produce ASTs and token streams over strings.
129
132
The `quote` and `syn` crates help
130
133
131
134
3. Get it working, then refine/refactor
@@ -134,14 +137,14 @@ The `quote` and `syn` crates help
134
137
- Design of the API is conducive to ease of use
135
138
- Asynchronous only
136
139
- Control API invariants through arguments on API function. For example
0 commit comments