Skip to content

Working On Intern

Jump to bottom
Jason Cheatham edited this page Jun 25, 2014 · 7 revisions

These are some basic guidelines for contributing to Intern. Welcome!

Setting up development environment

  1. git clone git@github.com:theintern/intern.git
  2. cd intern
  3. npm install
  4. cd node_modules/intern
  5. npm install dojo chai
  6. cd ../..

Switching between master and geezer

Because these two versions of Intern have slightly different dependencies, the easiest way to switch between the two is as follows:

The first time you switch to geezer:

  1. git checkout geezer
  2. mv node_modules/dojo node_modules/dojo-2
  3. npm install
  4. cd node_modules/intern-geezer
  5. npm install dojo
  6. cd ../..

Subsequent switch geezer → master:

  1. git checkout master
  2. mv node_modules/dojo node_modules/dojo-1
  3. mv node_modules/dojo-2 node_modules/dojo

Subsequent switch master → geezer:

  1. git checkout geezer
  2. mv node_modules/dojo node_modules/dojo-2
  3. mv node_modules/dojo-1 node_modules/dojo

etc.

(Hey, maybe you can write a script to automate this!)

Run the self-test before you pull request

You can run Intern’s self-test suite using the tests/selftest.sh script. This script uses the production version of Intern installed in node_modules to run the self-test suite using both the Node.js client and WebDriver runner. WebDriver tests are run on Sauce Labs, so you’ll need to provide your Sauce username and access key as environment variables:

SAUCE_USERNAME=… SAUCE_ACCESS_KEY=… ./tests/selftest.sh

Always run the self tests before issuing a pull request. Travis-CI will warn you later if you’ve done something dumb, but do you really want to broadcast that to the world?!!

Never merge to master when landing a PR

Whenever landing a PR, always use git pull https://github.com/cool-person/intern.git branch-name --squash --author="Original Author <foo@example.com>" instead of allowing a merge or fast-forward. NEVER allow a merge commit to be introduced to the master branch. ALWAYS make sure discrete features are committed in a single commit. Or else.

Always merge to geezer when landing a PR

Whenever merging a PR against the master branch, make sure you also commit it to the geezer branch, for as long as that thing exists.

  1. git commit
  2. git checkout geezer
  3. git merge master --no-commit
  4. Fix conflicts, if any
  5. Fix any getter/setters that need to be changed to use get/set methods
  6. git commit
Clone this wiki locally