I went to RailsConf this year and really liked Yehuda Katz’s talk about getting involved with the development of Rails. It really did inspire me to become more active in contributing in the Rails community. While at the conference I talked to 37signal’s Jeremy Kemper about working through some of the open Rails bug tickets. Tickets are a thing I am most familiar with working at Engine Yard as an Application Support Engineer. Working through complex issues and tickets with customers is part of the job. So, looking at the number of bug tickets with Rails (700+), I felt this was a great way to help out a bit. My thought was that I could work through the tickets, close some out that were not valid and push ones that had gone stale over time. Working with Jeremy he helped get me additional privileges with my Lighthouse account on the Rails project so that I could have greater control over the tickets. I could now close out tickets or mark them as invalid.
I first started working through the tickets when we had a hack day at Engine Yard. The hack day was set up so we could work on any single project in which we wanted to contribute. This could be a simple application that we could build in a day, contribute back some code to open source or anything along these lines for example. During hack day I worked on about 20-25 Lighthouse tickets. I was really happy with the progress I had made in that short time frame. While most people may not have an entire day to work on Lighthouse tickets, every little bit helps. This is the great thing with contributing with Rails. You may not want to work through patches, code or issues, but there is still many ways that you can contribute. You can work through these tickets to see if there are ones that can be closed as they are not relevant or there is the Rails documentation project which that you can contribute. After working on these tickets, I wanted to get more in to the internals of Rails and contribute some code. I wanted to be a Rails commiter. Before I could get to this point, I needed to be able to have the rails source on my machine and running the tests locally.
Guide on how to get the tests running locally
The first step is to clone the Ruby on Rails repo. The way I work is by having a top level projects folder under my user’s home directory. I then created a subfolder called ror_source under projects and then ran:
git clone http://github.com/rails/rails.git
This created a rails folder under my ror_source folder.
The next step was to go in to the rails directory and install the necessary gems using bundler. Before you do this though you will want to be certain you have the latest version:
gem install bundler –no-rdoc –no-ri
Then run bundle install to get them gems installed:
This will install all the necessary gems for you. Once you have this working, you can then run your tests:
When you do this, you will get errors since you don’t yet have Postgres, MySQL and sqlite3 configured as of yet. Ruby on Rails’ tests run against those 3 database types so for your tests to pass successfully you will need to have all 3 of these working. It is also important to note that if you are working on a bug, patch, etc. for Active Record you will need to make sure that you have tested against all 3 of these or your patch will get rejected. So, the next step and that is to get your databases set up and working. First, let’s get MySQL working and configured:
First set up the rails user for access to the database:
mysql -uroot -e ‘grant all on *.* to rails@localhost;’
Once this is done you can then create the databases for the rails user:
You now should have Rails running with MySQL. Let’s get Postgres working now.
This is a little bit different. There is a rake file that will help you get Postgres working. First go to the activerecord directory under the rails source. Under this folder is a rakefile. The rakefile that is there is used to build the databases. You will want to run the following command:
This will create the database for postgres. When I ran the test from this point I got a Postgres error that really stumped me. It said:
error: in `initialize': fe_sendauth: no password supplied (PGError)
I did a bit of research on this and found that the pg_hba.conf file for postgres needed to be updated. The method needed to be updated from MD5 to trust. Once I did this, I was still getting the error. I was completely stumped at this point. I talked to one of our database administrators at Engine Yard and found that pg_hba.conf is not loaded on each start. I had to manually reload the config file for it to pick up the changes.
So, here is how you reload the config file:
su to the postgres user, add the path to pg_ctl to $PATH, and then finally run the command: pg_ctl reload -D
Then re-run your tests and you should be in business now. From here you should be able to start looking at patches, bugs and other issues. I will get in to actually working on an issue in part 2.