Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-releng-dev] ModelReconcilerContributionTest failures in latest Mars and Neon builds

Brian,

I think you are on the wrong track. Those tests fail for me locally with M20160127-1000 and a new workspace. Same with latest I- and M-build.

Dani



From:        Brian de Alwis <briandealwis@xxxxxxxxx>
To:        "Eclipse platform release engineering list." <platform-releng-dev@xxxxxxxxxxx>
Date:        29.01.2016 16:05
Subject:        Re: [platform-releng-dev] ModelReconcilerContributionTest failures        in latest Mars and Neon builds
Sent by:        platform-releng-dev-bounces@xxxxxxxxxxx




The tests pass locally when run within M20160127-1000 (so presumably using the new EMF?).  The tests create temp files with stable names (in java.io.tmpdir, named XMLModelReconcilerContributionTest_XXXX.e4xmiwhere XXX is the test method).  The tests delete these temp files but does not verify that the deletion was successful.

Can you check the temp directory?

I can push up a patch to the tests to ensure the temp files don’t exist.

Brian.

On 29-Jan-2016, at 9:25 AM, David M Williams <david_williams@xxxxxxxxxx> wrote:


> From: "Daniel Megert" <
daniel_megert@xxxxxxxxxx>

>
> To be more concrete:
>
> 19 tests fail in XMLModelReconcilerContributionTest
> 7 tests fail in XMLModelReconcilerScenarioTest
>
> and I can reproduce them locally with I20160128-2000.
>
> The problem is caused in both streams by adopting the new EMF builds.
>
> At the moment I don't have time to investigate whether this is a
> test or an EMF problem. I've filed
https://bugs.eclipse.org/486804.
> If no one takes the bug in a few hours, then I suggest we revert the
> EMF upgrade and investigate the problem for Mars.2 RC3 and Neon M6.


I will do the revert if directed to, of course, but a couple of implications to be aware of:

A. It would probably be Saturday before they were ready.
B. Worse, assuming that EMF contributes their build to "Sim. Release" repo, then EPP packages (and similar) would still be built with those changes, so us reverting doesn't "buy" that much in terms of the overall release deliverables.


If we think they EMF fixes are correct then I think it would be just as valid to assume only our tests are wrong, and there is no impact to "running code".


I myself do not know for sure one way or the other (if EMF is correct or if it is a "test only" problem) -- just saying that "reverting and rebuilding" would only be less risky if we thought EMF fixes were wrong, or knew that tests were correct and that there was an impact to running code (such as the SDK).


(FYI, I will be offline today from about 10 to 12, Eastern, for an appointment, so I would assume it would be "this afternoon" before final decision made and a rebuild started, if that is desired.)


Thanks,




_______________________________________________
platform-releng-dev mailing list

platform-releng-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev
_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev


Back to the top