Skip to content

uwblueprint/feeding-canadian-kids

Repository files navigation

Feeding Canadian Kids

Feeding Canadian Kids is the only Canadian federal registered charity working to fill the dinner-gap, providing healthy meals to hungry children for a good night’s sleep, nourished body and brighter future. The organization needs assistance to bring volunteers who navigate to their website to sign up for delivering food to schools. A formalized process is needed to make the experience smoother for the volunteers and increase sign ups. They also need one place to have the volunteers submit documents to be screened to ensure safety of the children.

Please see our Notion workspace for more information and technical details!

Stack

Backend Language: Python (with Flask)
Backend API: GraphQL
Database: MongoDB
Frontend Language: Typescript (with React)

Table of Contents


Getting Started

Prerequisites

Set up

  1. Clone this repository and cd into the project folder
git clone https://github.com/uwblueprint/feeding-canadian-kids.git
cd feeding-canadian-kids
  1. Create a .env file in the root of this repo, and in the frontend folder. (Ask the PL for the file contents)

  2. Run npm install in the root, and also run cd frontend && npm install

  3. Run the application

docker-compose up --build

The backend runs at http://localhost:5000 and the frontend runs at http://localhost:3000.

Test Users

Password For all test accounts: 12345678

Test ASP: Email: shahan.neda+asptest1@gmail.com

Test Donor: Email: shahan.neda+mealdonortest1@gmail.com

Test Admin: Email: shahan.neda+testadmin1@gmail.com

Useful Commands

Get Names & Statuses of Running Containers

docker ps

Linting & Formatting

Backend:

docker compose up backend # Run in a separate terminal first
docker exec -it fck_backend /bin/bash -c "black . && flake8 ." # Run in a separate terminal after the first command

Frontend:

# linting & formatting warnings only
docker compose up frontend # Run in a separate terminal first
docker exec -it fck_frontend /bin/bash -c "yarn lint" # Run in a separate terminal after the first command

# linting with fix & formatting
docker compose up frontend # Run in a separate terminal first
docker exec -it fck_frontend /bin/bash -c "yarn fix" # Run in a separate terminal after the first command

You can also use the Makefiles if you have make installed:

# lint backend
make belint
# OR
cd backend
make lint

# lint frontend
make felint
# OR
cd frontend
make lint

Running Tests

Backend:

docker compose up backend # Run in a separate terminal first
docker exec -it fck_backend /bin/bash -c "pip install -r requirements.txt && python -m pytest" # Run in a separate terminal after the first command

Frontend:

docker compose up frontend # Run in a separate terminal first
docker exec -it fck_frontend /bin/bash -c "yarn test" # Run in a separate terminal after the first command

You can also use the Makefiles if you have make installed:

# test backend
make betest
# OR
cd backend
make test

# test frontend
make fetest
# OR
cd frontend
make test

VSCode Python Test runner and debugger

Use VSCode's python test runner, which makes life MUCH Better.

    1. Make sure you have the docker extension, and the Dev Containers extension installed.
    1. Run docker compose up backend --build to start up backend container.
    1. Use the docker extension, right click on the backend container, and click Attach Visual Studio Code.
    1. Inside the container, make sure the Python Extension and the Python Debugger extension is installed.
    1. Click the tests tab. Use the buttons to run or debug tests.
    1. If you get a "Test not found" or similar error, the problem could be the wrong python binary is being used. In the bottom right, click on the python version, and try switching to different python binaries.

Version Control Guide

Branching

  • Branch off of main for all feature work and bug fixes, creating a "feature branch". Prefix the feature branch name with your GitHub username or usernames. The branch name should be in kebab case and it should be short and descriptive (e.g. jfdoming-a4bello/readme-update for two usernames jfdoming and a4bello).
  • To integrate changes on main into 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 main so the entire PR will appear as 1 commit on main, but the individual commits are preserved when viewing the PR.

1: From Git's own guidelines