No more excuses 😉 here's an extremely short guide to get you started today!
First, if you haven’t forked the Rails project yet, then go to https://github.com/rails/rails and do it now.
If you’ve already worked with Rails, then there are only three new dependencies to install:
brew cask install virtualbox brew cask install vagrant vagrant plugin install vagrant-vbguest
We'll also use the rails-dev-box, a virtual machine for Ruby on Rails core development. This project automates the setup of a development environment for working on Ruby on Rails itself. We'll use the virtual machine to create a local environment with everything we need to start hacking and run the test suites.
git clone https://github.com/rails/rails-dev-box.git cd rails-dev-box git clone email@example.com:YOUR_USERNAME/rails.git # your fork git checkout -b YOUR_NEW_BRANCH # your new feature or bug fix vagrant up # this will take a long long time cd rails code . # or whatever editor of your choice
Now you can explore the code, make your changes, and write tests. But in order to run the tests, you'll need a little extra step.
Since you've already launched your virtual machine with the
vagrant up command, all you need now is to ssh into it:
cd rails-dev-box vagrant ssh # vagrant mounts that directory as /vagrant within the virtual machine vagrant@rails-dev-box:~$ cd /vagrant/rails vagrant@rails-dev-box:/vagrant/rails$ bundle
Finally, to start running your tests, you can:
# run all the tests $ cd rails $ bundle exec rake test # will take a long long time... # or run a particular component $ cd actionmailer $ bundle exec rake test # or run a specific file $ cd actionview $ bundle exec ruby -w -Itest test/template/form_helper_test.rb # or run a single test $ cd actionmailer $ bundle exec ruby -w -Itest test/mail_layout_test.rb -n test_explicit_class_layout
Once everything is ready, you can commit and push to your forked GitHub repo and open a pull request.
The code review might be the longest part. Depending on how busy the core team is, they can take some time to reply, but be patient. The most important part comes from you. Think about what context you could provide in order for them to quickly understand the issue. Do you have an example? How about screenshots? Add everything to your PR description in a clear way so they can optimize their work 🤗
Once you've had someone review your code, you might have some changes to make. Use the previous setup to make the changes, test them locally, and push it again.
You’ll need to squash your commits and, if it's been too long since you opened your pull request, you'll also want to rebase your branch on top of the upstream master.
cd rails-dev-box/rails git fetch upstream git rebase -i upstream/master git push --force origin YOUR_BRANCH_NAME
That should update your PR history and relaunch the CI.
If you need some guidance on how to rebase on top of master, thoughtbot has a pretty detailed article going through the whole workflow.
I hope that helps! Here's a sample of a contribution to Rails we made at Doctolib: github.com/rails/rails/pull/37581. Notice how descriptive the comments are and how long a review process can take. That should help you find some inspiration and reduce anxiety 😌
Please leave a comment with questions or suggestions below. And if you want to contribute to building the future of healthcare, Doctolib is hiring Ruby on Rails developers in Paris, Berlin, Nantes, and more yet to come...