Skip to content

Latest commit

 

History

History
129 lines (87 loc) · 4.28 KB

developer-setup.md

File metadata and controls

129 lines (87 loc) · 4.28 KB
Raw

Developer Setup

Application setup

To run the application locally, you will need to have the following local dependencies installed:

The recommended way to install language runtimes (ie Ruby and Node) is using the asdf version manager tool (documentation). asdf considers a file called .tool-versions in the repository root when deciding which version of each language to install or use.

# The first time
asdf plugin add ruby
asdf plugin add nodejs
asdf plugin add yarn

# To install (or update, following a change to .tool-versions)
asdf install

To install asdf, read the installation guide here.

Service dependencies setup

As for running service dependencies, you have 2 options:

  1. Metal
  2. Docker

Metal

Running the service dependencies requires you to have Redis and Postgres installed and running on your machine.

  • postgresql v14
  • redis v6

To install these dependencies, you can use a package manager like brew on MacOS or apt on Linux distros.

Docker

As an alternative, you can use containerized dependencies. This is useful to ensure that Redis and Postgres do not conflict with other projects on your machine.

You will need to have docker locally installed. You can follow the instructions here.

Running the service dependencies via Docker

A handy docker-compose.yml file has been included to simplify the process of running the dependencies. To use it, run the following command:

docker compose up

Initial setup

bin/setup will install local dependencies and set up your database with seed data.

bin/setup

Running the application

Now that you have the dependencies installed, you can run the application. The application is composed of 5 processes:

  • web - The main Rails application
  • worker - The background processing service
  • worker_secondary - The secondary background processing service that prioritizes BigQuery jobs
  • clock - The clock process that schedules recurring jobs
  • caddy - The reverse proxy server

You can run these processes independently or use bin/dev command to run them all at once.

bin/dev # Ensures foreman is installed and runs all processes defined in Procfile.dev

Local development

Creating and signing in to the candidate interfaces requires clicking a link sent via email using GOV.UK Notify.

In development mode, the contents of the emails sent is saved to a log file, which you can see by running:

tail -f log/mail.log

Signing in to the Provider interface requires a network connection and a user account on DfE Sign-in. In development you can eliminate this dependency by setting BYPASS_DFE_SIGN_IN=true in your .env file. This replaces the sign in flow with a dialog allowing you to specify a DfE Sign-in UID and Email address for your current session.

Provider permissions

We decide what to show providers based on their DfE Sign-in UID.

To grant a user permission to view a provider’s applications, visit /support/users/providers and create a user, specifying their DfE Sign-in UID and the relevant provider.

Support permissions

There is a support_users database table that lists all the DfE Sign-in accounts that have access to the Support interface based on their DfE Sign-in UID. There is only one privilege level, either you have access to everything or nothing.

You can add a new support user using the create_support_user rake task. You need to supply a DfE Sign-in UID and an email address, e.g.

bundle exec rails "create_support_user[alice, [email protected]]"

Note that only the UID is used for lookup. The email address serves only as a label.