status-mobile/doc/merging-pr-process.md

44 lines
1.9 KiB
Markdown
Raw Normal View History

2023-01-31 12:06:29 +00:00
## PR process
1) Create a PR in status-mobile
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.
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
8) Once it has been tested successfully, squash everything into one commit. rebase and merge. The commands we use:
```
git checkout develop
git pull develop
git checkout your-feature-branch
git rebase develop
git checkout develop
git rebase your-feature-branch
git push
```
## Status-go changes
If you are introducing status-go changes, the PR process is pretty similar, with some differences.
The most important thing is that
status-mobile code that makes it to the `develop` branch, should always point to a tagged version of status-go in the `develop` branch of status-go.
In practice this means:
1) Create a PR in status-go, get it reviewed by status-go devs
2) Create a PR in status-mobile, get it reviewed by devs, then go through manual testing (if necessary)
3) Once ready to merge, merge status-go PR first, make sure you bump the `VERSION` file in status-go
4) Once merged, tag the version with the new version and push the tag:
```
git checkout develop
git pull develop
git tag vx.y.z
git push origin vx.y.z
```
5) Update status-mobile with the new status-go version, using the new tag `scripts/update-status-go.sh "vx.y.z"`
6) Push, make sure it's rebased and go through the merge process as above.