[Iris 2.0] Download Firefox API

Title:

Download Firefox API

Author(s):

Silviu Checherita, Matt Wobensmith

Tracking issue:

Link to the associated Github issue(s).

Short description:

Provide an easy-to-use API for a test case to download, run, and manage its own Firefox instance(s).

Use case(s):

There may be tests that would like the ability to download and run tests on more than one build of Firefox, other than the one associated with the run itself. This API would allow them to do so, and report results within the test case's own assert structure.

The goal of this API should be simplicity. On the code side, ideally we just expose the logic we already have in core Iris code.

It should be noted that this API is to be used in special situations only, as we want to preserve the general concept of one Firefox build per Iris run. This API will cover use cases where it suits our users better to allow them to run a test against different Firefox builds - e.g. multiple locales.

Side note:
We should consider adding an API to reset the main build used for the Iris run. Specifically, delete/overwrite the current Firefox build on disk and unzip it again, to make sure it's fresh. Technically, this is not what we are talking about above, but since we are adding APIs to manage local builds, this is a logical place for it. It would allow us to integrate the update tests back into the larger test suite, as they currently update the active build and would need to restore it back to its original state in order to play nice with the Iris run.

Implementation:

• Overview

One consideration is the location of downloaded builds. We should consider putting them in a temp folder that Iris manages. That temp folder should be emptied when Iris quits.

• Sample code

Either real or pseudo code to describe what the logic will look like. Use code formatting for better readability.

• New and/or changed files and directories

List of additions/changes to the project structure - estimated.

• Control Center

None. Test cases must manage the results of their actions within the normal assert structure. The Control Center will always report the build that the run was started with.

• Localization

Does this feature impact localization?

• Documentation

This API will be documented.

• Bootstrap

N/A

• Setup

N/A

Risks:

• Dependencies on other people/teams/software.

Is this feature ready to be implemented or are we waiting for others? Are there any outstanding (or potential) issues in dependent software that we need to be aware of?

• Other factors that could influence functionality or schedule.

Do you anticipate any changes that could impact your design?

Estimated schedule:

• xxxx-xx-xx Spec due date (this)
• xxxx-xx-xx Implementation
• xxxx-xx-xx Code review
• xxxx-xx-xx Testing
• xxxx-xx-xx Final check-in date