Release marionette-driver 0.2 and marionette-client 0.9

RESOLVED FIXED in Firefox 38

Status

defect
--
blocker
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: davehunt, Assigned: whimboo)

Tracking

({pi-marionette-client})

unspecified
mozilla39
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox38 fixed, firefox39 fixed)

Details

Attachments

(1 attachment)

Once bug 1107336 is resolved we'll want to release a new version of the marionette-client package.
Is this likely to happen very soon? I'd like to get a new version out to pick up some fixes I landed for Luciddream.
It depends on the blocking bug. I would suggest releasing 0.8.8 if you need something soon.
The patch on the dependent bug landed right now on inbound. If it sticks we will have it fixed later today. Lets cross fingers!
David, how important is it to get a new release out? We don't have new Nightly builds yet, but I wonder if we will see breakage today with the packages separated.
Flags: needinfo?(dburns)
As it looks like we need both marionette-client and marionette-driver released. For marionette-client we would need an extra version bump. marionette-driver we should be able to get released immediately.

It's interesting that a 'python setup.py develop' for marionette-client on mozilla-central doesn't pick up the dev package in the same repo, but tries to get it from pip instead.
Summary: Release marionette-client 0.9 → Release marionette-driver 0.1 and marionette-client 0.9
Looks like marionette-driver 0.1.0 has been released to pypi:
https://pypi.python.org/pypi/marionette_driver/0.1.0

In marionette-client we have a dependency for "marionette-driver == 0.1", not sure if that makes a problem. But even when I fix that for 0.1.0 I still see the problem with the requirements.txt file:

> Processing marionette_driver-0.1.0.tar.gz
> Writing /tmp/easy_install-9nZs0Y/marionette_driver-0.1.0/setup.cfg
> Running marionette_driver-0.1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-9nZs0Y/marionette_driver-0.1.0/egg-dist-tmp-gbRRXR
> error: [Errno 2] No such file or directory: 'requirements.txt'

I assume it might not get packaged.
Blocks: m21s
Severity: normal → blocker
I was right here. The requirements.txt file is not present. So what we need is a MANIFEST.in file for marionette-driver and release a new version for it too. I will take it.
Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Flags: needinfo?(dburns)
Summary: Release marionette-driver 0.1 and marionette-client 0.9 → Release marionette-driver 0.2 and marionette-client 0.9
Attachment #8569715 - Flags: review?(dburns) → review+
We decided to already release both new versions without waiting for the merge to mozilla-central to stop the breakage.

Submitting dist/marionette_driver-0.2.tar.gz to https://pypi.python.org/pypi
Server response (200): OK

Submitting dist/marionette_client-0.9.tar.gz to https://pypi.python.org/pypi
Server response (200): OK
Changesets past my landing are green so I was going to get this patch merged to mozilla-central:

https://hg.mozilla.org/mozilla-central/rev/dcc86f78d75e
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Duplicate of this bug: 1137357
Wes, I'm a bit confused. Why are there two different commits for mozilla-central?
Flags: needinfo?(wkocher)
Mine was the actual merge of https://hg.mozilla.org/integration/mozilla-inbound/rev/5bc2f6d9dfce to m-c, yours had a changed commit message (and a different SHA), so I guess mc-merge didn't see it as the same commit. As far as I can tell, the second one should end up being a no-op.
Flags: needinfo?(wkocher)
Ah, I see! That might be indeed the case here. Thanks!
I did a quick check of a few of the affected files and they appear to match what the patch here did, so hopefully nothing broke.
What has been changed in the released version since the last release:

$ hg log -M -r dcc86f78d75e:: --template "{node|short}: {desc|firstline}\n" testing/marionette
1124667 - Release marionette-driver 0.2 and marionette-client 0.9. r=automatedtester, a=testonly DONTBUILD
Please scratch my last comment. It was wrong. Here the correct output:

Bug 1120364 - Bump marionette_client version to 0.8.7.
Bug 1121335 - Add the testing of selectioncarets drag with multiple selection ranges,
Bug 1114695 - factor a lot of MarionetteJSTestCase.runTest out into CommonTestCase.run_js_test.
Bug 1112660 - Fix B2GDesktopInstance.required_prefs.
Bug 859952 - B2GDesktopInstance should clone the gaia profile by default.
Bug 1105863 - Add docstring to timeouts.
Bug 1112913 - Screenshots should return only the view port.
Bug 1128760 - Part 1: Disable onerror hooking in chrome context.
Bug 1128760 - Part 2: Expose debug_script option.
Bug 1084125: Merge in desired capabilities when passed in on new session;
Bug 1084125: Add in SessionNotCreatedException to marionette;
Bug 1084125: Allow requiredCapabilities in Marionette, if they are not fulfilled then a new session is not created.
Bug 1090925 - Add keyboard support to marionette action chains ("keyDown" and "keyUp").
Bug 906712 - Tab modal dialog support for marionette.;r=automatedtester
Bug 906712 - Add a switch_to_alert API to marionette for handling alerts.
Bug 1131219 - Sort updated prefs alphbetically.
Bug 1131219 - Add focusmanager.testmode to Marionette;
Bug 1128515 - Update session_capabilities property.
Bug 1131948 - Part 2: Separate multiple line test cases from test_selectioncarets.html.
Bug 1119211 - Disable the 360 second socket timeout when marionette is invoked with --jsdebugger.
Bug 1133468 - Use wait_for_condition rather than immediately checking for a url update in marionette's modal handling code.
Bug 1131763 - Remove dead constants in marionette.py.
Bug 1133718 - By class misses constant for 'anon attribute'.
Bug 1118298 - Client uses unknown command property session_id.
Bug 1107336: Update marionette unit tests to use new marionette driver;
Bug 1107336: update marionette client runners to use the new marionette driver;
Bug 1107336: Create Marionette Driver containining all of the automation API code;
Bug 1135383 - Convert Marionette unit tests to use SpecialPowers.pushPrefEnv.
Bug 1124667 - Release marionette-driver 0.2 and marionette-client 0.9.

Generated (and then edited) using:
$ hg log -M -r 262fa804b844:: --template "{node|short}: {desc|firstline}\n" testing/marionette/client
David, I'm not sure if there is something we have to do here beside the separate packages for different branches. I assume for the latter you want a new bug? It's important because we need another release of driver and client soon. See bug 1143565.
Flags: needinfo?(dburns)
They are released but we need those versions to be available for Firefox 38.
(In reply to Henrik Skupin (:whimboo) from comment #23)
> They are released but we need those versions to be available for Firefox 38.

Why do we need those versions for Firefox 38? Have all of the patches from these versions been uplifted and confirmed compatible with 38? As I understood it the latest released versions are only supported against mozilla-central, has this changed? If so, how many versions back do we support? Also, can't we just use the latest versions from PyPI against these versions, or the in-tree packages (ignoring the version numbers). I'd at least like to see the version support matrix and release process documented for Marionette.
We are working on the uplift. David can give you a much better report in how this works. I think his last try push as mentioned in comment 21 should contain everything we need on 38.
Ah, okay. Perhaps there is a new policy for uplifting Marionette changes then. That's great - looking forward to understanding this more. Thanks Henrik.
So in short, there are blockers for our firefox ui tests, which have only been landed on 39 so far. But we want to get our tests running for Firefox 38 ESR, to not have to maintain Mozmill another year until we desupport that ESR release. Also given that those necessary changes are not only driver and client changes but also marionette server, we have to get all those patches backported. Please note that FxOS will not use 38, so we do not expect any breakage on that side.
You need to log in before you can comment on or make changes to this bug.