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

[Christian Damus <give.a.damus@xxxxxxxxx>]

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.

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.

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.

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

--

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