-
Check out the git repository
-
git clone git@github.com:MuckRock/muckrock.git
-
Set up your virtual machine
-
Install Vagrant and VirtualBox
-
Run
vagrant up
(this will take a while) -
Run
vagrant ssh
to ssh into the virtual machine -
Set the secrets
-
cd muckrock
-
touch .settings.sh
-
The
.settings.sh
file should never be checked in to the repository. -
We will send you the (definitely) sensitive information in a (probably) secure manner.
-
Inside your VM, run
source ~/.bashrc
. -
Populate the database and sync the files from AWS inside the virtual machine (Run all commands inside the VM)
-
Restart the database to pick up correct permissions,
sudo service postgresql
-
Login to heroku toolbelt,
heroku login
-
Pull the database,
fab populate-db
-
Pull files from S3,
fab sync-aws
-
Build the search index
-
Install watson with
fab manage:installwatson
-
Build the search index with
fab manage:buildwatson
-
After this, the index should stay updated. If a new model is registered with watson, then build the index (step 2). This command should be run on any staging or production servers when pushing code that updates the registration.
You should have a fully populated MuckRock site running locally now. The code checked out from GitHub is synced between the virtual machine and your host machine, so you may edit the code using your favorite text editor locally while running the code from within the virtual machine.
- Run
npm run watch &
to start a background Webpack instance - Run
fab mail &
to start a background email server - Run
fab celery &
to start a background task queue - Run
fab runserver
to start a server instance - Navigate your web browser (from the host machine) to
localhost:8000
To add a dependency, list it in one of the two .in
files inside the pip
folder.
The dev-requirements.in
file is used for local libraries, like testing suites.
The requirements.in
file is used for production libraries—stuff that should run on Heroku.
When entering a dependency, make sure to append a comment explaining its purpose. This is hugely helpful when it comes to navigating dependency hell.
After entering your dependency in the .in
file, run fab pip-compile
to canonize your change.
- Test your code in one of two ways:
- Run
fab test
to run all the tests. - Run
fab test:muckrock.<app>
to test a particular application. - Run
fab test:muckrock,1
to reuse the database between tests, which saves a ton of time.
- Run
- Lint your Python by running
fab pylint
. - Lint your Javascript by running
npm run lint
.
The master
branch represents our product code. master
should only ever be updated by merges from the dev
branch, which tracks it. New features should be branched from dev
, then merged back into dev
once they are tested and linted. Any feature branch pushed to GitHub will be evaluated by Codeship. If the staging
branch is pushed, the staging server will be updated. If the master
branch is pushed, the production server will be updated.