Skip to main content

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.

Jump to: navigation, search

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-Builds) built daily at 8:00 PM EST
+
* Integration builds (I-builds) built daily at 8:00 PM ET
* Maintenance builds(M-builds) built at 4:00 AM on every Wednesday EST
+
* 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:
* Bad commit causing some important test failures
+
* a bad commit causing some important functionality or test failures
* Some times due to comparator errors new code might not be in the build.
+
* due to comparator errors, new code might not be in the build
* any other problem
+
* any other problem deemed serious enough
  
In these cases the problem affects only a particular component not every one, so it is not correct to fail a build. If other components are waiting for a particular bug fix they can still test their bug fix. but it is not usable to the end user or regular development.  
+
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 update composite repository so that 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.
+
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.

Back to the top