- nvm (optional)
- Node.js >= 14
- npm >= 7.5 (
npm i -g npm
to update) - Docker
- git lfs (
brew install git-lfs
)
docker-compose pull
(nvm use)
npm install
Pull down following repositories: hmpps-assess-risks-and-needs, community-api, hmpps-auth, and offender-assessments-api
Go into each folder of downloaded repo's and run following command in each:
docker buildx build --platform linux/arm64 --load --tag quay.io/hmpps/REPLACE-ME-WITH-REPO-NAME:latest .
You'll also need to add the following line to your /etc/hosts
file:
127.0.0.1 hmpps-auth
127.0.0.1 hmpps-manage-users
./bin/start-dependencies
npm run start:dev
Navigate to http://localhost:3000
and log in:
- To log in as a service provider user, use HMPPS Auth dev credentials e.g.
TEST_INTERVENTIONS_SP_1 / password123456
(and, this user has an email address of[email protected]
if you want to assign a referral to them) - To log in as a probation practitioner user, use Community API dev credentials e.g.
bernard.beaks/secret
.
If you need a service user’s CRN for making a referral in local development, you can use X320741
.
Sometimes you might find it useful to be able to view or change the data held in the local databases.
The interventions service comes already seeded with some referrals.
If you want to connect to the interventions service database, run
psql -h localhost -d interventions -U postgres
and enter a password of password
. From there you can for example execute \dt
to see all the tables, and run whatever SQL query you want.
To connect to the local HMPPS Auth database, visit http://localhost:8090/auth/h2-console and enter a JDBC URL of jdbc:h2:mem:authdb
, with empty username and password, then click Connect.
In local development mode, you might want to selectively mock out some calls to the interventions service. For example, for endpoints that have not yet been built.
You can do this by configuring mocks in mocks.ts
.
npm run test
npm run lint
The integration tests require a different docker-compose stack and a different application configuration. Run each of the following commands in its own shell.
docker-compose -f docker-compose-test.yml up
npm run start:test
npm run int-test(-ui)
Note: You may need to run npm run build
if you make none test code changes while the cypress tests are active
To create mp4 files from the integration tests run use command
npm run int-test-video
Which sets a CYPRESS_COMMAND_DELAY env variable that is used to slow down each test step. It also sets CYPRESS_NO_COMMAND_LOG so the cypress test steps are not displayed during the video.
This will create the files in integration_tests/videos
The development server and integration tests Node processes have the Node Inspector enabled, running on ports 9229 and 9330 respectively. You can use a debugger such as the one built into Chrome to set breakpoints etc. See the linked page for further details.
To view the existing static pages, and for more instructions about how to edit them, go to http://localhost:3000/static-pages
. If you get asked to log in when you try to go to this page, then you might need to re-enter this URL after logging in.
This file is automatically generated from the GOV.UK Frontend library. If you need to use a type or property which isn’t listed here (for example, after updating the version of the GOV.UK Frontend library), then re-generate this file by running npm run-script generate-frontend-types
and committing the updated file to version control.
Git Large File Storage replaces large files with text pointers inside Git, and stores the file contents on a remote server. Using it allows us to serve larger pdfs from GitHub (particularly the Structured Interventions download).
git-lfs may conflict with any local git hooks you may have configured, so if you encounter any issues committing files to the repository, you may need to tweak or temporarily disable your local git hooks.
See https://git-lfs.github.com/ for more information.
Any features or behaviour that isn't ready to be interacted with by users should be placed behind a config-based feature flag, configured in server/config.ts
, e.g. as below:
features: {
previouslyApprovedActionPlans: get('FEATURE_PREVIOUSLY_APPROVED_ACTION_PLANS', 'false') === 'true',
}
You can then set whether the feature should be enabled in the config for each environment in the respective helm_deploy/values-[ENVIRONMENT].yaml
file.
The project uses dotenv so if you create a .env
file in the project root you can setup all environment variables you need, including switching feature flags on or off. See the helm_deploy/values-[ENVIRONMENT].yaml
files for what env variables are currently set for each enviornment.
This file is listed in .gitignore
so your version won't get included in any changes you make.
Example .env
file
FEATURE_PREVIOUSLY_APPROVED_ACTION_PLANS=true
SP_PERCENTAGE_OF_DASHBOARD_PAGINATION_USERS=100
SP_MY_CASES_PAGE_SIZE=10
SP_OPEN_CASES_PAGE_SIZE=10
SP_UNASSIGNED_CASES_PAGE_SIZE=10
SP_COMPLETED_PAGE_SIZE=10
SP_CANCELLED_PAGE_SIZE=10
- hmpps-auth - for authentication
- redis - session store and token caching