Sheldon

Sheldon is used to provide test feedback on styles/locales PRs. It assumes a few things about the environment it's ran in, most of which will automatically be set up correctly when ran on Travis (which is where it will usually run).

Environment variables for submitting the build details to Sheldon, to be ran on the styles/locales REPO

These will all be set by Travis automatically.

• TRAVIS_PULL_REQUEST is the number of the pull request/issue.
• TRAVIS_COMMIT_RANGE is the range of commits included in the PR.
• TRAVIS_REPO_SLUG is the repo being tested.
• TRAVIS_BUILD_ID is the internal Travis build ID. Not the same as the build number.

example .env for local testing:

TRAVIS_PULL_REQUEST=1
TRAVIS_COMMIT_RANGE=master
TRAVIS_REPO_SLUG=clone/styles
TRAVIS_BUILD_ID=1

Expected files in the repo being tested.

• spec/sheldon/travis.json (optional). Generated by rspec; when present, Sheldon will look for errors in this file. When errors are found, Sheldon will post build_failed.md.erb (see below) and quit.

Feedback templates

Sheldon includes templates for the messages to be posted on the github pull requests:

• templates/{locales,styles}/pull_request_opened.md.erb: the welcome message when a new PR is opened. Even though this is an ERB template, no variables are currently passed to it.
• templates/{locales,styles}/build_passed.md.erb: the message posted when tests pass. Gets variable build_url to link back to the Travis report. For styles, also gets the variable build_details, which contains a rendering of the modified/added styles.
• templates/{locales,styles}/build_failed.md.erb: the message posted when tests fail. Gets variable build_url to link back to the Travis report, and a variable build_details which is a summary of the errors.

Updating Sheldon

After making changes to Sheldon-gem,

• commit your changes
• run rake bump
• run git push
• run bundle update in the styles and locales repos

After making changes to Sheldon-bot,

• Make sure the heroku memcached add-on is activated
• Deploy to heroku