uptasticsearch icon indicating copy to clipboard operation
uptasticsearch copied to clipboard

Reduce duplication of Elasticsearch versions in the project

Open jameslamb opened this issue 5 years ago • 0 comments

Currently, there are at least 4 places where the set of versions of Elasticsearch are hard-coded.

These include:

  • .travis.yml (2 identical sets of versions, kept in sync manually)
  • setup_local.sh
  • .ci/seed_es_on_travis.sh

To close this issue, propose a pull request which eliminates this duplication. Ideally, the set of versions that we test against should be specified in a SINGLE place, and then re-used by all of the different places that need it.

One idea:

  • create es_versions.json, a file with a JSON that holds a dictionary keyed by version, like this:
{
    "7.3.1": {
        "docker_image": "docker.elastic.co/elasticsearch/elasticsearch:7.3.1",
        "debian_package": "https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.3.1-amd64.deb"
    }
}
  • setup_local.sh reads this file to know the mapping from versions to containers
  • building the Python package involves copying that file into something like py-pkg/pkgdata/es_versions.json, including it with py-pkg/MANIFEST.in, and then using it to export a variable from package called TESTED_VERSIONS or in some other way tying releases to the versions they are known to work against
  • same idea as that with the R package
  • somehow generate the matrix of builds in .travis.yml programmatically

This issue may take multiple PRs

It's possible that it will take multiple PRs to address different sources of duplication. For example, someone who is better at Travis than me might be able to reduce the two identical copies of the "what versions we test against" list by using matrix in a clever way.

jameslamb avatar Sep 04 '19 05:09 jameslamb