Applying and trying proposed pull requests

In the GitHub world, a Pull Request (PR) is a request that's made by a developer so that the maintainers of a project can include some new developments. Such a PR may contain a bug fix or a new feature. These requests are reviewed and tested before being pulled into the main branch.

This recipe explains how to apply a PR to your Odoo project in order to test an improvement or a bug fix.

Getting ready

As in the previous recipe, suppose you reported an issue with partner_address_street3 and received a notification that the issue was solved in a PR, which hasn't been merged in the 14.0 branch of the project. The developer asks you to validate the fix in PR #123. You need to update a test instance with this branch.

You should not try out such branches directly on a production database, so first create a test environment with a copy of the production database (refer to Chapter 1, Installing the Odoo Development Environment).

How to do it…

To apply and try out a GitHub PR for an add-on, you need to perform the following steps:

1. Stop the instance.
2. Go to the directory where partner-contact was cloned:

   $ cd ~/odoo-dev/my-odoo/src/partner-contact

3. Create a local tag for the project so that you can revert to that version in case things break:

   $ git checkout 14.0
   $ git tag 14.0-before-update-$(date --iso)

4. Pull the branch of the pull request. The easiest way to do this is by using the number of the PR, which should have been communicated to you by the developer. In our example, this is PR number 123:

   $ git pull origin pull/123/head

5. Update the partner_contact_gender1 add-on module in your database and restart the instance (refer to the Installing and upgrading local add-on modules recipe if you don't know how to update the module).
6. Test the update—try to reproduce your issue, or try out the feature you wanted.

If this doesn't work, comment on the PR page of GitHub, explaining what you did and what didn't work so that the developer can update the PR.

If it works, say so on the PR page too; this is an essential part of the PR validation process, and it will speed up merging in the main branch.

How it works…

We are using a GitHub feature that enables pull requests to be pulled by number using the pull/nnnn/head branch name, where nnnn is the number of the PR. The Git pull command will merge the remote branch in ours, applying the changes in our code base. After this, we update the add-on module, test it, and report back to the author of the change with regard to any failures or success.

There's more…

You can repeat step 4 of this recipe for different pull requests in the same repository if you want to test them simultaneously. If you are really happy with the result, you can create a branch to keep a reference to the result of the applied changes:

$ git checkout -b 14.0-custom

Using a different branch will help you remember that you are not using the version from GitHub, but a custom one.

Note

The git branch command can be used to list all of the local branches you have in your repository.

From then on, if you need to apply the latest revision of the 14.0 branch from GitHub, you will need to pull it without using --ff-only:

$ git pull origin 14.0