Skip to content

Latest commit

 

History

History
180 lines (131 loc) · 6.28 KB

CONTRIBUTING.md

File metadata and controls

180 lines (131 loc) · 6.28 KB
Raw

Contribution Guidelines

From the Rubinius contribution page:

Writing code and participating should be fun, not an exercise in perseverance. Stringent commit polices, for whatever their other qualities may bring, also mean longer turnaround times.

Submit a patch and once it’s accepted, you’ll get commit access to the repository. Feel free to fork the repository and send a pull request, once it’s merged in you’ll get added. If not, feel free to bug qrush about it.

Also, if you’re hacking on RubyGems.org, hop in #rubygems on irc.freenode.net! Chances are someone else will be around to answer questions or bounce ideas off of.

How To Contribute

  • Follow the steps described in Development Setup
  • Create a topic branch: git checkout -b awesome_feature
  • Commit your changes
  • Keep up to date: git fetch && git rebase origin/master

Once you’re ready:

  • Fork the project on GitHub
  • Add your repository as a remote: git remote add your_remote your_repo
  • Push up your branch: git push your_remote awesome_feature
  • Create a Pull Request for the topic branch, asking for review.

Once it’s accepted:

  • If you want access to the core repository feel free to ask! Then you can change origin to point to the Read+Write URL:
git remote set-url origin git@github.com:rubygems/rubygems.org.git

Otherwise, you can continue to hack away in your own fork.

If you’re looking for things to hack on, please check GitHub Issues. If you’ve found bugs or have feature ideas don’t be afraid to pipe up and ask the mailing list or IRC channel (#rubygems on irc.freenode.net) about them.

Acceptance

Contributions WILL NOT be accepted without tests.

If you haven't tested before, start reading up in the test/ directory to see what's going on. If you've got good links regarding TDD or testing in general feel free to add them here!

Branching

For your own development, use the topic branches. Basically, cut each feature into its own branch and send pull requests based off those.

The master branch is the main production branch. Always should be fast-forwardable.

Development Setup

This page is for setting up Rubygems on a local development machine to contribute patches/fixes/awesome stuff. If you need to host your own gem server, please consider checking out Gemstash. It's designed to provide pass-through caching for RubyGems.org, as well as host private gems for your organization..

Environment (OS X)

  • Use Ruby 2.3.1
  • Use Rubygems 2.6.4
  • Install bundler: gem install bundler
  • Install Elastic Search: brew install elasticsearch
    • Setup information: brew info elasticsearch
  • Install PostgreSQL (>= 8.4.x): brew install postgres
    • Setup information: brew info postgresql
  • Install memcached: brew install memcached
    • Show all memcached options: memcached -h

Environment (Linux - Debian/Ubuntu)

Getting the code

  • Clone the repo: git clone git://github.com/rubygems/rubygems.org
  • Move into your cloned rubygems directory if you haven’t already: cd rubygems.org
  • Install dependencies: bundle install

Setting up the database

  • Get set up: ./script/setup
  • Run the database rake tasks if needed: bundle exec rake db:reset db:test:prepare --trace

Running tests

  • Start elastic search: elasticsearch
  • Start memcached: memcached
  • Run the tests: bundle exec rake

Running RuboCop

We use RuboCop to enforce a consistent coding style throughout the project. Please ensure any changes you make conform to our style standards or else the build will fail.

bundle exec rake rubocop

If you'd like RuboCop to attempt to automatically fix your style offenses, you can try running:

bundle exec rake rubocop:auto_correct

Importing gems into the database

  • Import gems into the database with Rake task. bundle exec rake gemcutter:import:process vendor/cache
    • To import a small set of gems you can point the import process to any gems cache directory, like a very small rvm gemset for instance, or specifying GEM_PATH/cache instead of vendor/cache.
  • If you need the index available - needed when working in conjunction with bundler-api - then run bundle exec rake gemcutter:index:update. This primes the filesystem gem index for local use.

Getting the test data

  • A good way to get some test data is to import from a local gem directory. gem env will tell you where rubygems stores your gems. Run bundle exec rake gemcutter:import:process #{INSTALLATION_DIRECTORY}/cache

  • If you see "Processing 0 gems" you’ve probably specified the wrong directory. The proper directory will be full of .gem files.

Getting the data dumps

  • You can use rubygems.org data dumps to test application in development environment especially for performance related issues.
  • To load the main database dump into Postgres, use psql - e.g. $ psql gemcutter_development < PostgreSQL.sql.

Pushing gems

  • In order to push a gem to your local installation use a command like the following:

    RUBYGEMS_HOST=http://localhost:3000 gem push hola-0.0.3.gem

When everything is set up, start the web server with rails server and browse to localhost:3000 or use Pow!

Database Layout

Courtesy of Rails ERD

Rubygems.org Domain Model