TestEngineering/Web/Automation/Gaia UI Testing: Difference between revisions

Jump to navigation Jump to search
Line 137: Line 137:
# Cherry pick the commit that was made to master. You can find the commit hash by looking at the Github pull request:
# Cherry pick the commit that was made to master. You can find the commit hash by looking at the Github pull request:
## <code> git cherry-pick commit-hash</code>
## <code> git cherry-pick commit-hash</code>
## Please note: Use the commit hash of the original commit of code (the one submitted by the pull request author) as opposed to the commit hash of the merge commit (the one created by the person who merged the pull request). For example, for this [https://github.com/mozilla-b2g/gaia/pull/13644 pull request], you would choose commit hash ''a9798fc'', which is the hash of Bob's original commit, not commit hash  ''42de07a'', which is the commit hash of Zac's merge commit.
## The cherry pick may or may not complete without conflicts. If there are conflicts, resolve them manually.
## The cherry pick may or may not complete without conflicts. If there are conflicts, resolve them manually.
## Please note: Use the commit hash of the original commit of code (the one submitted by the pull request author) as opposed to the commit hash of the merge commit (the one created by the person who merged the pull request). For example, for this [https://github.com/mozilla-b2g/gaia/pull/13644 pull request], you would choose commit hash ''a9798fc'', which is the hash of Bob's original commit, not commit hash  ''42de07a'', which is the commit hash of Zac's merge commit.
### If there were conflicts, commit your changes to your branch:
#### <code>git commit -a</code>
#### The commit message should be pre-populated with the commit message from when the changes were committed to master. Leave this commit message intact. You may add a second line to the message to indicate that this is an uplift to the branch of interest.
# Run the affected test(s) against v1.2 to ensure that they still pass.  
# Run the affected test(s) against v1.2 to ensure that they still pass.  
## Note that there may be several tests affected which may not be included in the commit. For example, if a locator or method in an app object changes, then any tests that make use of that app object property or method would need to be tested.
## Note that there may be several tests affected which may not be included in the commit. For example, if a locator or method in an app object changes, then any tests that make use of that app object property or method would need to be tested.
## If the tests do not pass, try to determine why and whether or not they can be made to pass by making other changes. If you are unable to get the tests to pass on v1.2, and it isn't because they are attempting to test features that do not exist on v1.2, then make a comment in the bug about this, with the full details of the failures, and leave the bug flagged as ''status-b2g-v1.2: affected''.
## If the tests do not pass, try to determine why and whether or not they can be made to pass by making other changes. If you are unable to get the tests to pass on v1.2, and it isn't because they are attempting to test features that do not exist on v1.2, then make a comment in the bug about this, with the full details of the failures, and leave the bug flagged as ''status-b2g-v1.2: affected''.
## Assuming that the tests are passing, continue to the next step.
## Assuming that the tests are passing, continue to the next step.
# Commit your changes to your branch:
## <code>git commit -a</code>
## The commit message should be pre-populated with the commit message from when the changes were committed to master. Leave this commit message intact. You may add a second line to the message to indicate that this is an uplift to the branch of interest.
# Push your changes to your Github repo:
# Push your changes to your Github repo:
## <code>git push origin branch_name</code>
## <code>git push origin branch_name</code>
Confirmed users
425

edits

Navigation menu