[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[platform-releng-dev] I-Build: I20130423-0800: Comparator logs are back, and should be reviewed
|
Comparator logs are back, and should be
reviewed
Long note ... but, an important one.
Bookmark for reference :)
There are now several types of "comparator
logs" we produced.
Eventually, we may have a "releng
test" that will fail if certain ones of them contains content/errors,
but, for now, I'd
like committers and project leads to
review them, and make sure they "look right". In some cases,
we will
have to manually "touch" a
bundle, and rebuild, if a comparator log indicates we are missing new content,
and picking up old content instead .... just like the old days.
In all cases, (for Kepler) the reference
repo is .../eclipse/updates/4.3-I-builds
You can see the logs as soon as a build
is ready (don't have to wait for unit tests to finish). They are
on the "buildlogs" page, such
as for today,
http://download.eclipse.org/eclipse/downloads/drops4/I20130423-0800/buildlogs.php
Here is the full list (I'll describe
each, below).
buildtimeComparatorDocBundle.log
buildtimeComparatorFull.log
buildtimeComparatorSignatureOnly.log
buildtimeComparatorUnanticipated.log
postbuild-comparatorlog.txt
postbuild-mirrorlog.txt
There is one set that start with "buildtime".
These are (currently) parsed from the huge "debug" version of
the
mb060_run-maven-build_output.txt file.
These come from the custom (cbi) "plugin versioner" (basically)
and will make
use of an "old" bundle, if
the version/qualifier is the same as currently computed version/qualifier.
Very similar in concept to the "p2.mirror"
comparator task we used to use, except its "during the build",
instead of after the build.
There are 4 "buildtime" comparator
logs, one of them (buildtimeComparatorFull.log) should just be
the "sum" of the other three,
and I include it only to confirm my "parsing" code is working
correctly.
(Long term, may stop publishing it,
if all seems well with the "main" three.)
buildtimeComparatorDocBundle.log
For "doc bundles" I put issues
in a separate file. The reason is, the doc bundles contents change nearly
every build, I think due to
the way Java doc is produced, with slightly
varying dates/links, or something. In the past, we did not worry about
updating
the qualifier until very near a milestone
or release ... when it was most important the content be exactly correct.
So, is likely not unusual for us to
be picking up "old" content ... but ... those in charge of the
docs will need to
say if/when a rebuild is required.
buildtimeComparatorSignatureOnly.log
The bundles listed in "signatureOnly"
logs are where I use a heuristic to decide the bundles differ only by their
"signature data".
The Eclipse signing process causes a
change every build (since TSA is used) and normally,
we never worry about updating a qualifier,
just because
the "signature data" changed
... they should all be perfectly valid signatures.
buildtimeComparatorUnanticipated.log
Unanticipated. This is the key one to
look at, and would be the reason to do a rebuild, if it contains some content.
But, especially for now, I'll need project
leads to review and say if its accurate that "something changed"
and the
old content is incorrect for current
build, and the bundle needs to be manually "touched", and a rebuild
requested.
Or, please open a bug if the report
contains things that are not unanticipated and would never be a reason
to rebuild .. such as POM changes?
In today's build, for example,
A. a couple of pom.xml changes ... presumably
not significant? But ... hard for anyone to know, except the bundle owner?
B. SWT Tests seems to have substantially
different content. Is a "touch" and rebuild required for that?
C. There are some "feature.xml"
changes? These are probably significant, (I have not looked yet),
and _may_ be that old one refers to
old ICU4J 50.1.0 and new one refers to new one 50.1.1?
D. Some are listed, apparently, because
"source bundles" are missing from packaging and repo. (Bug 405911)
The second type of comparator log are
"postbuild" comparator logs, that I generate using the old way,
with p2.mirror
and its comparator function. They are
"post build" since they are done as I create the packages and
to upload to downloads server. Literally after the build.
The main reason I did this was to confirm
the CBI comparator was working as expected.
If it is working as expected, these
comparator logs should have no content, as any differences should have
already been
accounted for. Plus, I was under the
impression that in some cases, the CBI comparator would not catch certain
cases,
but ... seeing the results, not sure
that's true. (Bug 402448
) I think maybe the new comparator
catches them ... just doesn't
increment qualifier.
postbuild-comparatorlog.txt
This is the actual comparator log like
we used to have. If it has content, that indicates we (probably) do need
a rebuild,
and might indicate "holes"
in the CBI comparator ... such as if a third party bundle in a feature
changes.
The one from today indicates some "bad
bundles" in org.eclipse.osgi.tests
... but, that might be part of the tests.
(If so, open a bug and eventually I'll
fix parser to ignore them).
postbuild-mirrorlog.txt
This is simply the "mirror log"
... nothing to do with "comparator" ... but ... looks like its
capturing some important
information about some things missing.
(May partially be bug Bug 394216
? But, I think some other things
too, related to rcp.config?
If questions, please ask ... or if problems/suggestions
about the contents of the logs, please open a bug.
From:
e4Builder@xxxxxxxxxxx
To:
platform-releng-dev@xxxxxxxxxxx,
Date:
04/23/2013 11:00 AM
Subject:
[platform-releng-dev]
4.3.0 I-Build: I20130423-0800
Sent by:
platform-releng-dev-bounces@xxxxxxxxxxx
Eclipse downloads: http://download.eclipse.org/eclipse/downloads/drops4/I20130423-0800/
Software site repository: http://download.eclipse.org/eclipse/updates/4.3-I-builds
Equinox downloads: http://download.eclipse.org/equinox/drops/I20130423-0800_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev
