Version 2.0.0
Umeqo - a new faster and smarter way for recruiters to find potential student candidates.
virtualenv --no-site-packages UMEQO
.pip install -r requirements.txt
from the project root. You might get compilation errors. If you do, you're likely just missing some dev package. Google to find a fix.fab create_database
, followed by fab load_local_data
.python manage.py clear_prod_stripe_ids
. We don't want to use prod employer stripe ids locally and there is no way to keep them from getting committed atm.python manage.py runcserver
. You should get no errors.java -jar apache-solr-*/example/start.jar
from the project root.python manage.py runcserver
. You will use this to test whatever changes you make.git branch
and make sure you are on the dev branch. If there is no dev branch or you are not on it, run git checkout dev
.git add <files to add>
to stage the files you changed.git commit -m <commit message>
to commit your changes.git push origin dev
to push the changes to staging.fab staging update
locally to update staging.git checkout master
followed by git merge dev
to merge your changes to the master branch.git push origin master
to push your changes to master.fab prod update
locally to update prod.These are custom commands that can be run using python manage.py <command-name>
from the project root.
clear_stripe_test_customers
- clears all test mode customers from the Umeqo stripe account.
clear_prod_stripe_ids
- clears all employer Stripe customer ids that got committed from prod.
http://docs.fabfile.org/en/1.5/
restart
- restarts apache. Can be run on staging prod or demo. Needs to be called whenever python code is updated and is thus called by update
.
restart_all
- restarts nginx and apache. Can be run on raging prod or demo. Ty
migrate
- runs all available migrations for all apps. Is called by update
.
create_database
- deletes existing database, creates a new one, runs migrations, and loads in production data. Can only be called locally and on staging.
schemamigrate
- runs through all the apps and checks for schema changes. Creates migrations for any new ones.
We ideally want to set up something that monitors all the logs below and lets us know of any issues. Sentry only reports part of /var/www/umeqo/logs/umeqo.log
.
/var/log/umeqo_cron.log
- all cronjobs log to here.
/var/log/nginx/umeqo.access.log
- nginx logs all requests to here.
/var/log/nginx/error.log
- nginx logs all errors here.
/var/log/apache2/access.log
- apache logs all requests to here.
/var/log/apache2/error.log
- apache logs all errors to here.
/var/www/umeqo/logs/solr-reboots.log
- is incorrectly named (should just be solr.log). The solr process logs to here. If search queries are failing, this is the first place to check.
/var/www/umeqo/logs/umeqo.log
- everything that you see in sentry + more gets logged to here.