Visit our website on Student Tracking System
-
Install system packages, listed below
mysqlclient
MySQL client must be separately installed as a system package.
The mysqlclient Python package contains Python bindings to the MySQL client. Django depends upon this package, such that it can access MySQL. However, this package does not ship the actual MySQL client, merely the Python bindings to it. As such, the MySQL client must be separately installed as a system package. Installation information can be found at the pypi package listing.
On arch-linux, run
yay -S mysql
. With debian/Ubuntu,sudo apt install libmysqlclient-dev
will work. -
First, ensure you create and activate a Python virtual environment in this project's root:
python -m venv venv # create source ./venv/bin/activate # activate
activate scripts exist for various shells
-
All pip dependencies are listed in the
requirements.txt
file, and can be installed with:pip install -r requirements.txt
There are 2 database options: SQLite and MySQL. MySQL connects to the hosted, "real" database in AWS. SQLite makes a local file and uses that as the datastore for a local database instance.
The database is currently publically accessible, but has a subnet group with source IP address restrictions to it. If you would like direct connection to the database, contact Justen.
The current CI configuration uses the SQLite database. SQLite can be used by setting the environment variable USE_SQLITE to TRUE, and then starting the Django tests or server, as usual.
If you're unfamiliar with environment variables, an exported evironment variable in a shell session will persist for the extent of the shell session, but on a different shell session, you will have to export the variable, again.
Environment variable examples on MacOS & Linux:
export USE_SQLITE=TRUE # set to TRUE (use SQLite)
export USE_SQLITE=FALSE # set to FALSE (disable SQLite)
unset USE_SQLITE # unset (disable SQLite & remove var)
If this is the first invocation using the SQLite database, you first need to create the database schema. Do this with the following Django command, from the same directory as manage.py:
python manage.py migrate
A user is to upload many files to the program, both to configure the operation of the program, and to upload actual data. Sample data and config files are included in the data/
folder, which can be used for testing.
Data Files:
- studentData.txt
- courseData.txt
- transferData.txt
Configuration Files:
- rank-prerequisites.xlsx
- SWEProgram.xlsx
The configuration files must be uploaded prior to the data files. However, when
testing the program with python manage.py test ...
the local config files will
automatically loaded. Additionally, setting the environment variable
USE_LOCAL_CONFIGS=TRUE
will also cause the program to pre-load these config
files. This is useful when locally testing with python manage.py runserver ...
. Check manage.py
for details.
Now our repo has successfully deployed Django CI through Github Action!
- This will automatically run Django Test when you push or merge and return a result to tell you whether your project successfully ran this test.
- If you get a failed result, click the Action button to view the log.
- This branch is merged from the dev branch because this is the latest branch after sprint1.
- Branches that start with dev_ will automatically run CI when pushed to GitHub
For coding, please
- choose one dev branch from the lists
- create one new branch, like feature_Tom
- checkout to your branch and code
- commit and push to your branch
- merge your branch into the latest dev branch and delete your feature branch
- choose feature_xxxx just for checkouting from dev_**_ and _**delete*** it after merging
- choose dev_xxxx for merging your code with others and delete your feature branch after that. delete old dev if you all are working on new dev
After completing all development of a phase
- merge all dev branches into the main branch
- update the version number, like STS 1.0
- delete all feature branches
- write a document for this version