- Odoo Development Cookbook
- Holger Brunn Alexandre Fayolle Daniel Reis
- 582字
- 2021-07-16 11:00:31
Applying and trying proposed pull requests
In the GitHub world, a Pull Request (or PR for short) is a request made by a developer for the maintainers of a project to 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 in 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 pull request, which is not yet merged in the 9.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 (see Chapter 1, Installing the Odoo Development Environment, and Chapter 16, Server Deployment).
How to do it…
To apply and try out a GitHub pull request for an addon, you need to perform the following steps:
- Stop the instance.
- Go to the directory where partner-contact was cloned:
$ cd ~/odoo-dev/my-odoo/src - Create a local tag for the project so that you can revert to that version in case things break:
$ git checkout 9.0 $ git tag 9.0-before-update-$(date --iso)
- Pull the branch of the pull request. The easiest way is to use the number of the PR, which should have been communicated to you by the developer. In our example, this is the pull request number 123:
$ git pull origin pull/123/head - Update the
partner_address_street3addon module in your database and restart the instance (see the previous recipe, Installing and upgrading local addon modules). - Test the update—try to reproduce your issue, or try out the feature you wanted.
If it does not work, comment on the PR page of GitHub, explaining what you did and what did not 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 the merging in the main branch. You can use the text :+1:, which is rendered as a "thumb up" icon, meaning you approve the PR.
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 addon module, test, and report back to the author of the change about any failure or success.
There's more…
You can repeat step four 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 9.0-custom
Using a different branch will help you remember that you are not using the version from GitHub, but a custom one.
From then on, if you need to apply the latest revision of the 8.0 branch from GitHub, you will need to pull them without using --ff-only:
$ git pull origin 9.0