Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Platform-releng/Unstable build"
m |
|||
Line 1: | Line 1: | ||
== Purpose == | == Purpose == | ||
− | This page is to describe why a build is marked as Unstable | + | This page is to describe why a build is marked as Unstable. |
== Platform Build == | == Platform Build == | ||
− | There are two types of platform builds performed in regular release cycle. The build process is described here [[Platform-releng/Platform_Build]] | + | There are two types of platform builds performed in regular release cycle. The build process is described here: [[Platform-releng/Platform_Build]]. |
− | * Integration builds(I- | + | * Integration builds (I-builds) built daily at 8:00 PM ET |
− | * Maintenance builds(M-builds) built at 4:00 AM on every Wednesday | + | * Maintenance builds (M-builds) built at 4:00 AM on every Wednesday ET |
== Mark Unstable == | == Mark Unstable == | ||
− | Sometimes there is a possibility of | + | Sometimes there is a possibility of: |
− | * | + | * a bad commit causing some important functionality or test failures |
− | * | + | * due to comparator errors, new code might not be in the build |
− | * any other problem | + | * any other problem deemed serious enough |
− | + | The problem may affect only a particular component, so we don't want to completely fail a build. If other components are waiting for a particular bug fix they can still test their bug fix. But end users or developers better avoid switching to such builds. | |
− | In this scenario we will mark a build unstable and remove it from the | + | In this scenario we will mark a build unstable and remove it from the composite update repository so that the unstable build is not available during the update. If a particular user still wants to try an update he can still do it using the build-specific repository listed in the download. |
− | If a user wants to mark a build unstable they need to send a note (along with bug report) to platform-releng-dev@eclipse.org mailing list informing the need to do so. Platform-releng team will do the needful | + | If a user wants to mark a build unstable they need to send a note (along with bug report) to platform-releng-dev@eclipse.org mailing list informing the need to do so. The Platform-releng team will do the needful, i.e. run the [https://hudson.eclipse.org/releng/job/eclipse.releng.markUnstable/build?delay=0sec markUnstable job]. |
Latest revision as of 13:45, 10 January 2017
Purpose
This page is to describe why a build is marked as Unstable.
Platform Build
There are two types of platform builds performed in regular release cycle. The build process is described here: Platform-releng/Platform_Build.
- Integration builds (I-builds) built daily at 8:00 PM ET
- Maintenance builds (M-builds) built at 4:00 AM on every Wednesday ET
Mark Unstable
Sometimes there is a possibility of:
- a bad commit causing some important functionality or test failures
- due to comparator errors, new code might not be in the build
- any other problem deemed serious enough
The problem may affect only a particular component, so we don't want to completely fail a build. If other components are waiting for a particular bug fix they can still test their bug fix. But end users or developers better avoid switching to such builds.
In this scenario we will mark a build unstable and remove it from the composite update repository so that the unstable build is not available during the update. If a particular user still wants to try an update he can still do it using the build-specific repository listed in the download.
If a user wants to mark a build unstable they need to send a note (along with bug report) to platform-releng-dev@eclipse.org mailing list informing the need to do so. The Platform-releng team will do the needful, i.e. run the markUnstable job.