I think it is not related to the problem that Christian raised about test failed in the Core gerrit build.
It is indeed related to the the componentized build architecture.
The tests are referring to the old tooling build that fetch the org/eclipse/papyrusrt/umlrt/core/utils/SystemElementsUtils
This class was already removed from the Core plugin, and merged to master in a separate gerrit
My question is : when the tooling tests (that are failed here) are built ? in the Tooling gerrit build ?
Thank you
Asma
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx]
De la part de SMAOUI Asma
Envoyé : vendredi 13 janvier 2017 11:41
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : [PROVENANCE INTERNET] Re: [papyrus-rt-dev] Virtual doughnuts — build post-mortem
Hello,
I got 36 tests failed (diagram.common and tooling.ui test) in Core gerrit :
https://hudson.eclipse.org/papyrus-rt/job/Papyrus-RT-Gerrit-Core/251/
Then, my build is unstable
https://git.eclipse.org/r/#/c/88469/
Are these tests the same tests that failed before ?
Thanks
Asma
Hi, all,
The Master Core build is now green. The tests are all passing again.
It Turns Out™ that the problem was a new order of test execution, somehow induced by my commit of earlier this week ad influenced by the very different ways in which the Target
Platform Definitions of the main and gerrit builds for the Core component reference essentially the same content. This new execution order tripped the initialization of the UMLElementTypes enumerator before the dynamic type registry was initialized and populated
GMF’s Element Type Registry.
I have fixed the problem (for who knows how long) by promoting the application of the ElementTypesRule as high up and as early as I could in the test suites that need the element-types.
I would recommend to the Papyrus Team that all enumerators of static element-types such as the UMLElementTypes class should be regenerated with a new pattern that
-
ensures initialization of the dynamic (modelled) types registry
-
initializes every static element-type as a dynamic proxy fronting the real element type, where
-
the element-type proxy fetches its real element type from the registry on-the-fly to ensure that it always has the latest loaded implementation and
-
in the event that its element-type is unloaded, the proxy delegates to the default (null) element-type for continuity’s sake
because obviously there is value in having these enumerators. This would forever prevent the problems we have been beating down repeatedly like gophers in the carnival game.
😉
On Jan 11, 2017, 07:59 -0500, Christian Damus <give.a.damus@xxxxxxxxx>,
wrote:
Thanks, Rémi,
I’ll try adding a kick of the UMLElementTypes class into the ElementTypesRule to see if that helps. It was because these tests already use that rule to try to evade this problem
that we’ve seen so often, that I was perplexed.
On Jan 11, 2017, 03:39 -0500, Remi Schnekenburger <rschnekenburger@xxxxxxxxxxxxxxxxx>,
wrote:
Hi Christian,
Thanks for the donuts, even virtual ones ;)
I got a quick overview on your issue this morning, and it seems related to the element types coming from UMLElementTypes from uml service types. As soon as the tests are failing,
they seem to be in the neighborhood...
I don't really like that class, and those generated by GMFtooling for each diagram. The registry is dynamic now, with reload/unload of configurations, and those classes are statically
defined. As soon as an element type configuration is loaded, the static reference may be lost. So I would try to ensure that the registry is fully loaded with the UMLElementTypes nicely defined.
2017-01-10 23:54 GMT+01:00 Christian Damus <give.a.damus@xxxxxxxxx>:
Hi, Team,
To approximate an age-old tradition of software development offices, please enjoy a tray of virtual doughnuts with my apologies for today’s spate of broken builds.
As it happens, I got myself stuck in a tough spot in our build system with inter-component dependencies. A
contribution in the Core component that removed an obsolete plug-in bundle org.eclipse.papyrusrt.umlrt.core.sync passed Hudson Gerrit build validation and was merged, but this broke the Tooling
component build which still thought it needed that bundle. There was already a
gerrit patch waiting in the wings that would update the Tooling component to remove the dependency on this bundle, but now it could not build because the Gerrit builds are based on the full Product build, which could never successfully build because the
Tooling build was broken. So, there was no way to get an updated Product build that provided what the Tooling Gerrit build needs while the main Tooling build was broken, but of course the usual Gerrit process could not push fixes to the Tooling component
without the Gerrit build. This was all further complicated by the fact that the main Core build is based on the last successful Product build because the Core Tests need the Tooling component (some of the tests run in diagram editors).
So, long story short, I should have anticipated this problem and only deleted the obsolete sync plug-in as a final step, after all other changes to all components were merged,
and I had to by-pass Gerrit to push my updates including temporarily reinstating the sync plug-in, to get the builds working again.
There are still test failures in the main Core build that I don’t understand: they look like kind of failures usually caused by the Element Types Registry not being populated,
but that can’t be the cause here because the tests employ the ElementTypesRule. Moreover, the Core Gerrit build job doesn’t manifest these test failures. I shall continue to investigate this, tomorrow. Any ideas about the nature of this problem will be
most welcome. 🤕
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
--
Remi Schnekenburger
Senior Software Architect / General Manager
EclipseSource Paris
Email: rschnekenburger@xxxxxxxxxxxxxxxxx
Web:
http://eclipsesource.com/paris
Mobil: +49 89 21 555 30 - 25
Phone: +49 89 21 555 30 - 25
Fax: +49 89 21 555 30 - 19
EclipseSource France SAS
7 rue de la Croix Martre
91873 Palaiseau
General Manager: Remi Schnekenburger
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|
