Skip to content

Latest commit

 

History

History
205 lines (152 loc) · 7.51 KB

CONTRIBUTING.md

File metadata and controls

205 lines (152 loc) · 7.51 KB
Raw

Contributing

First, thank you for contributing!

We love pull requests from everyone. By participating in this project, you agree to abide by the thoughtbot code of conduct.

Here are a few technical guidelines to follow:

  1. Open an issue to discuss a new feature.
  2. Write tests.
  3. Make sure the entire test suite passes locally and on CI.
  4. Open a Pull Request.
  5. Squash your commits after receiving feedback.
  6. Party!

Configure Hound on Your Local Development Environment

  1. After cloning the repository, run the setup script

    ./bin/setup

    NOTE: If you don't need Hound to communicate with your local machine, you may skip steps 3-6. Designers, you don't need ngrok for the purpose of making css changes and running the app locally.

  2. Make sure that postgres, and redis, are both installed and running locally.

  3. Ngrok allows GitHub to make requests via webhook to start a build. Sign up for a free ngrok account and create a ~/.ngrok file with the following:

    auth_token: <your-token>

  4. Launch ngrok with a custom subdomain on port 5000.

    ngrok -subdomain=<your-initials>-hound 5000

  5. Set the HOST variable in your .env.local to your ngrok host, e.g. <your-initials>.ngrok.com.

  6. Change ENABLE_HTTPS to 'yes' in the .env.local file.

  7. Log into your GitHub account and go to your developer application settings.

  8. Under the Developer applications panel - Click on "Register new application" and fill in the details:

    • Application Name: Hound Development

    • Homepage URL: https://<your-initials>-hound.ngrok.com NOTE: If you did not set up ngrok, use http://localhost:5000

    • Authorization Callback URL: https://<your-initials>-hound.ngrok.com NOTE: If you did not set up ngrok, use http://localhost:5000

      NOTE: If you did not set up ngrok, skip to the last step.

  9. On the confirmation screen, copy the Client ID and Client Secret to GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET in the .env.local file.

  10. On the personal access token page, click "Generate new token" and fill in token details:

    • Token description: Hound Development
    • Select scopes: repo and user:email

  11. On the confirmation screen, copy the generated token to HOUND_GITHUB_TOKEN in the .env.local file. Also update HOUND_GITHUB_USERNAME to be your username.

  12. Run foreman start. Foreman will start the web server and the resque background job queue. NOTE: rails server will not load the appropriate environment variables and you'll get a "Missing secret_key_base for 'development' environment" error.

  13. Open https://<your-initials>-hound.ngrok.com in a browser.

Testing

  1. Set up your development environment as per above.
  2. Run rake to execute the full test suite.

To test Stripe payments on staging use this fake credit card number.

Card Number Expiration CVV
Visa 4242424242424242 Any future date Any 3 digits

Linters

To better understand the architecture of Hound, here is a list of the linters and services being used, and the default configuration for each linter.

  1. Ruby
  1. CoffeeScript
  1. JavaScript (JSHint)
  1. SCSS
  1. Haml
  1. Go
  1. Markdown (beta)
  1. Swift (beta)

Writing a Linter

Linters check code snippets for style violations. They operate by polling a Resque queue.

Linter jobs are created with the following arguments:

  • config - The configuration for the linter. This will be linter specific.
  • content - The source code to check for violations.
  • filename - The name of the source file for the code snippet. This should be passed through to the outbound queue.
  • commit_sha - The git commit SHA of the code snippet. This should be passed through to the outbound queue.
  • pull_request_number - The GitHub pull request number. This should be passed through to the outbound queue.
  • patch - The patch content from GitHub for the file being reviewed. This should be passed through to the outbound queue.

Once linting is complete, resulting violations should be posted to the outbound "CompletedFileReviewJob" queue:

  • violations - An array of violation objects. Each violation requires the following:
    • line - The line number where the violation occurred.
    • message - A message describing the violation. This will be the contents of the Pull Request comment.
  • filename - The name of the source file for the code snippet. This is provided by the inbound queue.
  • commit_sha - The git commit SHA of the code snippet. This is provided by the inbound queue.
  • pull_request_number - The GitHub pull request number. This is provided by the inbound queue.
  • patch - The patch content from GitHub for the file being reviewed. This is provided by the inbound queue.

If the given config is invalid, the invalid file should be posted to the outbound ReportInvalidConfigJob queue:

  • commit_sha - The git commit SHA of the code snippet. This is provided by the inbound queue.
  • linter_name - The name of the linter that received an invalid config file.
  • pull_request_number - The GitHub pull request number. This is provided by the inbound queue.

Contributor License Agreement

If you submit a Contribution to this application's source code, you hereby grant to thoughtbot, inc. a worldwide, royalty-free, exclusive, perpetual and irrevocable license, with the right to grant or transfer an unlimited number of non-exclusive licenses or sublicenses to third parties, under the Copyright covering the Contribution to use the Contribution by all means, including but not limited to:

  • to publish the Contribution,
  • to modify the Contribution, to prepare Derivative Works based upon or containing the Contribution and to combine the Contribution with other software code,
  • to reproduce the Contribution in original or modified form,
  • to distribute, to make the Contribution available to the public, display and publicly perform the Contribution in original or modified form.