From 5e3255ea578951def9da87c8940b364618e460a3 Mon Sep 17 00:00:00 2001 From: diana Date: Fri, 1 Sep 2023 15:26:26 +0200 Subject: [PATCH] Docs update: required e2e --- doc/merging-pr-process.md | 5 +++-- doc/pipeline_process.md | 13 +++++++------ 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/doc/merging-pr-process.md b/doc/merging-pr-process.md index e86174b951..90efa3fff6 100644 --- a/doc/merging-pr-process.md +++ b/doc/merging-pr-process.md @@ -4,10 +4,11 @@ 2) Add some reviewers to the PR and wait for feedback 3) Address feedback 4) Make sure builds and tests are green (run `make test` locally, `make lint-fix` to fix any indentation issue and `make lint`) -5) Once the PR has been reviewed by the dev team you can run e2e tests on it by going to https://github.com/status-im/status-mobile/projects/7 and move the pr under the column E2E tests. This will trigger tests. +5) Once the PR has been reviewed by the dev team, run e2e tests on it by going to https://github.com/status-im/status-mobile/projects/7 and move the pr under the column E2E tests. This will trigger tests. **Running E2E tests is required for all PRs.** 1) Read our [PR Review Policy](pr-review-policy.md) for more details on our approach to PR reviews. + 2) Learn more about our [Pipeline for QA](pipeline_process.md) process 6) Once e2e tests have run, they will report the result on the PR, if it's less than 100%, ask QA to take a look to make sure everything is in order (some might fail for legitimate reasons) -7) Ask QA for manual testing if the PR requires it +7) Ask QA for manual testing if the PR requires it (more details [here](pipeline_process.md)) 8) Once it has been tested successfully, squash everything into one commit. rebase and merge. The commands we use: ``` git checkout develop diff --git a/doc/pipeline_process.md b/doc/pipeline_process.md index a44ddce5f9..858d3d6645 100644 --- a/doc/pipeline_process.md +++ b/doc/pipeline_process.md @@ -1,6 +1,6 @@ # Pipeline process -[Pipeline for QA](https://github.com/status-im/status-mobile/projects/7) is a project board for developers and testers used to track the status of a pull request, get reviews and manual testing, _and run autotests_ (_temporary disabled_). +[Pipeline for QA](https://github.com/status-im/status-mobile/projects/7) is a project board for developers and testers used to track the status of a pull request, get reviews and manual testing, and run autotests. The generally accepted recommendations for its use are described below: @@ -53,7 +53,7 @@ _**How do I know if a design review is needed?**_ There are three cases here depending on the changes in the PR: 1. **Functional PRs with UI changes:** after the ```Tested - OK``` label is added, the QA moves the PR to the ```Design review``` column + mentions ```@Francesca-G``` in comments. -2. **Component PRs:** can be moved directly to the ```Design review``` column by the developer when get a review from devs (manual testing step can be skipped) + the developer mentions ```@Francesca-G``` in comments. +2. **Component PRs:** once the PR has received a review from developers and e2e tests results, it can be moved directly to the ```Design review``` column by the developer (manual testing step can be skipped) + the developer mentions ```@Francesca-G``` in comments. 3. **Functional PRs changes in which are not related to UI (e.g. a crash fix):** skip the ```Design review``` step (the PR should only be manually tested by QA). There are three possible scenarios when the design review is completed: @@ -75,10 +75,11 @@ In the second case - after fixing of all found issues, the developer should ping ## Merging a PR **Merge conditions:** 1. Required number of reviews received -2. All commits are squashed into one. -3. No conflicting files in PR -4. No issues from lint -5. Pay attention to automation checks (some of them are not blockers, best to check before merge anyway) +2. E2E results are received and reviewed +3. All commits are squashed into one. +4. No conflicting files in PR +5. No issues from lint +6. Pay attention to automation checks (some of them are not blockers, best to check before merge anyway) ![](images/pipeline-process/automation-checks.png)