Creating a patch on OpenStack can be time-consuming. Often, you need to go back to documentation to make sure that you have not missed any steps.
The documentation is, of course, well written. However, I find that there are a few things to keep in mind so that you can create a patch successfully at the first attempt.
This article is more of a checklist for you when creating a patch.
Checklist
OpenStack uses Gerrit as its review system and tox as its virtual environment management and test command line tool.
Let's go through the steps that you need to take to create a patch successfully the very first time.
1. Get the latest upstream changes
git remote update
git checkout master
git pull --ff-only origin master
2. Create a topic branch
git checkout -b TOPIC-BRANCH
3. Make your code changes
PyCharm helps you catch linting errors, so I'd advise using it.
4. Run tests
You can run tests in your tox virtual environment. You can also just run the test check in the directory or files that you made changes to.
Running tests ensures that you can rectify basic issues, if any, even before reviewers get to your code, saving everyone's time.
#run test checks within a tox virtual environment
tox -e <python version>
#run test checks within a particular directory
tox -e <python version> -- <directory_path>
#run test checks within a particular file
tox -e <python version> -- <file_path>
5. Fix any errors highlighted
When the tests are done, a summary is generated that shows whether they passed or failed.
The system also generates a file containing the test results. If there are any errors, you need to fix them.
OpenStack's extensive code base may contain warnings unrelated to the recent changes you made. Don't worry too much about warnings. If they are within the files you changed, you might want to fix them.
6. Check for any JavaScript linting and code style errors
If you have any JavaScript code, you can check for any linting or code style errors. You can check for linting errors within a tox virtual environment.
tox -e npm -- lint
7. Ensure you fix any errors highlighted.
8. Check for any Python code style errors
OpenStack has a lot of Python code. If you have made changes to JavaScript code, it is likely to interact with the Python code. You can check for style errors in a tox virtual environment.
tox -e pep8
If you have any errors, fix them before proceeding.
9. Craft a commit message
You need to craft your commit message before you push your changes to Gerrit.To do that, you can use a text editor like vim or nano to ensure you meet the required guidelines.
When you create your patch, it automatically generates the Change-Id. You don't need to create one.
10. Commit your changes
You need to commit your change before submitting it for a review.
git add <file>
git commit -m "<commit message>"
11. Submit your change for review
You are now finally ready to submit your change for review by a project maintainer.
git review
You should see a success message to show that your change was submitted successfully.
12. Wait for merging
If your code changes are correct, then they should be merged in no time. If there are any more changes, you should get feedback from the maintainers.
13. Updating a change
If you need to make any more changes, do so, and then repeat all these steps. This time, however, since you have already created a patch, you'll run a different command during your commit.
git commit -a --amend
Forging Forward
It takes a while to master these steps. Don't worry if you have to sit down and dedicate some time to focus on this.
With practice, it could become second nature. For now, I hope this guide provides a checklist you can use to make your patch-creating process on OpenStack more seamless.
PS: Feel free to subscribe to my newsletter on substack: https://techiewhowrites.substack.com/
Sources
https://docs.opendev.org/opendev/infra-manual/latest/developers.html#quick-reference
Top comments (0)