Contributing

Please take note of the following sections if you're contributing to the Jolly Advisor.

Table of Contents

• Getting Started
• Git Workflow
• Guard and TDD
• Testing
• Other Notes

Getting Started

1. Clone: git clone https://github.com/hacsoc/the_jolly_advisor.git
2. New branch: git checkout -b my-branch
3. Install rvm: https://rvm.io
4. Switch to Ruby 2.3.0 rvm install 2.3.0
5. Install bundle: gem install bundler
6. Install postgres; setup postgres; create database. This is platform specific. Next:
7. su - postgres; createuser --interactive use your system username when it asks for role to add
8. createdb the_jolly_advisor_development
9. exit
10. cd /path/to/the_jolly_advisor
11. Install gems: bundle

• You may run in to problems with libv8 or therubyracer. To get around this, try doing the following:
  1. gem install libv8 -v [VERSION] -- --with-system-v8
  2. gem install therubyracer -v [VERSION] -- --with-system-v8
     • Also, this is apparently another option.
  3. Finally, bundle to get the rest of the gems.

1. Migrate db: rake db:migrate this might take a few minutes
2. Open rails console; get SIS data
3. rails c
4. require “sis_importer”
5. SISImporter.import_sis
6. Start local server: rails s
7. Server will be available at http://localhost:3000/

Git Workflow

1. Clone from git: git clone https://github.com/hacsoc/the_jolly_advisor.git
2. Do work on a separate branch: git checkout -b aaron-dev
3. Finish your work and merge in master: git fetch origin master; git merge master
4. Push your code to github: git push origin aaron-dev
5. Create pull request from Github UI
6. Wait to get a 👍 from another team member before merging

Guard and TDD

We have the guard gem installed to help you with your TDD-ness. It's so agile. It watches for file changes and then runs the corresponding tests. This way you know right away if you broke anything. For more info, see their GitHub.

When working on The Jolly Advisor, you should always have a terminal open running guard. It will probably save you headaches in the long run.

Testing

Test Data

We use FactoryGirl to generate data for testing. Factories are defined in spec/factories/.

Unit Tests

We use RSpec for our unit tests. They live the spec/ directory.

Feature Tests

We use cucumber for our feature tests. They live in features/.

To get cucumber up and running:
createdb the_jolly_advisor_test
rake db:test:prepare

Then run tests with
rake cucumber

Running the Tests

• rake: runs all specs and then all feature tests
• rake spec: runs all specs
  • rspec [files]: runs specific spec files. This is much faster than using rake.
• rake cucumber: runs all feature tests
  • cucumber [files]: runs specific feature files. Much faster than using rake.

Travis-CI

Travis CI will run tests when you submit a pull request, but if you're using TDD (see above), you can and should be running tests locally before submitting a pull request so you know your changes work.

Travis Config

This is actually important info. It took Steph and Andrew a long time to get this working.

config/database.yml.travis holds the database configuration for the test database that Travis uses. This is because we use a different username for our postgres db than Travis does.

The actual Travis configuration is in .travis.yml. Things to note:

• cache: bundler caches gem installs across builds, significantly reducing build times.
• before_script:
  • Copies over the travis db config to be used by the Travis CI server
  • Creates the postgres database
  • Runs the migrations
• FactoryGirl needs to be require: false in the Gemfile. See this post if you want to know why.

Should you ever need to change this, please refer to the Travis-CI Docs and make sure you understand the current setup before modifying.

Other Notes

• Use Github issues to note bugs and feature requests
• If opening an issue, use the appropriate labels to help us prioritize issues better.