New test environments: Difference between revisions
(Add tasks section) |
(Replace number bullet with bullet) |
||
| Line 13: | Line 13: | ||
Broadly speaking, the following are the discrete phases involved. | Broadly speaking, the following are the discrete phases involved. | ||
* ensure availability of machines (if hardware) | |||
responsibility: release engineering | responsibility: release engineering | ||
* enable platform on try | |||
placeholder | placeholder | ||
* run all suites on try | |||
placeholder | placeholder | ||
* begin greening process | |||
placeholder | placeholder | ||
* create, review and land patches | |||
placeholder | placeholder | ||
Revision as of 21:09, 7 August 2019
Overview
From time to time, there rises a need to upgrade the underlying operating system of a platform. This need arises in sync with new major releases of various operating systems that form part of the CI infrastructure.
For instance, as of 2019-08-07, all Firefox builds for Linux is executed on Ubuntu 16.04.5 docker containers. In other words, the version of Linux distribution used for testing is at least 2 major releases behind the likely dominant version on the market, which is Ubuntu 18.04.
Upgrade of the underlying operating system version has been, in the past, considered a large undertaking often taking upwards of 6 months. This causes a chicken-and-egg problem where regular upgrades do not occur due to the perceived amount of work, which in turn causes the amount of issues to multiply when the upgrade is finally tackled.
The aim of this document, and process is to establish a standardized process that can be used by anyone in Mozilla engineering to perform operating system upgrades.
Tasks
Broadly speaking, the following are the discrete phases involved.
- ensure availability of machines (if hardware)
responsibility: release engineering
- enable platform on try
placeholder
- run all suites on try
placeholder
- begin greening process
placeholder
- create, review and land patches
placeholder