This removes the undocumented `META FUNCTIONS` command that emits
descriptions for all functions. This shouldn't be used because we never
told anyone about it. I'd have preferred if we'd have explicitly
documented it as no public or if we'd have left it snapshot-only. But
sometimes you make a mistake. I'm hopeful no one is relying on it. It
was never reliable and not public.....
This PR contains the following updates:
| Package | Update | Change | |---|---|---| |
docker.elastic.co/wolfi/chainguard-base | digest | `c16d3ad` ->
`90888b1` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once
you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
This commit adds support to transform the value of the value field in the close_to assertion.
For example, with the following configuration:
tasks.named("yamlRestCompatTestTransform").configure({ task ->
task.replaceValueInCloseTo("get.fields._routing", 9.5, "my test name")
})
will transform the following in "my test name" from:
close_to: { get.fields._routing: { value: 5.1, error: 0.00001 } }
to
close_to: { get.fields._routing: { value: 9.5, error: 0.00001 } }
This commit also adds supports to specify a specific test name to apply the replaceIsTrue task configuration.
Before this commit, you could replace the values in the is_true, but it only supported doing so for all tests subject to the configuration.
This commit bumps the REST API version from 8 to 9. This effectively removes all support for REST API
compatibility with version 7 (though earlier commits already chipped away at some v7 support).
This also enables REST API compatibility support for version 8, providing support for v8 compatibility headers,
i.e. "application/vnd.elasticsearch+json;compatible-with=8" and no-op support (no errors) to accept v9
compatibility headers i.e. "application/vnd.elasticsearch+json;compatible-with=9".
see additional context in the GH PR #113151
* Add more missing wolfi references to fix tests
* packaging tests require access to docker registry
* Fix symlink for es distributions jdk cacerts in wolfi docker
* Fix native support on wolfi images
* Fix provided keystore packaging tests for wolfi
* Add utils used for testing to wolfi image
* Explicitly set default shell to bash in docker images
* Fix docker config issues
* Apply review feedback around docker login
---------
Co-authored-by: Rene Groeschke <rene@elastic.co>
Regardless of JDK version, ES should always use CLDR locale database from 9.0.0.
This also removes IsoCalendarDataProvider used to override week-date calculations for the root locale only.
Extensible plugins use a custom classloader for other plugin jars. When
extensible plugins were first added, the transport client still existed,
and elasticsearch plugins did not exist in the transport client (at
least not the ones that create classloaders). Yet the transport client
still created a PluginsService. An indirection was used to avoid
creating separate classloaders when the transport client had created the
PluginsService.
The transport client was removed in 8.0, but the indirection still
exists. This commit removes that indirection layer.
Now that main has a minimum compile version of Java 21, native access no
longer needs JNA. This commit removes JNA as a dependency, and moves the
jdk implementation into the main source set. It also slightly adjusts
the Mrjar plugin so that the main source set also supports preview
features, like the other numbered source sets.
ZStandard was added via #103374 a few months ago to snapshot builds of Elasticsearch only and benchmark results have shown that using zstd is a better trade off compared to deflate for when index.codec is set to best_compression.
This change removes the feature flag for ZStandard stored field compression for indices with index.codec set to best_compression.
JDK 23 removes the COMPAT locale provider, leaving CLDR as the only option. This commit configures Elasticsearch
to use the CLDR provider when on JDK 23, but still use the existing COMPAT provider when on JDK 22 and below.
This causes some differences in locale behaviour; this also adapts various tests to still work whether run on COMPAT or CLDR.
Native libraries in Java are loaded by calling System.loadLibrary. This
method inspects paths in the java.library.path to find the requested
library. Elasticsearch previously used this to find libsystemd, but now
the only remaining use is to set the additional platform directory in
which Elasticsearch keeps its own native libraries.
One issue with setting java.library.path is that its not set for the cli
process, which makes loading the native library infrastructure from clis
difficult. This commit reworks how Elasticsearch native libraries are
found in order to avoid needing to set java.library.path. There are two
cases. The simplest is production, where the working directory is the
Elasticsearch installation directory, so the platform specific directory
can be constructed. The second case is for tests where we don't have an
installtion. We already pass in java.library.path there, so this change
renames the system property to be a test specific property that the new
loading infrastructure looks for.
We see gradle cache incompatibilities sneaking into our code base. Until
we can enable this feature by default we should regular run checks
existing configuration cache achievements are not degrading.
This change includes: - updating spotless gradle plugin to configuration
cache compatible version (its still BETA but imo good enough for our
needs)
Ocassionally we see a LISTING.TXT not included in the jar. The cause
seems a timing issue with sync task were target root folder is same
folder as folder containing listing.txt.
* Fallback to bundled jdk for runtime jdk instead of build jvm
* Rework bundled jdk resolution to be lazy
* Use fixed runtime jdk for gradle build integ tests
With this commit, if no key or SAS token is supplied for an Azure
repository then Elasticsearch will use the `DefaultAzureCredential`
chain defined in the Azure SDK, which will obtain credentials from the
instance metadata service when running on an Azure VM.
We do not implicitly rely on all different kind of env variables when leveraging Gradle Configuration Cache
this makes reusing config cache more reliable and improves cache hits
* configure default env variables for logged exec task
* Fix antfixturestop constructor
* Make LoggedExec cc compatible (fix integtests)
* Fix spotless
This commit relaxes the toolchain specification when runtime.java is set
to allow the adoptium toolchain resolver to match the jdk. Before this
only the oracle toolchain resolvers could match. It also removes LTS
releases from the archived oracle resolver since those are not EOL.
Since the bundled JDK is now Java 22, the archive resolver needs to
support resolving Java 21. This commit updates the resolver to know
which version of Java 21 to download.
This commit moves the file preallocation functionality into
NativeAccess. The code is basically the same. One small tweak is that
instead of breaking Java access boundaries in order to get an open file
handle, the new code uses posix open directly.
relates #104876
Ensures that the value provided by the `runtime.java` system property,
or `RUNTIME_JAVA_HOME` environment variable is respected, even when it
is the same as the current `JAVA_HOME`. The previous logic had
`isRuntimeJavaHomeSet` return `false` when the "requested" Java was the
same as the current one. This isn't strictly correct, as the behavior
when Java home is unset is to use the bundled JDK. The result was that
passing `-Druntime.java=17` when the Gradle daemon was also using Java
17 was to execute tests with the bundled JDK, which could be something
entirely different.
