Closed Bug 994176 Opened 10 years ago Closed 10 years ago

Create branched versions of marionette-client and consumer packages

Categories

(Remote Protocol :: Marionette, defect, P1)

defect

Tracking

(b2g-v1.3 fixed, b2g-v1.3T fixed)

RESOLVED FIXED
Tracking Status
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed

People

(Reporter: mdas, Assigned: davehunt)

References

Details

(Keywords: pi-marionette-runner, pi-marionette-task)

Attachments

(9 files, 1 obsolete file)

1.23 KB, patch
mdas
: review+
Details | Diff | Splinter Review
46 bytes, text/x-github-pull-request
bsilverberg
: review+
Details | Review
847 bytes, patch
wlach
: review+
Details | Diff | Splinter Review
1.15 KB, patch
wlach
: review+
Details | Diff | Splinter Review
1.65 KB, patch
ahal
: review+
Details | Diff | Splinter Review
46 bytes, text/x-github-pull-request
zcampbell
: review+
Details | Review
1.65 KB, patch
davehunt
: review+
Details | Diff | Splinter Review
620 bytes, patch
wlach
: review+
Details | Diff | Splinter Review
2.89 KB, patch
wlach
: review+
Details | Diff | Splinter Review
Filing as a bug for tracking. We need to investigate how to make the marionette client backwards compatible up to v.13, to make it easier for consumers of the marionette client (like gaiatest, b2gperf, etc.). This way, they won't need to know which version of the package to use, they can just use master, and we won't need to uplift patches to different versions of the client, we'll just maintain one.
Whiteboard: [runner]
Assignee: mdas → dburns
Priority: -- → P1
Whiteboard: [runner]
Assignee: dburns → dave.hunt
The latest proposal is to release packages from the branched releases, such as marionette_client_b2g28_v1_3. This would therefore be the most suitable package to use when running against gecko 28 and gaia 1.3. In this proposal marionette_client package would commit only to supporting mozilla-central, however it may work to some extent with other branches.
Blocks: 1008234
We've decided to release marionette client packages based on branch. For example, for mozilla-b2g28_v1_3, we will release marionette_client_mozilla-b2g28_v1_3 with initial version number 0.1.

To do this, we'll need to verify that our consumers who are using unpinned (master) marionette client against these branches can safely switch to using the new packages. We'll need to uplift any missing changes before releasing the initial packages.

From our meeting, we need to verify against:
* b2gperf, b2gpopulate, and gaiatest
* marketplace tests: https://github.com/mozilla/marketplace-tests-gaia/ contains the tests that rely on some features currently in m-c
* Eideticker. The source may not branch, we'll need to find a way to pull in the right marionette client w/o branches
* any other consumer of unpinned versions of marionette. If you want to point one out, please comment.

After we release the client packages, we'll need to update the consumer packages like b2gperf, b2gpopulate and gaiatest.
Summary: Scope out what's needed to get master marionette client compatible with v1.3, v.1.4 onwards → Create branched versions of marionette-client and consumer packages
Blocks: 1017484
I've tested marionette_client from the mozilla-b2g28_v1_3 branch with gaiatest from the v1.3 branch. Everything worked fine with marketplace-tests-gaia, and only a few uplifts are needed for gaiatest to get b2gperf and b2gpopulate working. I'll submit patches for each of these.

:mdas One thing I did notice is that the scrolling isn't working, so we may need the APZ fixes uplifted in the Marionette client, but I'm not sure if we really need that fixed as we're not running the FPS tests against v1.3.

:bsilverberg As you pointed out, there may be desirable uplifts in addition to the required uplifts. I think for 0.1 of each of these new packages we should only concern ourselves with the changes required to get the tests passing. We can then tackle any other uplifts (such as improving the waits) as enhancements.
No longer blocks: 1008234
(In reply to Dave Hunt (:davehunt) from comment #3)
> 
> :bsilverberg As you pointed out, there may be desirable uplifts in addition
> to the required uplifts. I think for 0.1 of each of these new packages we
> should only concern ourselves with the changes required to get the tests
> passing. We can then tackle any other uplifts (such as improving the waits)
> as enhancements.

wfm
Comment on attachment 8430654 [details] [review]
Create branched version of gaiatest for mozilla-b2g28_v1_3

I added a question about how to test in the PR.
Attachment #8430657 - Flags: review?(wlachance) → review+
Attachment #8430656 - Flags: review?(wlachance) → review+
Attachment #8430648 - Flags: review?(mdas) → review+
Attached file PR for gaia v1.3 (obsolete) —
This is failing Gu on mozilla-b2g28 since it was trying to use tip marionette_client, so I pushed a patch to fix it on gaia's v1.3 branch.

will r? if it passes travis
(In reply to Malini Das [:mdas] from comment #12)
> Created attachment 8432687 [details] [review]
> PR for gaia v1.3
> 
> This is failing Gu on mozilla-b2g28 since it was trying to use tip
> marionette_client, so I pushed a patch to fix it on gaia's v1.3 branch.
> 
> will r? if it passes travis

That's what attachment 8430654 [details] [review] is for, although I'm fine with this one landing first.
(In reply to Dave Hunt (:davehunt) from comment #13)
> That's what attachment 8430654 [details] [review] is for, although I'm fine with this
> one landing first.

Why in the world was comment 11 landed without this attachment being ready? Was the bustage unexpected? What were we expecting would happen when landing one without the other?
Flags: needinfo?(dave.hunt)
Attachment #8432687 - Flags: review?(jgriffin)
Comment on attachment 8432687 [details] [review]
PR for gaia v1.3

lgtm
Attachment #8432687 - Flags: review?(jgriffin) → review+
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #14)
> (In reply to Dave Hunt (:davehunt) from comment #13)
> > That's what attachment 8430654 [details] [review] is for, although I'm fine with this
> > one landing first.
> 
> Why in the world was comment 11 landed without this attachment being ready?
> Was the bustage unexpected? What were we expecting would happen when landing
> one without the other?

This is my fault - I wasn't aware that we were running Gu on mozilla-b2g28. Could someone please link to the bustage so I can see what the failure was? Malini's patch was passing on Travis, which had a prerequisite of the package being available on PyPI.
Flags: needinfo?(dave.hunt) → needinfo?(ryanvm)
Blocks: 987046
Blocks: 1005057
Comment on attachment 8430654 [details] [review]
Create branched version of gaiatest for mozilla-b2g28_v1_3

marketplace-tests-gaia all pass for me on a Hamachi with a v1.3 build and this branch.
Attachment #8430654 - Flags: review?(bob.silverberg) → review+
Bug 1020396 reminded me that we also have the marionette-transport package. Does it make sense to also branch this? Otherwise our branched marionette-client package will depend on the latest marionette-transport package.
Flags: needinfo?(mdas)
Flags: needinfo?(jgriffin)
The only thing in transport.py that's at risk of breaking across branches is if we ever change what we expect from the connect() and send() function (https://mxr.mozilla.org/mozilla-central/source/testing/marionette/transport/marionette_transport/transport.py#77), which would happen if we change how we communicate with the server. We may do that to enforce WebDriver compatibility (the other option is to keep it the same and write transport.py-like libraries for each client language).


If this happens, we'll either need to pin the branches to older versions of marionette-transport or branch. Since we don't know if this will happen, I think it's safe to keep using the latest package and not branch.
Flags: needinfo?(mdas)
I agree; since we expect this to change very infrequently, I think we're ok without branching.
Flags: needinfo?(jgriffin)
Okay this failed because we needed to land attachment 8430654 [details] [review] at the same time as the others. I'll update this patch to include the tbpl_requirements change, and reland when I have time to watch TBPL like a hawk.
Comment on attachment 8432687 [details] [review]
PR for gaia v1.3

I've incorporated this change into attachment 8430654 [details] [review].
Attachment #8432687 - Attachment is obsolete: true
I've released gaiatest-v1.3 version 0.1 to PyPI:
https://pypi.python.org/pypi/gaiatest-v1.3/0.1
Blocks: 1028254
Attachment #8430654 - Attachment description: Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/19758 → Create branched version of gaiatest for mozilla-b2g30_v1_4
Attachment #8430654 - Attachment description: Create branched version of gaiatest for mozilla-b2g30_v1_4 → Create branched version of gaiatest for mozilla-b2g28_v1_4
Attachment #8430654 - Attachment description: Create branched version of gaiatest for mozilla-b2g28_v1_4 → Create branched version of gaiatest for mozilla-b2g28_v1_3
Comment on attachment 8445138 [details] [diff] [review]
Create branched version of Marionette client for mozilla-b2g30_v1_4

Review of attachment 8445138 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for doing this!
Attachment #8445138 - Flags: review?(ahalberstadt) → review+
Comment on attachment 8445139 [details] [review]
Create branched version of gaiatest for mozilla-b2g30_v1_4

r+
Attachment #8445139 - Flags: review?(zcampbell) → review+
Fixed mozrunner to be the latest from the target branch. Carried r+
Attachment #8445155 - Flags: review+
(In reply to Zac C (:zac) from comment #33)
> Comment on attachment 8445139 [details] [review]
> Create branched version of gaiatest for mozilla-b2g30_v1_4
> 
> r+

I'm currently trying to get a clean run of tests against these new branched versions. There's a unit test fix that I'll be uplifting, but I think I've resolved a lot of the other issues I was having locally. My last run unfortunately hit a crash that wasn't possible to recover from. I'll update when I have more results.
Blocks: 1027570
Okay, all tests are now passing for me. I'll attach the patches for b2gpopulate and b2gperf. The latter required a revert that was dependent on a more recent gaiatest release.
The revert here was from https://github.com/mozilla/b2gperf/commit/1dba265dfff7ccf9c83f4fe60bca5454c49cc311 which uses getActiveApp, which was added after the branch was created.
Attachment #8445952 - Flags: review?(wlachance)
Comment on attachment 8445952 [details] [diff] [review]
Create branched version of b2gperf for mozilla-b2g30_v1_4

Review of attachment 8445952 [details] [diff] [review]:
-----------------------------------------------------------------

makes sense to me.
Attachment #8445952 - Flags: review?(wlachance) → review+
Comment on attachment 8445949 [details] [diff] [review]
Create branched version of b2gpopulate for mozilla-b2g30_v1_4

lgtm
Attachment #8445949 - Flags: review?(wlachance) → review+
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: