Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Virtual doughnuts — build post-mortem
Hi, Ernesto,

Yes, the nuance that I didn’t account for in my split and ordering of commits was that, although my commit in the Core component that removed the sync bundle built fine and passed all the tests, this was only because the Core component’s target platform includes the previous Core component build.  So, the target platform supplied the bundle that I had deleted.

I think that this is a mistake in the Core component’s target platform selection.  The build is configured to select the “releng” TP for the Core build, which is intended primarily for the Product build to get all the Papyrus-RT bits that it needs to assemble into the repo and RCP.  This TP is selected because the Core tests run in the diagrams, and so need the Tooling Component.

Therefore, I have further recommendations to make 😉:

  1. first, that we change the “core” TP to include the latest tooling build, in order to satisfy the test requirement, and then remove the “target.kind=releng” property from the Core build config in Hudson so that it will use its proper TP
  2. next, that we work on removing the dependency on the diagrams (and any other Tooling dependency) in the Core tests.  This involves a lot of re-writing of existing test cases
  3. then, we can remove the Tooling component from the Core TP that we added in step 1

cW

On Jan 11, 2017, 12:04 -0500, Ernesto Posse <eposse@xxxxxxxxxxxxx>, wrote:
Thanks for the doughnuts!

A (possibly dumb) question for future reference: is the lesson here that, in the general case, whenever we remove a bundle, we need to first make sure that no other components depend on that bundle, and removing the downstream dependencies on that bundle before merging the change that removes the bundle?

--
Ernesto



On Wed, Jan 11, 2017 at 7:59 AM 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.

cW

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. 

HTH
Cheers...
Rémi


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.


                       Image by joefoodie licensed under Creative Commons CC BY 2.0.


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.  🤕

Cheers,

Christian 

_______________________________________________
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
_______________________________________________
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
--
Ernesto Posse
Zeligsoft
_______________________________________________
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

Back to the top