If your PR implements a major feature or improvement, then you must fill in the Release Note field on the issue's Jira with an explanation of the feature that will be comprehensible by the end user.
Jenkins Pre-commit Check
Once a PR is created, a Jenkins job will be triggered to run a set of pre-commit checks on the pull request, including all Java and C unit tests, find bug test, release audit check, etc. If all checks pass, you should see something like this in your pull request page:
After code review and committers sign off, the pull request will be merged.
If any of the checks fail, you will see this:
In this case, please check the Jenkins output by following the "Details" link, and fix the issue, and try trigger a Jenkins build again. There are two ways to trigger a Jenkins build:
- Close and reopen the pull request. This is the recommended approach, and only the contributor who owns the pull request can do this.
- Update the PR by pushing a new commit or amend the previous commit (git commit --amend). This is also recommended approach and only contributor who owns the pull request can do this.
- A committer or PMC member who has admin access to Apache Jenkins infrastructure can rebuild the same Jenkins job. This is not recommended, because due to permission issues, the rebuild Jenkins job would fail to push the results back to git, and you will see something like this, regardless of the job succeeded or not.
For contributors who owns the pull request: please make sure to get a green build to prepare the patch in a landing state.
For committers: please make sure to get a green build before committing a pull request.
Code Review and Accept Pull Request