This commit upgrades JNA to 5.10.0. The primary reason for this upgrade
is to adopt a newer version of `libffi` which supports the
`LIBFFI_TMPDIR` environment variable so that we can change the location
of temporary executables and resolve#77014.
This commit also switches to the upstream JNA releases rather than using
the specially-repackaged ones we've used in the past.
We have a few leftover mentions of `zen` discovery, mostly for
historical/BwC reasons, which this commit removes.
Prior to this commit the default value for `discovery.type` was `zen`
but this was not written down anywhere or officially supported: the two
options were to set it to `single-node` or to omit it entirely. This
commit changes the default to `multi-node` and documents this.
Co-authored-by: Adam Locke <adam.locke@elastic.co>
Going forward we will no longer maintain an `M.x` branch which is
intended to be the next minor version where `master` is always `M+1`.
This simplifies a lot of our logic to no longer care much about major
vs minor version.
In order to prevent cluster to be in yellow state when starting up only
one node - often when testing or trying things - autoexpand should be
set on that data stream
Also to making sure the deprecation log indexing is disabled on all
nodes in mixed-cluster and rolling upgrade
relates #78991
Our spotless configuration wasn't being applied to `build-tools`
and `build-tools-internal`. Move the Spotless configuration to a
Java plugin in `build-conventions`, and apply it everywhere.
This resulted in a lot more Java files being subject to formatting,
so I added more exclusions to the list.
Also remove the `paddedCell` stuff, we've never needed it.
Changing the default for deprecation log indexing to be true.
This commit also overrides this default to tests where a deprecation
data stream would interfere - because it uses index template, it would
not be possible to delete with _index_template/*.
The overrides should be removed when #78850 is done.
closes#76292
Allow passing FileCollection instead of single Jar files. This makes using the API way easier
as gradle configurations for resolving jars do not need to be resolved eagerly
By using a BuildService we can decouple the configuration of projects but keep making
expensive operations (e.g. parsing properties file or reading minimumJavaCompiler from file) only once
per build.
This bring us closer to decouple projects and get ultimatively configuration cache compliant. In
general we will bring in more BuildServices for the main build to follow along that Pattern and
ultimatevely remove usages of allprojects and subprojects in our build.
- Use file property and conventions to avoid afterEvaluate hook
- Simplify root build script
- One little step closer to configuration cache compliance
* Do not create unused testCluster
This avoids creating test clusters that are not required during the build.
We use lazy configuration here on testClusters and only instantiate them as theyre
* Do not fail on run task (debug)
* Create more test cluster lazy
* Make more test cluster lazy
* Avoid creating unused testcluster
* Fix PluginBuildPlugin
* Fix disabling geo db download
* Fix cluster setup in repository-multi-version
* Polishing
* Fix issue with irretic groovy ogic
* Fix bwc tests
* Fix more bwcTests
* Fix more bwc tests
* Fix more bwc tests
* Fix more bwc tests
* Fix typo
* Minor polishing
* Fix rolling upgrade tests
* Fix cluster config in sql qa mixedcluster project
* Fix more bwc tests
* Clean up before review
* Document test cluster usage
* Api polising after Review
provide useCluster(Provider) method to TestClusterAware
Ideally we take this a step further and realize those test clusters only on use.
But out of scope of this PR.
* Allow gradle provider as value for nonSystemProperties
* Some simplification on test configuration
* Fix typo in rest test config
* Fix more typos
* Fix another typo
* Fix more typos
This change makes it so x-pack-core and x-pack-security are bundled
in the INTEG TEST distribution that we use for testClusters in our
tests. There are two reasons for this:
- In https://github.com/elastic/elasticsearch/pull/77231 where we
are looking into enabling and auto-configuring security by default
for all nodes, we need to call out to ConfigInitialNode to
determine whether we should do the auto-configuration or not.
- Since we are enabling security by default, we should be looking
into enabling security for all for our tests moving forward, or
at least make a conscious decision about which ones run without
security. This change is a step towards that direction.
This introduces a basic public yaml rest test plugin that is supposed to be used by external
elasticsearch plugin authors. This is driven by #76215
- Rename yaml-rest-test to intern-yaml-rest-test
- Use public yaml plugin in example plugins
Co-authored-by: Mark Vieira <portugee@gmail.com>
Closes#74795.
Introduce two Docker image variants for Cloud. The first bundles
(actually installs) the S3, Azure and GCS repository plugins. The
second bundles all official plugins, but only installs the repository
plugins.
Both images also bundle Filebeat and Metricbeat.
The testing utils have been refactored to introduce a `docker`
sub-package. This allows the static `Docker.containerId` to be
shared without needing all the code in one big class. The code for
checking file ownership / permissions has also been refactored to
a more Hamcrest style, using a custom Docker file matcher.
The quota aware filesystem was added as a means of allowing
Elasticsearch to track the used space of the underlying filesystem in
virtualized environments. However, the need for it was due to a bug in a
much earlier version of Elasticsearch that always found the underlying
mount and checked it directely for usage. That bug has already been
fixed, so the there is no longer a need for this plugin. This commit
removes the plugin. We should consider separately whether there is still
a need for bootstrap plugins.
closes#70309
Part of #67335.
Add tasks for generating release notes, using information stored in files
in the repository:
* `generateReleaseNotes` - generates new release notes, release
highlights and breaking changes
* `validateChangelogs` - validates that all the changelog YAML files are
well-formed (confirm to schema, have required fields depending on the
`type` value)
I also changed `Version` to allow a `v` prefix in relaxed mode
* Fix task dependency wiring for multi node test clusters
for multi node test cluster configurations we accidentally miss calculating the proper
task dependencies in TestClusterAware. This moves the task dependency declaration
in TestClusterAware to use the live collection method nodes#all instead of nodes.forEach
which will also take nodes into account that are added later to the cluster _after_
this configuration block is triggered.
* Fix duplicate lines
- No manual show task dependencies logic needed. we can use build scans instead for that.
- Move common plugin configuration into according plugins
- Reduce overall callbacks in root script, remove unneeded logic in afterEvaluate hooks
After breaking up build logic between internal and external we can remove BuildParams.isInternal().
We also resolve bwc versions lazy and not eagerly. This makes configuration of non bwc builds easier and
also makes integration tests easier to setup.
- Fix new introduced deprecated usages
- Update to newer ospackage snapshot to include provided PR for fixing deprecated usage
This gradle release comes with improvements on incremental compilation which we should benefit from
The org.elasticsearch.bootstrap package exists in server with classes
for starting up Elasticsearch. The elasticsearch-core jar has a handful
of classes that were split out from there, namely java version parsing
and jarhell. This commit moves those classes to a new
org.elasticsearch.jdk package so as to not split the server owned
bootstrap package.
relates #73784
This moves the public build api and plugins into a separete included build called 'build-tools'
and we removed the duplication of included buildSrc twice (2nd import as build-tools).
The elasticsearch internal build logic is kept in build-tools-internal as included build which allows us better handling of this project that its just being an buildSrc project (e.g. we can reference tasks directly from the root build etc.)
Convention logic applied to both projects will live in a new build-conventions project.
