Docs update: required e2e
This commit is contained in:
parent
77fc7a92d9
commit
5e3255ea57
|
@ -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
|
||||
|
|
|
@ -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)
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue