[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-releng-dev] I-Build: I20130423-0800: Comparator logs are back, and should be reviewed
|
What does "no-classifier" mean?
>A. a couple of pom.xml changes ...
presumably not significant? But ... hard for anyone to know, except the
bundle owner?
The builder reports if pom changes are
required and offers patches. I would assume, that if no such report is
generated, then those pom.xml changes are irrelevant and can be ignored
i.e. removed from the report
Regarding Javadoc: a doc bundle does
not know/change if the Javadoc changed. Therefore, one needs to manually
touch a doc bundle, if only Javadoc changed and no file changed inside
that doc bundle. Usually, we only do this near the end of the release,
as it is not that important to have accurate Javadoc with each build.
Filed
bug
406417 with
some suggestions to improve the reports.
Dani
| From:
| David M Williams <david_williams@xxxxxxxxxx>
|
| To:
| "Eclipse platform release engineering
list." <platform-releng-dev@xxxxxxxxxxx>,
|
| Date:
| 23.04.2013 17:52
|
| Subject:
| [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_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev
