-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intermittent Y-build failures due to baseline replacement #2793
Comments
@stephan-herrmann with #2800 this should now be fixed. The next Y-build should confirm this if there are no comparator-errors. Btw. are you aware of the existing comparator-errors between the I-build repo?
This means that we will probably have these errors in the I-build if the new ECJ version is merged into master. But maybe the change in generated byte-code is intended. Just wanted to make you aware. :) |
Thanks for the heads-up. Initial analysis indicates the change should be legit, but I asked for confirmation via eclipse-jdt/eclipse.jdt.core#3649 |
As reported in #2791 (comment) and already noticed before the Y-build fails occasionally with failures similar to
after baseline replacement detected changes without a qualifier change:
A similar report was #2660 and looking at #2660 (comment) the reason could indeed be that the Y-build uses the I-build as baseline for the p2-baseline-replacement:
eclipse.platform.releng.aggregator/eclipse-platform-parent/pom.xml
Line 85 in c077b24
If then there is no change on the
BETA_JAVAX
branch between the latest I-build and the next Y-build then the scenario could happen as the baseline contains more recent artifacts than the reactor (qualifier-wise).I have to investigate it again, but if that's really the cause a solution would be to baseline Y-builds against the latest Y-build repo by specifying
-Dcomparator.repo=https://download.eclipse.org/eclipse/updates/4.35-Y-builds/
.This would hopefully also resolve the comparator-errors that are currently found on all (otherwise successful) Y-builds.
Another reason might be that there is a problem in considering time-zones during baseline replace or when computing aggregated qualifiers for features. The former seems to be a much better explanation of the problem, but IIRC I have also seen problems that seem to be connected to the latter (i.e. baseline-replacements failing shortly after I-builds), but this was already some time ago, so could be a red herring.
The text was updated successfully, but these errors were encountered: