Jump to: navigation, search

Difference between revisions of "Platform-releng/Releng Plan for CBI adoption"

(Initial document)
 
(Main Criteria for moving to CBI based build for Kepler)
Line 14: Line 14:
 
# Be easy to fit in to current workflow of automated builds and tests of "nightlies", I-builds, milestones (i.e. committers have to know
 
# Be easy to fit in to current workflow of automated builds and tests of "nightlies", I-builds, milestones (i.e. committers have to know
 
what to do to "release" something for a build, how to "freeze" changes at a certain point).
 
what to do to "release" something for a build, how to "freeze" changes at a certain point).
 +
 +
=Bug queries and reference documents=
 +
 +
* Buq query for [https://bugs.eclipse.org/bugs/buglist.cgi?cmdtype=runnamed&namedcmd=OpenCBI&list_id=4380932 open CBI bugs (in platform, releng)].
 +
 +
* Bug query for  [https://bugs.eclipse.org/bugs/buglist.cgi?cmdtype=runnamed&namedcmd=EFCBIOpen&list_id=4380964 open Eclipse Foundation CBI bugs] (all in Eclipse Foundation, CBI)
 +
 +
* See [[Platform-releng/Platform_Build]] for steps to do local builds and tests.

Revision as of 16:56, 10 February 2013

This document is the "plan", and more working notes for moving to CBI-based builds.

Main Criteria for moving to CBI based build for Kepler

  1. Have same output deliverables as current build: zips, repository, etc. (For Equinox and Eclipse)
  2. (Be able to reproduce exact same build, given a tag (or tags) to start the build with.)
  3. Same warnings (and compile errors, if any) as PDE based build.
  4. Be able to run our JUnit tests, with same results, as PDE based build.
  5. Run a binary comparator against the bundles to ensure that they are the same binary content as the regular bundles.
[Not sure how to do this since "qualifier algorithm" is different].
  1. Qualifiers not change (except for branding bundles) if the content has not changed.
  2. All bundles signed.
  3. Final I-build type repository have same content and metata as PDE based build (nothing missing, nothing extra).
  4. Be easy to fit in to current workflow of automated builds and tests of "nightlies", I-builds, milestones (i.e. committers have to know

what to do to "release" something for a build, how to "freeze" changes at a certain point).

Bug queries and reference documents