docker compose up --build
: bring up and attach to the compose servicesdocker compose down
: stop all of the running servicesdocker system prune --volumes -a
: remove all stopped containers and volmesdocker volume rm mongo-data
: clear the persistent data stored in mongoDbbun i && bun dev
: when ran under src/app/server + src/app/client you can run the GUI in development modedocker compose --profile gui up --build
: run the services and the webserver containerdocker compose --profile feeder up --build
: run the services and the online feeder which has host devicesruff check .
: lint all python filesruff check . --fix
: fix linting errorsruff format
: re-format all python files
- Clear Description: When opening an issue, the issue title should address the added feature, fix, or enhancement. If further detail is necessary, elaborate in the description to justify its necessity. Details in implementation should be described under the PR
- Iteration and Weight: Assign the issue to an appropriate iteration and give it an estimated weight, where each weight of 1 is equal to 4 hours of work.
- Labels: Apply relevant labels to categorize the issue correctly. Limit the number of tags to 3 excluding a priority. As an example, most PRs will have some Docker or gRPC element to them, but they shouldnt be labeled as such unless that is their only contribution.
- PR Title: PR titles should match exactly the name of its closing issue. In the case of a PR closing multiple issues, the name should capture its significant changes but will be upto the author.
- Issue Linking: Every PR must be linked to at least one issue. Please use the GitHub keywords (e.g., "Closes #issue_number") in your PR description to automatically link the PR to the relevant issue.
- Formatting: When editing .py files be sure to utilize
ruff check . --fix
to avoid linting errors. - JavaScript-Related Code: All JavaScript-related code must be reviewed by @CaseyBramlett.
- Other Code: All other code must be reviewed by @IsaiahHarvi.
- Responsibility: Threads in the PR should be resolved by the person who opened the thread, not the PR author.
- Testing: PRs should not be merged until all tests pass.