Lines in the code that should be removed before a release can be annotated with
//NORELEASE . This can be useful when debugging test failures. For example,
one might want to add additional logging that would be too verbose for production
and therfore should be removed before releasing.
closes#10141
Don't insist on log file removal until after usage is printed.
Some simple Python code improvements (x.find(y) != -1 --> y in x)
Make sure the git area is "clean" (has no unpushed changes, has pulled
all changes, has no untracked files)
Add label color detail when creating next github version label.
Closes#7913
Lucene will soon release official 4.10.1, but by upgrading sooner we can 1) sidestep the false failures due to the 1.8.0_20 JVM hotspot bug (has caused a number of false failures in recent Jenkins tests), 2) make sure none of the Lucene changes in 4.10.1 are problematic.
Closes#7844
This commit adds the ability to run bwc tests during the release
process to ensure the current release is backwards compatible with
the latest installed previous version. Installed means available
in the configured bwc test path.
Closes#6953
This commit adds checks for nocommit and tabs in the source code.
The task is executed during the validate phase and can be disabled via
`-Dvalidate.skip`
Revert "[BUILD] Promote artifacts from strings to their own type"
This reverts commit dcd4ba0654eb6780235718092969c2f9e6b38775.
This reverts commit 00d7eb3c0a6eefdb5947d07b18cf071ba538d696.
In our REST tests we already have support for features and skip sections that allow to skip tests if a feature is not supported.
We can then add a skip section based on the benchmark feature to the benchmark tests and execute them only when they are supported, knowing that they need at least a node with node.bench settings within the cluster. We can check that this requirement is met by calling the nodes info api.
This way we can dynamically decide whether to execute those tests or not and we don't need to have a node.bench around all the time. In fact, given that the REST tests use the GLOBAL cluster, we want to be able to randomize settings as much as possible and run tests against default settings as well. Also, this mechanism can be easily supported by the external cluster implementation that is used during the release process.
Introduced ability to disable benchmark nodes which is needed by BenchmarkNegativeTest.
ElasticsearchRestTests extends now ElasticsearchIntegrationTest and makes use of our ordinary test infrastructure, in particular all randomized aspects now come for free instead of having to maintain a separate (custom) tests runner
We previously parsed only the tests that needed to be run given the version of the cluster the tests are running against. This doesn't happen anymore as it didn't buy much and it would be harder to support as the tests get now parsed before the test cluster gets started. Thus all the tests are now parsed regardless of their skip sections, afterwards the ones that don't need to be run will be skipped through assume directives.
Fixed REST tests that rely on a specific number of shards as this change introduces also random number of shards and replicas (through randomIndexTemplate)
Closes#5654
Elasticsearch is release from release-branches but the modifications
to the documentation must be cherry-picked into the current development
branch. To make this easier this commit splits the commits of the
Version and the documenation into seperate commits.
this commit allows to run the release tool for smoke
testing without being on the actually released branch.
This commit also added a list of plugins that will be installed
for smoke testing to see if the plugin startup mechanism works
correctly.
the build_release.py tool now also downloads and verfyfies the
released packages from S3. It checks integrity based on the sha1
checksums and runs the smoketest against the specs in the current branch.
If RPM tools are not installed the release tool now fails with an
appropriate message. The tool now also fails if any of the required
artifacts is not present.
We use 'coming[x.y.z]' in our ref docs which needs to be updated
when doing a release to 'added[x.y.z]' This commit adds support
for replacing the references where applicable during preparing the release.
This tool builds a release and runs several checks to make sure the
release is in a reasonable shape (smoke test). From a top level
perspective it runs the following steps:
* clean the build environment `mvn clean`
* check if a Java 6 JDK is available
* run the tests with network and local
* generates the checksums for the binary packages
* uploads the binary packages to Amazon S3
* runs a 'mvn deploy' to publish the maven artifacts
The script will create an intermediate branch from a given 'release
branch' updates all versions based on the version we are currently
releasing. Updates the 'pom.xml' file as well as the 'Version.java'
class. Once this is done it commits the changes and rebase with the
branch we want to release from, merges the changes from the intermediate
branch and pushes to the given remote repository including the release
tag.
javanna
Britta Weber
Alexander Reelsen
Simon Willnauer
Ryan Ernst
Veres Lajos
Lee Hinman
Michael McCandless
Andrew Raines
David Pilato