The following instructions were tested to work with the following software versions:

1. Vagrant 1.9.3
2. VirtualBox 5.0.32

1. Check out the git repository - git clone git@github.com:MuckRock/muckrock.git
2. Enter the directory - cd muckrock
3. Set up your virtual machine
   1. Install Vagrant and VirtualBox
   2. Run vagrant up (this will take a while)
      1. You will see the following error: ==> default: mesg: ttyname failed: Inappropriate ioctl for device. It can be safely ignored.
   3. Run vagrant ssh to ssh into the virtual machine
4. You may edit the file ~/muckrock/.settings.sh if you would like to set up accounts and passwords for any external providers - you should be able to develop without these unless you specifically need to use and test them

You should have a fully populated MuckRock site set up 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.

1. The following commands should be run from the MuckRock directory inside the virtual machine: cd muckrock
2. Run npm run build to rebuild the javascript and css
   • NOTE: This only needs to be run if you change any javascript or scss files, it will be built for you initially
3. Run fab mail to start a background email server (in order to log email sent during development)
4. Run fab celery to start a background task queue (in order to use celery during development)
5. Run fab runserver to start a server instance
6. Navigate your web browser (from the host machine) to localhost:8000
7. You may log in as a super user with the username super and password abc

The index should stay updated. If a new model is registered with watson, then build the index (fab manage:buildwatson). This command should be run on any staging or production servers when pushing code that updates the registration.

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.
• Lint your Python by running fab pylint.
• Lint your Javascript by running npm run lint.
• All code should be formatted by yapf and isort. You can format your code by running fab format. It may be helpful to set up your editor to autoformat your code upon saving.

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.