Repository files navigation

A volunteer management web application built forSistering.

Made withstarter-code-v2, brought to you by the UW Blueprint Internal Tools team!

• 👷Getting Started
  • ✔️Prerequisites
  • ⚙️Set up
• 🧰Useful Commands
  • ℹ️Get Names and Statuses of Running Containers
  • 💽Accessing PostgreSQL Database
  • ✨Linting and Formatting
  • 🧪Running Tests
• 🌳Version Control Guide
  • 🌿Branching
  • 🔒Commits

• Install Docker Desktop (MacOS |Windows (Home) |Windows (Pro, Enterprise, Education) |Linux) and ensure that it is running

# these commands should give error-free outputdocker infodocker-compose --version

• Ask a member of the Sistering dev team to be added to our Firebase project
• Set up Vault client for secret management, see instructionshere

1. Clone this repository andcd into the project folder

git clone https://github.com/uwblueprint/sistering.gitcd sistering

2. Pull secrets from Vault

vault kv get -format=json kv/sistering | python update_secret_files.py

3. Set a post-merge Git hook to automatically pull from Vault after every pull on origin'smain branch

./setup.sh"kv/sistering""main"

4. Run the application

docker-compose up --build

docker ps

# run a psql shell in the DB container (postgres is the default user)dockerexec -it<container-name> /bin/bash -c"psql -U postgres -d sistering"# in postgres shell, some common commands:# display all table names\dt# display user-defined types, including enums\dT+# quit\q# you can run any SQL query, don't forget the semicolon!SELECT* FROM<table-name>;

# linting & formatting warnings onlydockerexec -it<container-name> /bin/bash -c"yarn lint"# linting with fix & formattingdockerexec -it<container-name> /bin/bash -c"yarn fix"

dockerexec -it<container-name> /bin/bash -c"yarn test"

To create a new migration, change the schema.prisma file as requiredand runnpx prisma migrate dev --name <DESCRIPTIVE_NAME> --create-only

NOTE: You should be running this in the backend docker container cli, not locally. This is because the DB secrets will only be injected in that container

• Branch off ofmain for all feature work and bug fixes, creating a "feature branch". Prefix the feature branch name with your name. The branch name should be in kebab case and it should be short and descriptive. E.g.sherry/readme-update
• To integrate changes onmain into your feature branch,use rebase instead of merge

# currently working on feature branch, there are new commits on maingit pull origin main --rebase# if there are conflicts, resolve them and then:git add.git rebase --continue# force push to remote feature branchgit push -f

• Commits should be atomic (guideline: the commit is self-contained; a reviewer could make sense of it even if they viewed the commit diff in isolation)
• Trivial commits (e.g. fixing a typo in the previous commit, formatting changes) should be squashed or fixup'd into the last non-trivial commit

# last commit contained a typo, fixed nowgit add.git commit -m"Fix typo"# fixup into previous commit through interactive rebase# x in HEAD~x refers to the last x commits you want to viewgit rebase -i HEAD~2# text editor opens, follow instructions in there to fixup# force push to remote feature branchgit push -f

• Commit messages and PR names are descriptive and written inimperative tense¹. The first word should be capitalized. E.g. "Create user REST endpoints", not "Created user REST endpoints"
• PRs can contain multiple commits, they do not need to be squashed together before merging as long as each commit is atomic. Our repo is configured to only allow squash commits tomain so the entire PR will appear as 1 commit onmain, but the individual commits are preserved when viewing the PR.

1: From Git's ownguidelines