Sistering
A volunteer management web application built for Sistering.
Made with starter-code-v2, brought to you by the UW Blueprint Internal Tools team!
Table of Contents
Getting Started
Prerequisites
- Install Docker Desktop (MacOS | Windows (Home) | Windows (Pro, Enterprise, Education) | Linux) and ensure that it is running
# these commands should give error-free output
docker info
docker-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 instructions here
Set up
- Clone this repository and
cdinto the project folder
git clone https://github.com/uwblueprint/sistering.git
cd sistering
- Pull secrets from Vault
vault kv get -format=json kv/sistering | python update_secret_files.py
- Set a post-merge Git hook to automatically pull from Vault after every pull on origin's
mainbranch
./setup.sh "kv/sistering" "main"
- Run the application
docker-compose up --build
Useful Commands
Get Names and Statuses of Running Containers
docker ps
Accessing PostgreSQL Database
# run a psql shell in the DB container (postgres is the default user)
docker exec -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 and Formatting
# linting & formatting warnings only
docker exec -it <container-name> /bin/bash -c "yarn lint"
# linting with fix & formatting
docker exec -it <container-name> /bin/bash -c "yarn fix"
Running Tests
docker exec -it <container-name> /bin/bash -c "yarn test"
Version Control Guide
Branching
- Branch off of
mainfor 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 on
maininto your feature branch, use rebase instead of merge
# currently working on feature branch, there are new commits on main
git pull origin main --rebase
# if there are conflicts, resolve them and then:
git add .
git rebase --continue
# force push to remote feature branch
git push -f
Commits
- 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 now
git 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 view
git rebase -i HEAD~2
# text editor opens, follow instructions in there to fixup
# force push to remote feature branch
git push -f
- Commit messages and PR names are descriptive and written in imperative tense1. 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 to
mainso the entire PR will appear as 1 commit onmain, but the individual commits are preserved when viewing the PR.
1: From Git's own guidelines
4 May 3, 2022
14 Jan 3, 2023
27 Dec 21, 2022
4 Jan 2, 2023
2 Dec 25, 2021
7 Dec 16, 2022
7 Sep 21, 2022
7 Nov 5, 2022
7 Dec 18, 2022
20 Dec 29, 2022
8 Sep 28, 2022
7 Aug 5, 2022
2 Apr 6, 2022
7 Jul 17, 2022
9 Jun 23, 2022
3 Jun 28, 2022
7 Nov 2, 2022
4 Oct 31, 2022
6 Oct 4, 2022