The maven properties are passed to maven as command-line “-D” arguments, so if we use build parameters in their definition, e.g.
papyrus.kind=${PAPYRUS_KIND}
then it is just a matter of sharing the PAPYRUS_KIND build parameter amongst the jobs (the job when it runs gets this as an environment variable in its shell).
Is there some Hudson plug-in that implements shared build parameters? Or maybe this is supported out of the box?
cW On 9 November, 2016 at 08:52:49, SCHNEKENBURGER Remi 211865 (remi.schnekenburger@xxxxxx) wrote:
+1 for sharing this configuration ;) I do not know which solutions would be possible here. Any ideas?
-------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
 www.eclipse.org/papyrus
It sure would be nice if this configuration could be shared by all of those Hudson jobs.
On 9 November, 2016 at 08:50:33, SCHNEKENBURGER Remi 211865 (remi.schnekenburger@xxxxxx) wrote:
While changing for the master product job, I was also thinking of doing the same for the other master
jobs => if we want to rely on Papyrus Neon.2 incoming updates, we will have to switch to the nightly build, until Neon.2 is released end of December.
Shall I go with these updates? And shall I update also the gerrit jobs?
Regards,
Rémi
-------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
www.eclipse.org/papyrus
Hi team,
I updated the configuration of
https://hudson.eclipse.org/papyrus-rt/job/Papyrus-RT-Master-Product/
to use papyrusnightly. It was indeed papyrusrelease that was used in the configuration.
Regards,
Rémi
-------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
www.eclipse.org/papyrus
Perhaps the Hudson builds are still using "papyrusrelease" variants of their target platforms? The job configurations would have to be changed to use the "papyrusnightly" variants
(there's a system property passsd to maven for that) now that the 0.8 build is complete. The nightly TPs are all lazy.
On November 9, 2016 at 04:27:50, Peter Cigéhn (peter.cigehn@xxxxxxxxx) wrote:
I was planning on verifying a Bugzilla that Christian have fixed, but we seem to have yet another similar issue of "pinning" a version
of something that no longer exist. The latest build of
https://hudson.eclipse.org/papyrus-rt/job/Papyrus-RT-Master-Product/ #222 (that I triggered manually, since build #221 had failed with the mysterious java.io.IOException: Unexpected termination of the channel) now fails with
Could not find "org.eclipse.papyrus.junit.feature.feature.group/2.0.1.201611060311" in the repositories of the current location
Are we missing a "lazy" keyword here as well?
On 8 November 2016 at 13:59, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Indeed. The non-lazy mode is critically important for reproducibility of builds, especially for release builds in which the dependencies are all also releases and so permanently
available. It might also make sense for stable milestone builds, but we don't really do those. At least, not yet.
On November 8, 2016 at 07:55:48, Philip Langer (planger@xxxxxxxxxxxxxxxxx) wrote:
Hi,
the "lazy" keyword is equivalent to version 0.0.0 in the target file, which means that the most current version will be selected at _resolution time_. If the "lazy" keyword is _not_
used, the version will be fixed to a specific version, which is the most current version at the time at which the target file is generated.
The latter is more conservative and fine for release streams, as there won't be any surprises regarding the versions we consume. But we definitely should use the "lazy" keyword
for nightly builds, because otherwise the build may fail in the future, when a specific version is not available anymore. I think, we should also use lazy for integration builds, as we typically want to test the integration with all the latest other plug-ins
within the defined range rather than with a specific version.
On Tue, Nov 8, 2016 at 11:47 AM, SCHNEKENBURGER Remi 211865 <Remi.SCHNEKENBURGER@xxxxxx> wrote:
Hi,
Regarding the “lazy” keyword, in which context should we use it? The usage is quite heterogeneous in
the .tpd files, I would like to understand better the case.
Regards,
Rémi
-------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
www.eclipse.org/papyrus
De :
papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx]
De la part de Philip Langer
Envoyé : mardi 8 novembre 2016 11:11
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Failing builds
Hi Céline,
thanks, your change -- i.e. regenerating the target -- fixes the build. But to ensure that this problem doesn't reoccur, I'd like to suggest to use the lazy keyword for all non-release
update-sites (as mentioned earlier). I applied this keyword in
https://git.eclipse.org/r/84214 for EMF Compare / EGit integration update sites.
Also, I rebased change 84214, but it seems that unrelated tests are failing (org.eclipse.papyrusrt.umlrt.core.tests.creation.CreateElementTest).
On Mon, Nov 7, 2016 at 5:10 PM, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
Thanks Céline. By the way, are you Ok with merging change 84214?
Hi
everyone,
The
Master-Core build is back to normal.
The
regeneration of .target, was the solution.
Regards
Céline
Objet :
Re: [papyrus-rt-dev] Failing builds
Hi Peter,
Céline is currently investigating the patch proposed for these regressions.
Regards,
Rémi
-------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48
48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
www.eclipse.org/papyrus
De :papyrus-rt-dev-bounces@xxxxxxxxxxx
[mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx]
De la part de Peter Cigéhn
Envoyé : lundi 7 novembre 2016 15:06
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : [papyrus-rt-dev] Failing builds
When looking into the logs, this looks related to the discussion about the changing to use the integration
repo of the custom builds of EGit and EMF Compare, which I guess is what is proposed in https://git.eclipse.org/r/#/c/84214/
Could someone who knows more about the builds and why they are failing look into this, and if possible merge
in the proposed Gerrit change (if that is concluded what should fix the failing builds).
_______________________________________________
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
--
Dr. Philip Langer
Senior Software Architect / General Manager
EclipseSource Services GmbH
_______________________________________________
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
--
Dr. Philip Langer
Senior Software Architect / General Manager
EclipseSource Services GmbH
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
|
