Skip to content

Commit d3204bc

Browse files
committed
Increment global.json version for release + Regenerate documentation
1 parent b736d13 commit d3204bc

23 files changed

+80
-5
lines changed

.paket/Paket.Restore.targets

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -114,9 +114,11 @@
114114
<PaketReferencesFileLinesInfo Include="@(PaketReferencesFileLines)" >
115115
<PackageName>$([System.String]::Copy('%(PaketReferencesFileLines.Identity)').Split(',')[0])</PackageName>
116116
<PackageVersion>$([System.String]::Copy('%(PaketReferencesFileLines.Identity)').Split(',')[1])</PackageVersion>
117+
<AllPrivateAssets>$([System.String]::Copy('%(PaketReferencesFileLines.Identity)').Split(',')[4])</AllPrivateAssets>
117118
</PaketReferencesFileLinesInfo>
118119
<PackageReference Include="%(PaketReferencesFileLinesInfo.PackageName)">
119120
<Version>%(PaketReferencesFileLinesInfo.PackageVersion)</Version>
121+
<PrivateAssets Condition="%(PaketReferencesFileLinesInfo.AllPrivateAssets) == 'true'">All</PrivateAssets>
120122
</PackageReference>
121123
</ItemGroup>
122124

docs/aggregations/writing-aggregations.asciidoc

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -228,6 +228,7 @@ return s => s
228228
);
229229
----
230230
<1> a list of aggregation functions to apply
231+
231232
<2> Using LINQ's `Aggregate()` function to accumulate/apply all of the aggregation functions
232233

233234
[[handling-aggregate-response]]
@@ -259,5 +260,6 @@ var maxPerChild = childAggregation.Max("max_per_child");
259260
maxPerChild.Should().NotBeNull(); <2>
260261
----
261262
<1> Do something with the average per child. Here we just assert it's not null
263+
262264
<2> Do something with the max per child. Here we just assert it's not null
263265

docs/analysis/token-filters/token-filter-usage.asciidoc

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -183,7 +183,7 @@ InitializerExample
183183
"ngram": {
184184
"type": "ngram",
185185
"min_gram": 3,
186-
"max_gram": 30
186+
"max_gram": 4
187187
},
188188
"pc": {
189189
"type": "pattern_capture",
@@ -207,7 +207,7 @@ InitializerExample
207207
"shing": {
208208
"type": "shingle",
209209
"min_shingle_size": 8,
210-
"max_shingle_size": 12,
210+
"max_shingle_size": 10,
211211
"output_unigrams": true,
212212
"output_unigrams_if_no_shingles": true,
213213
"token_separator": "|",

docs/client-concepts/certificates/working-with-certificates.asciidoc

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -150,8 +150,11 @@ public class PkiCluster : CertgenCaCluster
150150
}
151151
----
152152
<1> Set the client certificate on `ConnectionSettings`
153+
153154
<2> The path to the `.cer` file
155+
154156
<3> The path to the `.key` file
157+
155158
<4> The password for the private key
156159

157160
Or per request on `RequestConfiguration` which will take precedence over the ones defined on `ConnectionConfiguration`

docs/client-concepts/connection-pooling/exceptions/unexpected-exceptions.asciidoc

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -58,8 +58,11 @@ audit = await audit.TraceUnexpectedException(
5858
);
5959
----
6060
<1> set up a cluster with 10 nodes
61+
6162
<2> where node 2 on port 9201 always throws an exception
63+
6264
<3> The first call to 9200 returns a healthy response
65+
6366
<4> ...but the second call, to 9201, returns a bad response
6467

6568
Sometimes, an unexpected exception happens further down in the pipeline. In this scenario, we
@@ -98,7 +101,9 @@ audit = await audit.TraceUnexpectedException(
98101
);
99102
----
100103
<1> calls on 9200 set up to throw a `WebException`
104+
101105
<2> calls on 9201 set up to throw an `Exception`
106+
102107
<3> Assert that the audit trail for the client call includes the bad response from 9200 and 9201
103108

104109
An unexpected hard exception on ping and sniff is something we *do* try to recover from and failover to retrying on the next node.
@@ -143,6 +148,8 @@ audit = await audit.TraceUnexpectedException(
143148
);
144149
----
145150
<1> `InnerException` is the exception that brought the request down
151+
146152
<2> The hard exception that happened on ping is still available though
153+
147154
<3> An exception can be hard to relate back to a point in time, so the exception is also available on the audit trail
148155

docs/client-concepts/connection-pooling/exceptions/unrecoverable-exceptions.asciidoc

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -81,6 +81,7 @@ var audit = new Auditor(() => Framework.Cluster
8181
);
8282
----
8383
<1> Always succeed on ping
84+
8485
<2> ...but always fail on calls with a 401 Bad Authentication response
8586

8687
Now, let's make a client call. We'll see that the first audit event is a successful ping
@@ -101,7 +102,9 @@ audit = await audit.TraceElasticsearchException(
101102
);
102103
----
103104
<1> First call results in a successful ping
105+
104106
<2> Second call results in a bad response
107+
105108
<3> The reason for the bad response is Bad Authentication
106109

107110
When a bad authentication response occurs, the client attempts to deserialize the response body returned;
@@ -135,6 +138,7 @@ audit = await audit.TraceElasticsearchException(
135138
);
136139
----
137140
<1> Always return a 401 bad response with a HTML response on client calls
141+
138142
<2> Assert that the response body bytes are null
139143

140144
Now in this example, by turning on `DisableDirectStreaming()` on `ConnectionSettings`, we see the same behaviour exhibited
@@ -169,5 +173,6 @@ audit = await audit.TraceElasticsearchException(
169173
);
170174
----
171175
<1> Response bytes are set on the response
176+
172177
<2> Assert that the response contains `"nginx/"`
173178

docs/client-concepts/connection-pooling/request-overrides/disable-sniff-ping-per-request.asciidoc

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -65,8 +65,11 @@ audit = await audit.TraceCalls(
6565
);
6666
----
6767
<1> disable sniffing
68+
6869
<2> first call is a successful ping
70+
6971
<3> sniff on startup call happens here, on the second call
72+
7073
<4> No sniff on startup again
7174

7275
Now, let's disable pinging on the request
@@ -90,6 +93,7 @@ audit = await audit.TraceCall(
9093
);
9194
----
9295
<1> disable ping
96+
9397
<2> No ping after sniffing
9498

9599
Finally, let's demonstrate disabling both sniff and ping on the request
@@ -111,5 +115,6 @@ audit = await audit.TraceCall(
111115
);
112116
----
113117
<1> diable ping and sniff
118+
114119
<2> no ping or sniff before the call
115120

docs/client-concepts/connection-pooling/round-robin/skip-dead-nodes.asciidoc

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -140,7 +140,9 @@ await audit.TraceCalls(
140140
);
141141
----
142142
<1> The first call goes to 9200 which succeeds
143+
143144
<2> The 2nd call does a ping on 9201 because its used for the first time. It fails so we wrap over to node 9202
145+
144146
<3> The next call goes to 9203 which fails so we should wrap over
145147

146148
A cluster with 2 nodes where the second node fails on ping
@@ -190,5 +192,6 @@ await audit.TraceCalls(
190192
);
191193
----
192194
<1> All the calls fail
195+
193196
<2> After all our registered nodes are marked dead we want to sample a single dead node each time to quickly see if the cluster is back up. We do not want to retry all 4 nodes
194197

docs/client-concepts/connection-pooling/sniffing/role-detection.asciidoc

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -138,6 +138,7 @@ var audit = new Auditor(() => Framework.Cluster
138138
};
139139
----
140140
<1> Before the sniff, assert we only see three master only nodes
141+
141142
<2> After the sniff, assert we now know about the existence of 20 nodes.
142143

143144
After the sniff has happened on 9200 before the first API call, assert that the subsequent API
@@ -218,7 +219,9 @@ var audit = new Auditor(() => Framework.Cluster
218219
};
219220
----
220221
<1> for testing simplicity, disable pings
222+
221223
<2> We only want to execute API calls to nodes in rack_one
224+
222225
<3> After sniffing on startup, assert that the pool of nodes that the client will execute API calls against only contains the three nodes that are in `rack_one`
223226

224227
With the cluster set up, assert that the sniff happens on 9200 before the first API call
@@ -295,6 +298,8 @@ await audit.TraceUnexpectedElasticsearchException(new ClientCall
295298
});
296299
----
297300
<1> The audit trail indicates a sniff for the very first time on startup
301+
298302
<2> The sniff succeeds because the node predicate is ignored when sniffing
303+
299304
<3> when trying to do an actual API call however, the predicate prevents any nodes from being attempted
300305

docs/client-concepts/high-level/analysis/writing-analyzers.asciidoc

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -103,6 +103,7 @@ var createIndexResponse = client.CreateIndex("my-index", c => c
103103
);
104104
----
105105
<1> Pre-defined list of English stopwords within Elasticsearch
106+
106107
<2> Use the `standard_english` analyzer configured
107108

108109
[source,javascript]
@@ -268,6 +269,7 @@ var createIndexResponse = client.CreateIndex("questions", c => c
268269
);
269270
----
270271
<1> Use an analyzer at index time that strips HTML tags
272+
271273
<2> Use an analyzer at search time that does not strip HTML tags
272274

273275
With this in place, the text of a question body will be analyzed with the `index_question` analyzer

0 commit comments

Comments
 (0)