Eclipse Release Engineering build schedule
Last change of static content: 2015-10-14.
I-builds use branches specified in repositories.txt file, from
master branch of aggregator (eclipse.platform.releng.aggregator). The projects built are submodules of aggregator so normally
there is one line in repositories.txt file for each submodule of the aggregator.
(usually Tuesdays, 08:00 A.M. Eastern Time, EST/EDT, -0400/-0500)
N-builds always use 'master' branch of the repositories built.
(daily 20:00, Eastern Time (except Saturday: 15:00))
M-builds use a branch of the aggregator (and therefore a branch of the repositories.txt file)
and, like I-builds, pull whatever branch is specified in the repositories.txt file.
(usually Wednesdays, 10:00 A.M., Eastern Time)
ICAL Calendar URL
- Nightly builds - No rebuilds
- Integration builds - Same day rebuild if compile errors, missing plugins, the build is unusable or if the drops do not get posted.Otherwise, a rebuild the next day at 8:00am.
- Maintenance builds - Rebuild until success
Build Retention Policy
In an effort to reduce our disk utilization on the eclipse.org infrastructure and reduce the amount of data sent to the mirrors, we have adopted the following build retention policy.
- Release builds are kept indefinitely and moved to the archive.eclipse.org server as appropriate
- Four integration and nightly builds are retained
- Maintenance builds are kept until a release of the maintenance stream is available.
- Stable builds are retained until a release is available.
For the 4.<n> Integration builds:
- build time is 8:00 am (Eastern time) on Tuesday mornings.
- In the event of an integration build failure due to compile errors, missing plugins or if the drops are not posted,
there will be a same day rebuild upon
submission of a fix.
- Otherwise, there will be a rebuild at noon Wednesday morning to accommodate fixes that have a workaround or do not impact the general usability of the build.
- Teams are expected to indicate on the platform-releng-dev mailing list if they intend to contribute to a rebuild.
- In the event of a double integration build failure, all other work will stop until guaranteed-to-be-successful build contributions are prepared for a rebuild at 8:00 am Thursday morning.
- if the Thursday 8:00 am (Eastern time) integration build fails we will rebuild until success
- once a good integration build is achieved, it will be marked as such on the website.
- the Releng team will often request a go/no go status from all teams to determine if the build is suitable for the week's testing. If you provide status and then
recontribute to a subsequent build, you are required to revalidate the build and provide an updated status.
For the 4.<n-1>.x maintenance builds:
- Build time is 8:00 am Wednesday (Eastern time)
- Due to the nature of the fixes in this stream, these builds should not fail. However, if a
rebuild is requested by one of the teams, it will take place as soon as the build contribution is available.
In the above descriptions, a build is considered to be a failure if there are "Red X"s that the developers
agree represent valid reasons for them to not begin using the integration build.
An example of a Red X which would *not* require a re-build would be a test which
failed because the test was bogus.
IMPORTANT: This strategy requires
us to have good build inputs. All teams must use the tools to pre-build and test
their submissions. In addition, teams should track the nightly builds to detect
integration problems early on. What we want to achieve is for the Tuesday morning
4.<n> build to typically be successful, with an infrequent requirement for a
Wednesday noon build. Failing the Wednesday noon rebuild should be treated as a catastrophic
failure. In other words, more than two or three of these per year is an unacceptable