Hi,
It seems everything is back on track with build #224. The speed the Hudson job can access to the nightly builds for Papyrus may have an impact here. #223 did
fetch a lot of things, when #224 did less stuff to be accomplished. The nightly build from Papyrus probably did not evolved between the 2 builds.
We access the Hudson papyrus folder using https, maybe the same trick as using the local path in the TP could be useful here.
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é : mercredi 9 novembre 2016 15:56
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Failing builds
I saw that the Master-Product build was aborted after 45 minutes. When looking in the log it looks like it got aborted in exactly the same place as earlier (when we had a 30 minute limit).
[INFO] Installing product org.eclipse.papyrusrt.rcp.product for environment macosx/cocoa/x86_64 to /jobs/genie.papyrus-rt/Papyrus-RT-Master-Product/workspace/source/releng/rcp/org.eclipse.papyrusrt.rcp.product/target/products/org.eclipse.papyrusrt.rcp.product/macosx/cocoa/x86_64/Papyrus-RT.app
Build timed out (after 45 minutes). Marking the build as aborted.
It looks like something gets stuck during the installation for macOS, disregarding that we increased the timeout with 15 minutes.
On 9 November 2016 at 15:12, SCHNEKENBURGER Remi 211865 <Remi.SCHNEKENBURGER@xxxxxx> wrote:
While running the jobs update, I discovered some old ones, like the ones for Mars. I think it is time
for a bit of cleaning, and these following ones are good candidates:
I will probably delete them beginning of next week, until someone needs to keep them alive. Some of
them never ran, and I am probably sure no build on Mars is required anymore.
Regards,
Rémi
Almost all recent jobs have been updated. I did not know however for this job:
https://hudson.eclipse.org/papyrus-rt/job/Papyrus-RT-Nexus-Deploy/configure
This one is failing, but it does not have the parameter for the maven invocation. I will add it and
check everything runs fine.
Regards,
Rémi
+1 for sharing this configuration ;) I do not know which solutions would be possible here. Any ideas?
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
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
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
|