THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
This page outlines guidelines for merging Pull Requests.
NOTE: Due to recently found synchronization issue between GitBox and Github repositories, committers should only use Github repositories for pushing commits.
If you haven't setup Github repository, please refer to the general information page.
Before When merging a Pull Request a Committer:
- MUST make sure that all commits reference the appropriate JIRA.
- SHOULD make sure that all commits have a component tag attached to them.
- MUST ensure a clean commit history, where each commit is meaningful by itself.
- MUST squash fixup commits (for example commits that are addressing review comments).
- Each commit SHOULD address one thing, e.g.:
- SHOULD NOT fix a bug fix commit and reformatting things at once.
- Renamings / refactorings / clean ups that do not change semantics/do not add new features.
- SHOULD rebase the PR and re-run Travis before merging
- If you have linked your Apache and GitHub accounts you can rebase the PR itself and/or restart the Travis build
- If you have not linked your accounts create a rebased copy in your own repository and run Travis
- It is impractical to require always running CI tests on the latest codebase before merging, because new commits can be merged during the CI execution.
- SHOULD check the commits merged into the codebase after the CI being triggered.
- If there is any conflict, or any commit that touches the same components/files that the PR does, it is recommended to at least re-compile the project and re-run the relevant test cases before merging.
- MUST make sure the latest version of the PR passes the CI tests.
- Success CI builds from personal Azure also counts. In that case, please link to the build.
- It’s also acceptable if there is not a complete success build but each stage has succeeded at least once. In that case, please link to all relevant builds.
- See also Best practice handling test failures.
When merging a Pull Request:
- MUST NOT use merge commits.
- SHOULD NOT MAY use the GitHub UI to merge Pull Request.
- SHOULD add Requests IF it has a recent Travis build IF you're pushing manually you MAY amend the commit message with "This closes #PR_ID." to the message of the last commit of the PR.
- When doing so please make sure to not overwrite existing commit messages!
After merging a Pull Request:
- SHOULD back port SHOULD backport bug-fixes to the 2 last versions (e.g., once 1.7 is released, include them in master, release-1.7, release-1.6).
- Changes that affect Flink's behavior (in a way that could break setups) SHOULD NOT be back-ported.
- MUST close the JIRA
- add Add a comment listing the commit hash for each branch respectively.
- check Check the JIRA data
- titleTitle, components, type and type assignee are accurate
- title Title is meaningful
- fixVersion FixVersion covers all versions.
- for For release-X.Y branches, pick the next upcoming release version.
- for For master branch, include the next release version (e.g. 1.8.0), unless it was also merged for the first release in the previous series (1.7.0).
Best practice handling test failures:
- Try reproducing the problem, see if the test failure is deterministic.
- Try run the test locally.
- If the problem cannot be reproduced locally, try re-run the CI build.
- Sometimes the test failures might be deterministic but only in the CI environment.
- If the test failure is deterministic, it is likely related to the PR changes, and further debugging is needed.
- For non-deterministic test failures, search on JIRA see if it has been reported.
- If there’s an existing ticket, report the new instance and link to the build.
- If there isn’t an existing ticket, create one.
- For a test instability of very high frequency, that significantly blocks new PRs from merging.
- Consider upgrading the ticket to Critical or Blocker priority, to receive more attention.
- Try reaching out to committers with expertise in relevant components to look into the issue.
- Raise a discussion on temporarily disabling the relevant test cases, in order not to block other PRs.
- The JIRA ticket must be made a Blocker before disabling the test cases.
- The test cases must be re-enabled before the JIRA ticket is closed / downgraded.