-
Postgres DB - psql
-
In the
api
folder. -
Create a
.env.development
file with this content. It must match the config indocker-compose.db.yml
AUTH0_DOMAIN=https://dev-0tc6bn14.eu.auth0.com AUTH0_AUDIENCE=testing
-
Go back to the top level directory.
-
Set up the
dev
command, or usedocker compose -f docker-compose.development.yml
instead ofdev
in all instructions. -
Boot the api, web, and db services via
dev up
ordocker compose -f docker-compose.development.yml up
. This will run the boot pipeline and create the database, run migrations, and run seeds. -
Stop the api, web, and db services via
ctrl+c
ordev down
or if you want to wipe the databasedev down -v
.
-
Boot only the api service using:
dev up api # or docker compose -f docker-compose.development.yml up api
-
Access the api by logging in to the front-end, then going to http://localhost:3000
-
Boot only the web service using:
dev up web # or docker compose -f docker-compose.development.yml up web
-
Log in to the front-end service at http://localhost:8080
-
Boot only the db service using:
dev up db # or docker compose -f docker-compose.development.yml up db
Migrations run automatically, as do seeds. We need to change the seed format for production as it currently wipes the database during seeding.
-
You can access the
psql
command line viadev psql # or docker compose -f docker-compose.development.yml exec db psql "postgresql://app:itsallgood@localhost:5432/travel_development"
You can also run migrations and seeding manually after login in to the web UI by going to
- http://localhost:3000/migrate/latest
- http://localhost:3000/migrate/up
- http://localhost:3000/migrate/down
- http://localhost:3000/migrate/seed
You can also skip seeding if database is not empty by setting the SKIP_SEEDING_UNLESS_EMPTY=true
environment variable.
If you are getting a bunch of "Login required" errors in the console, make sure that you have disabled any kind of enhanced tracking protection.
Auth0 use third-party cookies for authentication, and they get blocked by all major browsers by default.
With dev
helper run: dev test api
or dev test web
.
- Run the api test suite via
dev test_api
.
See api/tests/README.md for more detailed info.
Run dev test_web
to run the front-end tests.
Currently can only test .js
files. .vue
files are not yet supported.
You can generate migrations via the api service code. Currently uses knex Migration CLI using dev knex ...
or cd api && npm run knex ...
.
dev knex migrate:make migration-name
This will generate a migration of the form:
api/src/db/migrations/20231013235256_migration-name.ts
Ideally the full name would be dash cased but that would require switching to umzug/Sequelize
.
dev knex migrate:latest
dev knex migrate:up
dev knex migrate:rollback
dev knex migrate:rollback --all
dev knex migrate:down
The dev
command vastly simplifies development using docker compose. It only requires ruby
; however, direnv
and asdf
will make it easier to use.
It's simply a wrapper around docker compose with the ability to quickly add custom helpers.
All commands are just strings joined together, so it's easy to add new commmands. dev
prints out each command that it runs, so that you can run the command manually to debug it, or just so you learn some docker compose syntax as you go.
-
(optional) Install
asdf
as seen in https://asdf-vm.com/guide/getting-started.html.e.g. for Linux
apt install curl git git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.12.0 echo ' # asdf . "$HOME/.asdf/asdf.sh" . "$HOME/.asdf/completions/asdf.bash" ' >> ~/.bashrc
-
Install
ruby
viaasdf
as seen here https://github.com/asdf-vm/asdf-ruby, or using whatever custom Ruby install method works for your platform.e.g. for Linux
asdf plugin add ruby https://github.com/asdf-vm/asdf-ruby.git # install version from .tool-versions file asdf install ruby asdf reshim ruby
You will now be able to run the
./bin/dev
command. -
(optional) Install direnv and create an
.envrc
with#!/usr/bin/env bash PATH_add bin
and then run
direnv allow
.You will now be able to do
dev xxx
instead ov./bin/dev xxx
.
- Create the appropriate database, as specified by the
DB_NAME
environment variable, and - Make sure the
public
schema exists in that database.
Files:
- Dockerfile
- docker-compose.yml
- Non-commited
.env
file
-
Create a
.env
file in top level directory with the appropriate values.DB_HOST="db" DB_PORT="5432" DB_USER="app" DB_PASS="itsallgood" DB_NAME="travel_production" AWS_LOGGING_ENABLED="true" AWS_LOGGING_GROUP="travel-authorization" AWS_LOGGING_STREAM="travel-auth-dev.ynet.gov.yk.ca" AWS_LOGGING_REGION="ca-central-1" AWS_LOGGING_ACCESS_ID="some-id" AWS_LOGGING_ACCESS_KEY="some-key"
- TODO: investigate if additional custom environment variables are needed
-
(optional) If testing build arguments do
docker compose build \ --build-arg RELEASE_TAG=2024.01.8.1 \ --build-arg GIT_COMMIT_HASH=532bd759c301ddc3352a1cee41ceac8061bfa3f7
or
docker compose build \ --build-arg RELEASE_TAG=$(date +%Y.%m.%d) \ --build-arg GIT_COMMIT_HASH=$(git rev-parse HEAD)
and then in the next step drop the
--build
flag. -
Build and boot the production image via
docker compose up --build
-
Go to http://localhost:3000/ and log in.
-
Navigate around the app and do some stuff and see if it works.