15
edits
TestEngineering/Performance/Sheriffing/Workflow: Difference between revisions
TestEngineering/Performance/Sheriffing/Workflow (view source)
Revision as of 13:34, 23 February 2024
, 23 February 2024→How to triage a firefox-android alert: Provided information for special case
Bacasandrei (talk | contribs) (→Sheriffing Firefox-Android Alerts: Adding more updated info) |
Bacasandrei (talk | contribs) (→How to triage a firefox-android alert: Provided information for special case) |
||
| Line 404: | Line 404: | ||
* make sure you’re seeing the jobs from current revision back and look for gaps | * make sure you’re seeing the jobs from current revision back and look for gaps | ||
2. Trigger the jobs in the revisions in the gap (browsertime & build_metrics) | 2. Trigger the jobs in the revisions in the gap (browsertime & build_metrics) | ||
* For every revision in the gap click | * For every revision in the gap click '''''Add new jobs''''' and trigger the needed job manually | ||
3. Find the responsible push that caused the regression | 3. Find the responsible push that caused the regression | ||
* If the regression is caused by a mozilla-central push, then you have to take the build id (Update GeckoView (Nightly) to 121.0.20231106094018.) and search for the revision in Buildhub | * If the regression is caused by a mozilla-central push, then you have to take the build id (Update GeckoView (Nightly) to 121.0.'''20231106094018'''.) and search for the revision in [https://buildhub.moz.tools/ Buildhub] | ||
* Build-metrics: file a generic performance regression | * Build-metrics: file a generic performance regression | ||
* Browsertime: it should be an autoland alert to mark as downstream for | * Browsertime: it should be an autoland alert to mark as downstream for | ||
4. If it’s caused by a firefox-android push then the process of filling a regression bug should be straight-forward - the default one from documentation. (browsertime & build_metrics) | 4. If it’s caused by a firefox-android push then the process of filling a regression bug should be straight-forward - the default one from [[TestEngineering/Performance/Sheriffing/Workflow#Filing_a_regression_bug|documentation]]. (browsertime & build_metrics) | ||
==== Special case ==== | |||
There’s a special case that happens very very rare when code from geckoview build (mozilla-central) doesn’t affect geckoview pageload but affects fenix (firefox-android). It is the case for alert [https://treeherder.mozilla.org/perfherder/alerts?id=40028&hideDwnToInv=0 40028]. In this case there’s no other option than bisection on mozilla-central with fenix build. The steps are: | |||
# Follow bisection workflow from documentation | |||
# Checkout to the previous commit of the suspect one | |||
# Download the [https://treeherder.mozilla.org/jobs?repo=firefox-android&group_state=expanded&tochange=71d772f64a8acfd1f916d8cc7fde01957c5ca2d5&fromchange=71d772f64a8acfd1f916d8cc7fde01957c5ca2d5&searchStr=fenix-android-all%2Copt%2CNightly-related%2Ctasks%2Cthat%2Crun%2Con%2Ceach%2Cgithub%2Cpush%2Cbuild-apk-fenix-nightly-simulation%2CB&selectedTaskRun=Zxf1CST0Ru61vzqrElJp3A.0 fenix-android-all fenix-nightlySim(B) build]: [https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Zxf1CST0Ru61vzqrElJp3A/runs/0/artifacts/public/build/target.armeabi-v7a.apk target.armeabi-v7a.apk] (artifacts) | |||
# Add it to the code using the command: ''./mach try perf --browsertime-upload-apk path/to//target.armeabi-v7a.apk'' | |||
# Commit ''hg commit -m="fenix apk"'' | |||
# Push to try the pageload job for geckoview ''Android 11.0 Samsung A51 AArch64 Shippable'' | |||
# Repeat steps 1-6 for pushing to try the suspected revision and then compare the results to try. | |||
= Resources = | = Resources = | ||
* [https://wiki.mozilla.org/TestEngineering/Performance/FAQ FAQ] | * [https://wiki.mozilla.org/TestEngineering/Performance/FAQ FAQ] | ||