Working with Gerrit and Tox

Hey!!

Today I am going to share some of the small things I’ve picked up during the course of my internship regarding working with Gerrit, running tests locally etc.

Running unit tests locally

One of the small but very useful things I learned about was regarding running unit tests locally. The one thing that should definitely be done is running the tox tests locally and resolving any issues before submitting any change for review. Running the command “tox” in the projects root directory runs all the tests for all the categories of tests as specified for the project like python-2.7, python3.4, pep8, docs etc.

However, running all these tests may take a while. There may be times when you may want to run just a particular category of tests, for which you can just run the “tox -e <test>” command (here <test> refers to the category of test you want to run). Further, there may be a case where you may want to run only one particular unit test, or just a few unit tests. In this case, running even just the py27 tests, for instance, may seem like a bit of a pain. In this case, the following commands can be used to test just a few unit tests at a time:

source .tox/py27/bin/activate
testr list-tests test_name_regex > my-list
python -m testtools.run discover --load-list my-list

In the above commands, test_name_regex refers to the unit test(s) you want to run. Running these commands then only runs the specific unit tests that you want to run instead of running all the unit tests. Alternately, if you want to run just one test, you could simply run the following command:

tox -e py27 -- <test>

In the above command, <test> refers to the unit test you want to run. Although in this case, the entire path to the test needs to be provided (for instance, glance.tests.unit.test_glance_replicator.ImageServiceTestCase.test_rest_errors) which is in contrast with the set of commands I mentioned earlier where just the test name suffices (for instance, test_rest_errors).

Adding dependencies

Another thing I learned about recently is adding dependencies on patches. There may be a case where you may want to submit a very big patch, but instead decide to split it into smaller patches. In this case, it makes sense to make one patch dependent on another. Another case where dependencies may be used is when a patch that you submit may require another patch still under review to be submitted first.

Firstly, what does adding a dependency mean? So, for instance, there is a patch under review, let’s call it patch X. And there is a patch Y that is dependent on X. In terms of code, what this means is that for patch Y, its master branch is actually patch X i.e. all the changes that are made in patch Y are made on the state of the repository with X’s changes made on it. X on the other hand (if it is not dependent on any other patch too) is based on the master branch i.e. the current state of the repository. So once Y has been submitted for review, if any changes are made on the X patch i.e. new patchsets are uploaded for it, Y will have to be rebased. Rebasing a patch just means bringing it up-to-date with the master branch. However, Y will have to be rebased onto X’s new patchset.

However, there are a few fairly simple commands that can be used to add dependencies. First, you need to fetch the change under review and checkout a new branch to work on as follows:

git review -d $CHANGE_NUMBER
git checkout -b $BRANCH_NAME

Next, you can make the changes for the patch to be submitted, and then submit the patch as follows:

git commit -a
git review

So the patch that you have now submitted will be dependent on the patch that you fetched using the first command. This method can be used when creating a new patch and making it dependent on another existing patch. If you have already submitted a patch for a change, and then want to make it dependent on another existing patch, you can simply fetch the parent change, cherry-pick your commit on top of it, and then submit the rebased change for review, as follows:

git review -d $PARENT_CHANGE_NUMBER
git review -x $CHILD_CHANGE_NUMBER
git review

Lastly, if you want to rebase your change since your parent change has been changed since then, you can just run the following command:

git rebase -i $PARENT_CHANGE

That’s all for now. Thanks for reading! 😀