Re: [papyrus-rt-dev] Build infrastructure wiki questions

[Ernesto Posse <eposse@xxxxxxxxxxxxx>]

Thanks Christian. Some follow up question inline below.

On Thu, Sep 22, 2016 at 8:53 AM Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Hi, Ernesto,

See some replies in-line, below.

HTH,

Christian

On 21 September, 2016 at 17:23:00, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:

Hi. I finally had time to read the description of the build infrastructure at https://wiki.eclipse.org/Papyrus-RT/Developer_Guide/Builds, and I have a few questions:

First an RCP/Product newbie question here: if I wanted to package Papyrus-RT as a zip file to distribute, how would I do it? Are the "rcp" and/or "product" projects supposed to provide this? If not, do we have plans to do this?

Yes, the Papyrus-RT-<Stream>-Product build should package the RCP archive when the time comes to define its make-up.

Ok, so it is currently not doing that?

What is the difference then between the oeprt.product and the oeprt.rcp plugins?

Also, I'm preparing the tutorial for MODELS, which is supposed to be a hands-on tutorial, but using the Oomph setup(s) seems impractical because it takes a certain amount of time, and it crashed whenever a dependency repo is unavailable, so we thought that the best thing would be to package the whole thing in a zip and pass around some USB keys so that people could just unzip it and get the full thing ready to go. Is this something that the RCP will do? How hard is it to make it? I figure that if the packaging is not ready yet, I could just do a couple of installations for Linux, Windows and OS X and zip those, but if the build process can do that, it might be preferable. 

 

Under "Integration Jobs" it says:

* Papyrus-RT-<Stream>-Product-Releases doesn publish and archive

Is that a "doesn't" or a "does"?

That should be “doesn’t”.  I’ll fix the wiki.  The point is that we don’t want to automatically publish a release candidate build to the Eclipse download server until it has been thoroughly tested.  For integration and nightly builds, the bar is much lower.

But is should package it so that publishing and archiving would be easier, right?

 

Under "Target Platforms", should the -Product path be updated to the updates/nighly/<Stream>?

It could, but that would be a trip to download.eclipse.org just to be redirected back to the location listed in the wiki.

Ah, so it doesn't really matter, eh?

 

Under "Triggering", it seems to me that codegen is a bit of a special case, because changes to plugins/xtumlrt/... should trigger a codegen build as well, or is this supposed to be handled by triggering the codegen build from a (not yet existing) xtumlrt build?

At this point, the xtumlrt component is lumped together with codegen.

Well, it is lumped together in the Papyrus-RT-CodegenRTS-BuildFrom-gerrit-Master job, but not in the new Papyrus-RT-Gerrit-Codegen job which only looks at the codegen folders.

 

  To get this new architecture deployed long enough ahead of our release window, it was agreed to continue with a fairly coarse-grained componentization for now. 

So for now at least shouldn't we add the xtumlrt folders to the triggers of the new Papyrus-RT-Gerrit-Codegen job? (as well as the runtime folders)?

 

When there’s a practical motive for splitting out an xtumlrt component, then yes, its build would trigger a downstream codegen build.

I’ll add a section in the wiki to explain the currently reduced componentization.

In fact, shouldn't there be triggering dependencies for the Gerrit jobs according to the components? E.g., shouldn't a gerrit build of "Core" trigger a build of "Tooling", "Codegen", etc?

No, Gerrit jobs can’t really trigger one another.  If the Core build is triggered for some commit A and then this cascades a few levels to other components, then in the mean-time another commit B could trigger a new Core build and the build from commit A will no longer be current.  Besides, we don’t want to incur the cost of archiving the outputs of these builds.

However, each Gerrit build does run all of the tests for its dependents, to verify that the changes don’t break those components.  I suppose we may find that this isn’t sufficient, if our test coverage isn’t good enough.  This also helps to enforce component API boundaries:  there should be no need to rebuild Tooling for a change in Core because that change in Core must maintain the APIs that Tooling depends on.  For the extraordinary cases where we do have to break API, then we’ll have nightly builds that are broken until all components catch up, which shouldn’t take long because the developer will have Gerrits for all components prepared.

If this doesn’t pan out as we hope, then of course we’ll have to re-think the strategy.

I want to make sure I understand, so let's make it a bit more concrete. Suppose that I have a bug that requires modifying some construct in the language, say, a change in the way exclusions are to be specified. This entails changes to the xtumlrt meta-model, possibly the xtext projects and the xtumlrt utilities and APIs and to the code generator. If we have an xtumlrt Gerrit job separate from the codegen Gerrit job, then can I still make all the required updates in one commit rather than splitting the changes in one commit for each component? If everything is done in one commit, both jobs would be triggered (since they listen to their respective folders), but would the codegen job get the xtumlrt updates? Just to be sure, the maven build builds on the full commit checked out from git which will contain all the changes and not just the ones in the folders that are being listened, is that right?

 

Thanks,

--

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 

_______________________________________________
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