Skip to content

Reduce duplication of Elasticsearch versions in the project #168

@jameslamb

Description

@jameslamb

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

These include:

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions