To create the applicant questionnaire for the National Background Investigation System (NBIS), the project team is employing a user-centered design approach leveraging key principles from the U.S. Digital Services Playbook:
- Understand what people need
- Address the whole experience, from start to finish
- Make it simple and intuitive
Culper is a responsive, mobile-friendly web application that applicants can use to fill out an SF-86, SF-85, or SF-85P. It forms the foundation of eApp, which is part of a larger NBIS information technology system.
The project team primarily utilizes a private NBIS tool to administer user stories, defects, and tasks. Users of this open source code however are welcome to report issues via GitHub. Higher-level and non-development tasks are tracked in a Trello board.
Documentation for this software is maintained under docs and in a private wiki.
For more information on licenses and third-party source code, use a tool like this one.
Clone the repository and cd into it:
git clone https://github.com/18F/culper
cd culperThen to develop locally, create a .env file:
cp .env.example .envFor more information on the various settings, examples, and values please refer to the configuration documentation.
To do the initial setup and ensure that all tests pass locally:
makecd api
make reset-test-dbThere are some pre commit hooks added using husky to run them. The pre-commit hooks are designed to run outside of docker for speed so you will need to have run yarn install outside the containers if you have not done so.
The hooks should automatically be applied once yarn install is complete, and will run the eslint and css lint rules on files changed that are staged for commit. Developers should apply lint fixes; however, specifiying --no-verify as an argument to git commit to bypass this check for temporary wip commits.
The eslint rules for the pre-commit hook will be using a stricter standard than the CI build to allow us to improve the code as we modify files while avoiding having to fix all the errors that would be generated if the rules were applied to the whole project immediately. Eventually we will want to apply the stricter rules to the CI build as well.
To run a local server, we are using docker containers leveraging the docker-compose tool via the command:
make runThen direct your browser at http://localhost:8080. The access the site in development use the username test01 and password password01. If you make changes to frontend files, the site will automatically rebuild after ~10 seconds.
The Make target calls Docker Compose, which then runs containers for various parts of the system. Frontend assets are built from their own containers into the dist/ folder, which are then served by nginx. There is also an API backend (under api/) written in Go, which has a PostgreSQL database behind it. See the architecture diagram below.
See also: frontend docs.
There are several possible architectures which may be implemented. The diagram references one of those possible solutions and highlights the basic flow of data within the system. It also demonstrates integration with external systems (e.g. identity services) which are not part of this project but may be part of the overall system.
See advanced docs for more.
See tools docs for more.
Supported files are formatted using Prettier, though note this should only be done when a file is new or heavily modified. You should install Prettier for whatever editor you use.
- Vim users: install
syntastic - Emacs users: install
flycheck
For command-line alternatives there are the following:
- For CSS, run
make lint-css - For JavaScript, run
make lint-js - For HTML, html-lint which may be installed with
yarn add html-lint
Please refer to the contributing documentation.