Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add information about required E2E testing #1425

Merged
merged 1 commit into from
Dec 10, 2024
Merged

Add information about required E2E testing #1425

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions site/content/contribute/more-info/getting-started/code-review.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -130,12 +130,16 @@ If you are a core committer asked to give a review
4. Avoid leaving a review hanging.
* Try to accept or reject the review instead of just leaving comments.
* If you are the last developer to approve the changes, consider requesting a review from the appropriate QA tester to speed up the process.
5. Merge the pull request.
6. Run the E2E tests against the PR code
* After the PR has been reviewed, the reviewer should trigger an E2E test run on it by using [one of the available mechanisms](https://mattermost.atlassian.net/wiki/spaces/CLOUD/pages/2627371043/E2E+Tests). The E2E Test result will be posted back to the PR as a comment.
* It's the PR author's responsibility to address the E2E test failures, with the assistance of the reviewers.
* Core committers can refer to [this Confluence page](https://mattermost.atlassian.net/wiki/spaces/CLOUD/pages/2627371043/E2E+Tests) for additional informations on E2E testing and related processes.
7. Merge the pull request.
* Do not merge until the labels `1: UX Review`, `2: Dev Review` and `3: QA Review` labels have been removed.
* Add the `4: Reviews Complete` label if the last reviewer did not already add it.
* Do not merge if there are outstanding changes requested.
* Do not merge if there are any `Do Not Merge` labels applied.
- When in doubt, leave the merging of the pull request to the author.
* Merge the pull request, and delete the branch if not from a fork.
6. Handle any cherry-picks.
8. Handle any cherry-picks.
* There is an automated cherry-pick process and the author of the pull request should make sure the cherry-pick succeeds. Assume this is the case unless you are explicitly asked to help cherry-pick.
Loading