You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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:
es_versions.json
, a file with a JSON that holds a dictionary keyed by version, like this:setup_local.sh
reads this file to know the mapping from versions to containerspy-pkg/pkgdata/es_versions.json
, including it withpy-pkg/MANIFEST.in
, and then using it to export a variable from package calledTESTED_VERSIONS
or in some other way tying releases to the versions they are known to work against.travis.yml
programmaticallyThis 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.The text was updated successfully, but these errors were encountered: