You can start the database easily within docker, using docker-compose:
docker-compose up mysql-als
To populate the database with tables and seeded valued, ensure that the correct database URI is in the default.json
file, or set the ALS_DATABASE_URI
accordingly, and run the following command:
npm run migrate
To run the API and/or Admin servers run the following commands
#NPM:
npm start
#CLI:
node src/index.js server
#NPM:
npm run start:api
#CLI:
node src/index.js server --api
#NPM:
npm run start:admin
#CLI:
node src/index.js server --admin
Running unit tests
npm run test:unit
npm run test:coverage-check
The integration tests use docker-compose
to spin up a test environment for running the integration tests.
The tests are executed inside a standalone account-lookup-service-int
container, defined in docker-compose.integration.yml
.
Run the tests in a standalone mode with:
npm run test:integration
By default, the test results will be available in /tmp/junit.xml
. See below to configure the output directory and file name of the test results.
In order to debug and fix broken integration tests, you may want to run the tests without tearing down the environment every time. To do this, you can set TEST_MODE
to wait
, which sets up the integration runner to start the docker containers, run the migrations, and then wait for you to log into the account-lookup-service-int
container and run the tests yourself.
Note: The docker-compose.integration.yml file mounts the
./src
and./test
directories inside the docker-container, so you can re-run your tests repeatedly without removing and rebuilding your containers each time.
For example:
export TEST_MODE=wait
npm run test:integration
# containers will now be ready and waiting for the tests
# log into the `account-lookup-service-int` container
docker exec -it als_account-lookup-service-int sh
# now run the integration tests
npm run test:int
You can then stop and remove the containers with the following commands:
docker-compose -f docker-compose.yml -f docker-compose.integration.yml stop
docker-compose -f docker-compose.yml -f docker-compose.integration.yml rm -f
Environment variable | Description | Example values | Default Value |
---|---|---|---|
TEST_MODE |
The mode that integration-runner.sh uses. See ./test/integration-runner.sh for more information. |
default , wait , rm |
default |
JEST_JUNIT_OUTPUT_DIR |
The output directory (inside the docker container) for the jest runner | /tmp , /opt/account-lookup-service/test/results |
/tmp |
JEST_JUNIT_OUTPUT_NAME |
The filename (inside the docker container) for the jest runner | junit.xml |
junit.xml |
RESULTS_DIR |
The output directory (on the host machine) that the test results is copied to | /tmp |
/tmp |
We use npm-audit-resolver
along with npm audit
to check dependencies for vulnerabilities, and keep track of resolved dependencies with an audit-resolve.json
file.
To start a new resolution process, run:
npm run audit:resolve
You can then check to see if the CI will pass based on the current dependencies with:
npm run audit:check
And commit the changed audit-resolve.json
to ensure that CircleCI will build correctly.
As part of our CI/CD process, we use anchore-cli to scan our built docker container for vulnerabilities upon release.
If you find your release builds are failing, refer to the container scanning in our shared Mojaloop CI config repo. There is a good chance you simply need to update the mojaloop-policy-generator.js
file and re-run the circleci workflow.
For more information on anchore and anchore-cli, refer to:
- For all put parties callbacks
FSPIOP-Destination
header is considered to be mandatory.