Hi, Peter,
As the codegen component has two builds, one of which is a continuous integration and the other a true nightly, we might want a parameter in the setup that lets developers decide which they want. For myself, as a tooling-focused person, I wouldn’t need to keep up so aggressively with the codegen. I have found in working on Papyrus that almost every time I run Oomph, it downloads another nightly build, and they aren’t small. It gets to be rather much after a while and requires a lot of bundle-pool garbage collection maintenance. So, does that sound fair? With a parameter in place, dev can opt for the continuous “repo” builds if they need to get going right away on Neon, and switch later if they want to.
cW
On 8 April, 2016 at 10:16:05, Peter Cigéhn (peter.cigehn@xxxxxxxxx) wrote:
Hi again,
I have now tried the
latest patch set 8, and the Mylyn pre-configured queries works. We
are getting there... :)
Next step I tried starting
a runtime workbench, and started testing a bit. But then I bumped
into the same kind of issue I did in my nightly build test
installation. And we once again bump into this confusion about
"nightly builds". I see that you have chosen
the ${base.downloads.url}/papyrus-rt/builds/nightly/ as the
repo for downloading "nightly" builds for the codegen/runtime
parts, instead of ${base.downloads.url}/papyrus-rt/builds/repo/
(which is the one that I would have picked).
I really think that for
consistency the repo-repo shall be used (since the build of that
one is triggered directly by a push to master, in the same way as
the "nightly" builds for the core/profile/tooling parts in the repo
on Hudson).
We really need to settle
this about "nightly builds", i.e. whether they should be a time
trigger built every 24 hours, or if a "nightly build" is built as
soon (within 20 minutes) as new push has been made to the master
branch. Personally I really do not see the need for having to wait
24 hours to get a "nighty build", at least not for developers who
want to be working on the "bleeding edge".
But maybe I am wrong. But
currently we have it very inconsistent where we pick up 20-minute
builds for the core/profile/tooling and 24-hour builds for the
codegen/runtime parts. I really think that we need to be
consistent. And we should at least get one 24-hour build for the
codegen/runtime parts to have succeeded so that we can have a
consistent neon target definition in the runtime workbench.
/Peter Cigéhn
_______________________________________________
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
|