Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cbi-dev] Criteria for Platform team to use CBI

I'm not the original author of this list ... but I do agree with it, and I
am (re?) posting it here for discussion and documentation.

Kim Moir original proposed this list, and in talking to her as she prepares
to leave and transition responsibilities, I asked if/when/where this list
was ever published? I'd seen it in some e-mail notes (and I know at least
some of you have too) but I could not recall where else it might have been
published, mailing lists? wiki?  She thought it had been, but, could not
find it, so, I just to be sure it is "out there in the open".

This is the current thinking of what the CBI must do to provide (and show)
the same quality build that is currently being produced by the platform

So, apologies if I'm duplicating something, but wanted to be sure to
capture this (before Kim leaves) in case it was not yet published

Discussion welcome. Perhaps some items should be added? amended? clarified?

Thanks, Kim, for providing this starting point.

1) Build the master feature that we use to construct our bundles from the
map files of an existing build, for instance a milestone build.  You can't
compare two builds just from the master branch as the content is fluid.
2) Build the appropriate platform zips for LTS + all products and features
that are submitted to Juno.  This includes Equinox features.
3) No compile errors, same compile warnings as regular build.
4) Run all our JUnit tests. They should have the same results as the
regular platform build.
5) Run a binary comparator against the bundles to ensure that they are the
same binary content as the regular bundles, once all the versions and
qualifiers are the same. There is a p2.mirror Ant task for this purpose.
6) The bundles should have the same major.minor.service.qualifier as the
bundles that result from the regular build.  My understanding is that Tycho
produces bundles with unique versions each build.  This is not acceptable
as it forces the user to spuriously download bundles where the content is
the same.  In an effort to be good Eclipse citizens and reduce our
bandwidth utilization we only push new bundles to our repo when the content
has actually changed.

Back to the top