usaspending-api
usaspending-api copied to clipboard
Updating README and local config
Description:
Update the README and other aspects of the usaspending-api
codebase to support local development.
Technical details: Below is a brief list of changes going file by file in order to give a high-level reasoning of "why".
-
.env.template
- The wrong database name was used for the Broker DB
-
.gitignore
- Support change of the
docker-compose.yaml
to use more relative paths
- Support change of the
-
Dockerfile
- The
es_configure
job relies oncurl
to query the ES indexes - Without
curl
theelasticsearch_indexer
job fails to create the templates for the ES indexes and thus creates many mis-typed fields on the indexes
- The
-
Dockerfile.spark
- Similar changes that were made to the
Dockerfile
to change the base image used - Also had to update the version of OpenJDK
- Some new installs were needed to support the different image
- Old installs were left in place to avoid breaking things
- Similar changes that were made to the
-
Dockerfile.testing
- Update to the OpenJDK version similar to
Dockerfile.spark
- Remove the logic that change the working directory as it interfered with hot reload
- Update to the OpenJDK version similar to
- Makefile
- Update references of
docker-compose
to instead usedocker compose
(read more here) - Some paths updated to relative paths
- Update references of
-
README.md
- Some cleanup
- Made changes to reflect the steps that I took when setting everything up
-
docker-compose.yaml
- Removed the
version
as that is deprecated - Updated to use relative paths; main reasoning here is to avoid use of parameters such as
$PWD
in windows and also more WSL friendly - Updated the
usaspending-test
volume to be/usaspending-api
in the container to support hot reload when testing
- Removed the
-
usaspending_api/search/tests/integration/test_spending_by_category_categories.py
- This test never mocked the ES Transaction index; as a result if you tried to run this locally and you had data on your ES index it would fail because it would retrieve data
- Would be good to update the test cases to return actual data instead of a count of zero, but that is out of the scope of this PR
Requirements for PR merge:
- [x] Unit & integration tests updated
- [x] API documentation updated
- [x] Necessary PR reviewers:
- [x] Backend
- [x] Matview impact assessment completed
- [x] Frontend impact assessment completed
- [x] Data validation completed
- N/A Appropriate Operations ticket(s) created
- N/A Jira Ticket
Area for explaining above N/A when needed: