Table of Contents
Please read the Contributing guidelines before working on a pull request.
Note that new features and bug fixes should be performed from develop and on a new feature branch for the pull request to be manageable.
It is preferred that while developing, debug be set to True, by starting the application with python application.py -d True.
This will guarantee that any code changes will immediately refresh the application and cause it to start again with the new changes.
Pre-Releases are typically not built in a distributable format until the very end of the development cycle. For this reason, pre-release versions have to be built manually - with the UI and API working in separate directories.
Navigate to the root directory of the project...
npm installnpm starthttp://localhost:8080You still need to start the python server, but that is accomplished as normal:
pip install -r requirements.txtpython application.pyIn this case, using a development version, the API will be running on port 5000, and the UI will be accessible on port 8080.
To build the final distribution that will have the UI and API accessible from port 5000, run npm run-script build.
This will create an index.html that the Flask server will serve, under /elastichq/templates and static file bundles under /elastichq/static.
Once the distribution is built, you can start the server with python application.py and view the application at http://localhost:5000
The develop branch is automatically built on dockerhub. If you wish to test using this tag, which is latest unstable:
docker run -p 5000:5000 elastichq/elasticsearch-hq:develop
All tests run using docker containers for specific versions of ES. Running the entire suite will run against all containers, one at a time.
To run all tests across all ES major versions:
./run-tests.sh
To run tests for a specific major version of ES:
python manage.py run-tests --esv=<MAJOR_VERSION>
The code repo contains docker compose files for testing against different Elasticsearch versions.
You can run these individually and then use the applicaiton to test against it:
cd /tests/local/v2
docker-compose up
Or you can run them all at once and test against them:
cd /tests/local
./run_es_versions.sh
To bring the containers down:
./kill_es_versions.sh
In the event of errors to the effect of “container name in use”, list the containers and remove them. This will remove all stopped containers:
docker container ls
docker container prune
Sphinx requires specific libraries that are not in the default requirements.txt.
First install the sphinx requirements: pip install -r sphinx-requirements.txt
To generate the documentation:
./sphinx-build -b html /path/to/docs/source /path/to/docs
All response codes are included in the HTTP Status response header. There are method-specific responses to take note of:
201200200Standard header response below:
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, OPTIONS, GET, PUT, DELETE
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 3600
Allow: POST, GET, PUT, DELETE
Content-Length: 4320
Content-Type: application/json
Date: Wed, 31 Jan 2018 22:54:08 GMT
Server: Werkzeug/0.14.1 Python/3.5.0
Status: 200
X-HQ-Response-Time: 2570
Custom headers are pre-fixed with X-HQ.
Patches, bug reports, and feature requests are all welcome through the GitHub site. Contributions in the form of patches or pull requests are easier to integrate and will receive priority attention.