Hi Robert Yes absolutely, that sounds great!
Thanks for your prompt replies. Regards Julian On Wed, Nov 9, 2016 at 9:16 PM, Robert Munteanu <romb...@apache.org> wrote: > On Wed, 2016-11-09 at 20:49 +0100, Julian Sedding wrote: >> Hi Robert >> >> Thanks for the hints. >> >> I was wondering if it is possible to trigger a build of each module >> at >> least once every 24h? Even if there are no changes in the module. >> >> Writing a Jenkins trigger, extracting dependencies from PaxExam tests >> does not sound trivial. And that may be only one case of many. > > Pax-Exam is one, provisioning model is another. > > I would propose the following: > > 1. for jobs that we know have 'hidden' depedendencies to SNAPSHOT > versions, either through pax-exam or the provisioning model, we add a > new property in tooling/jenkins/create_jobs.groovy [1], something like > 'rebuildNightly' > > 2. for those jobs we enable a time-based trigger with the value 'H H * > * *' , which according to Jenkins docs is a value that is random across > jobs, but remains fixed for a certain job. > > So for instance sling-bundles-api-1.7 would run at 11:41:48 AM UTC, > while sling-bundles-api-1.8 woudl run at 1:10:48 PM UTC > > Would that work for you? > > Robert > > [1]: https://svn.apache.org/repos/asf/sling/trunk/tooling/jenkins/creat > e_jobs.groovy > >> >> Regards >> Julian >> >> >> On Wed, Nov 9, 2016 at 5:10 PM, Robert Munteanu <romb...@apache.org> >> wrote: >> > Hi Julian, >> > >> > On Tue, 2016-11-08 at 22:29 +0100, Julian Sedding wrote: >> > > Hi Robert >> > > >> > > I think the test failures in oak-server did not come up because >> > > of >> > > the >> > > modularised jenkins jobs we have now. >> > > >> > > The bundle's build seems to have run last after changes were >> > > applied >> > > to it. However, a referenced SNAPSHOT dependency has evolved >> > > since >> > > and >> > > made the tests fail. >> > > >> > > Any ideas how to catch this earlier? >> > >> > I've added some hints about this at [1] and [2]. >> > >> > Basically the issue is that Jenkins does not know about inter-job >> > dependencies based on Pax-Exam code. The way to automate it would >> > be to >> > write a new Jenkins Trigger and deploy it on builds.apache.org . >> > >> > Robert >> > >> > [1]: https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkin >> > s+Se >> > tup#SlingJenkinsSetup-Managinginter-jobdependencies >> > [2]: https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkin >> > s+Se >> > tup#SlingJenkinsSetup-Pax-ExamtestswithSNAPSHOTdependencies >> > >> > >> > > >> > > Regards >> > > Julian >> > > >> > > PS: I have filed SLING-6260 for the failing oak-server ITs and >> > > committed a fix. >> > > >> > > On Tue, Nov 8, 2016 at 10:07 PM, Robert Munteanu <rombert@apache. >> > > org> >> > > wrote: >> > > > Hi Alex. >> > > > >> > > > On Tue, 2016-11-08 at 20:01 +0000, Alexander Klimetschek wrote: >> > > > > I have some trouble building Sling (all of it, it's been a >> > > > > while >> > > > > since I tried that :) >> > > > > >> > > > > 1. It seems the Sling build requires Java 1.8 ("Apache Sling >> > > > > Testing >> > > > > PaxExam" project failed with not all bundles loaded when I >> > > > > ran it >> > > > > with a 1.7 JDK). A check/hint at the start of the build would >> > > > > be >> > > > > great. >> > > > >> > > > Yes, some projects, mostly related to testing, pull in a >> > > > launchpad >> > > > version which requires Java 8. I'm not sure that the best fix >> > > > is >> > > > here. >> > > > >> > > > We could move all of them to a Java 8 profile, which might not >> > > > be >> > > > OK >> > > > because you're missing projects without noticing. Or we could >> > > > fail >> > > > the >> > > > reactor build altogether, which again is tricky since you might >> > > > want to >> > > > build a subset of the reactor using mvn -pl ... . >> > > > >> > > > > >> > > > > 2. Then I get one project further to "Apache Sling JCR Oak >> > > > > Repository >> > > > > Server" which fails as well during the test with not all >> > > > > bundles >> > > > > loaded issues: >> > > > > >> > > > > Tests in error: >> > > > > >> > > > > LoginAdminBlacklistedIT.org.apache.sling.jcr.oak.server.it.Lo >> > > > > ginA >> > > > > dmin >> > > > > BlacklistedIT » TestContainer >> > > > > >> > > > > LoginAdminWhitelistedIT.org.apache.sling.jcr.oak.server.it.Lo >> > > > > ginA >> > > > > dmin >> > > > > WhitelistedIT » TestContainer >> > > > > OakServerIT.org.apache.sling.jcr.oak.server.it.OakServerIT >> > > > > » >> > > > > TestContainer The… >> > > > > >> > > > > I see this in the log: >> > > > > >> > > > > org.osgi.framework.BundleException: Unable to resolve >> > > > > org.apache.sling.jcr.repoinit [79](R 79.0): missing >> > > > > requirement >> > > > > [org.apache.sling.jcr.repoinit [79](R 79.0)] >> > > > > osgi.wiring.package; >> > > > > (&(osgi.wiring.package=org.apache.sling.repoinit.parser.opera >> > > > > tion >> > > > > s)(v >> > > > > ersion>=3.0.0)(!(version>=4.0.0))) Unresolved requirements: >> > > > > [[org.apache.sling.jcr.repoinit [79](R 79.0)] >> > > > > osgi.wiring.package; >> > > > > (&(osgi.wiring.package=org.apache.sling.repoinit.parser.opera >> > > > > tion >> > > > > s)(v >> > > > > ersion>=3.0.0)(!(version>=4.0.0)))] >> > > > > at >> > > > > org.apache.felix.framework.Felix.resolveBundleRevision(Felix. >> > > > > java >> > > > > :411 >> > > > > 1) >> > > > > at >> > > > > org.apache.felix.framework.Felix.startBundle(Felix.java:2117) >> > > > > at >> > > > > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.ja >> > > > > va:1 >> > > > > 371) >> > > > > at >> > > > > org.apache.felix.framework.FrameworkStartLevelImpl.run(Framew >> > > > > orkS >> > > > > tart >> > > > > LevelImpl.java:308) >> > > > > at java.lang.Thread.run(Thread.java:745) >> > > > >> > > > ( I guess Julian already fixed it ) >> > > > >> > > > > >> > > > > >> > > > > 3. Still A LOT of projects to go in the build, so I am now >> > > > > going >> > > > > to >> > > > > skip the tests :( >> > > > >> > > > We still have some flaky tests, see the dedicated Jenkins view >> > > > at >> > > > >> > > > https://builds.apache.org/view/S-Z/view/Sling-Dashboard/ >> > > > >> > > > So you might still experience failures. >> > > > >> > > > FWIW, all SNAPSHOTs are deployed to repository.apache.org, so >> > > > you >> > > > should not need to build all of Sling - it's fine to build >> > > > individual >> > > > projects. >> > > > >> > > > Unless your goal is to build all of Sling, which is of course >> > > > fine >> > > > :-) >> > > > >> > > > Thanks, >> > > > >> > > > Robert >
