mirror of https://github.com/hwchase17/langchain synced 2024-11-08 07:10:35 +00:00

History

Jamal a2f191a322 Replace JIRA Arbitrary Code Execution vulnerability with finer grain API wrapper (#6992 ) This fixes #4833 and the critical vulnerability https://nvd.nist.gov/vuln/detail/CVE-2023-34540 Previously, the JIRA API Wrapper had a mode that simply pipelined user input into an `exec()` function. [The intended use of the 'other' mode is to cover any of Atlassian's API that don't have an existing interface](`cc33bde74f/langchain/tools/jira/prompt.py (L24)`) Fortunately all of the [Atlassian JIRA API methods are subfunctions of their `Jira` class](https://atlassian-python-api.readthedocs.io/jira.html), so this implementation calls these subfunctions directly. As well as passing a string representation of the function to call, the implementation flexibly allows for optionally passing args and/or keyword-args. These are given as part of the dictionary input. Example: ``` { "function": "update_issue_field", #function to execute "args": [ #list of ordered args similar to other examples in this JiraAPIWrapper "key", {"summary": "New summary"} ], "kwargs": {} #dict of key value keyword-args pairs } ``` the above is equivalent to `self.jira.update_issue_field("key", {"summary": "New summary"})` Alternate query schema designs are welcome to make querying easier without passing and evaluating arbitrary python code. I considered parsing (without evaluating) input python code and extracting the function, args, and kwargs from there and then pipelining them into the callable function via `f(args, *kwargs)` - but this seemed more direct. @vowelparrot @dev2049 --------- Co-authored-by: Jamal Rahman <jamal.rahman@builder.ai>		2023-07-05 15:56:01 -04:00
..
integration_tests	Replace JIRA Arbitrary Code Execution vulnerability with finer grain API wrapper (#6992 )	2023-07-05 15:56:01 -04:00
mock_servers	Add a mock server (#2443 )	2023-04-05 10:35:46 -07:00
unit_tests	Fixed Office365 tool __init__.py files, tests, and get_tools() function (#7046 )	2023-07-05 15:46:21 -04:00
__init__.py	initial commit	2022-10-24 14:51:15 -07:00
data.py	Add workflow for testing with all deps (#4410 )	2023-05-10 09:35:07 -04:00
README.md	feat: improve pinecone tests (#2806 )	2023-04-13 21:49:31 -07:00

README.md

Readme tests(draft)

Integrations Tests

Prepare

This repository contains functional tests for several search engines and databases. The tests aim to verify the correct behavior of the engines and databases according to their specifications and requirements.

To run some integration tests, such as tests located in tests/integration_tests/vectorstores/, you will need to install the following software:

Docker
Python 3.8.1 or later

We have optional group test_integration in the pyproject.toml file. This group should contain dependencies for the integration tests and can be installed using the command:

poetry install --with test_integration

Any new dependencies should be added by running:

# add package and install it after adding:
poetry add tiktoken@latest --group "test_integration" && poetry install --with test_integration

Before running any tests, you should start a specific Docker container that has all the necessary dependencies installed. For instance, we use the elasticsearch.yml container for test_elasticsearch.py:

cd tests/integration_tests/vectorstores/docker-compose
docker-compose -f elasticsearch.yml up

Prepare environment variables for local testing:

copy tests/.env.example to tests/.env
set variables in tests/.env file, e.g OPENAI_API_KEY

Additionally, it's important to note that some integration tests may require certain environment variables to be set, such as OPENAI_API_KEY. Be sure to set any required environment variables before running the tests to ensure they run correctly.

Recording HTTP interactions with pytest-vcr

Some of the integration tests in this repository involve making HTTP requests to external services. To prevent these requests from being made every time the tests are run, we use pytest-vcr to record and replay HTTP interactions.

When running tests in a CI/CD pipeline, you may not want to modify the existing cassettes. You can use the --vcr-record=none command-line option to disable recording new cassettes. Here's an example:

pytest --log-cli-level=10 tests/integration_tests/vectorstores/test_pinecone.py --vcr-record=none
pytest tests/integration_tests/vectorstores/test_elasticsearch.py --vcr-record=none

Run some tests with coverage:

pytest tests/integration_tests/vectorstores/test_elasticsearch.py --cov=langchain --cov-report=html
start "" htmlcov/index.html || open htmlcov/index.html