78 is too much. There is no problem to trigger release over sub-folders and tag it with prefix which is already done in SVN. The CI build can always trigger the root and Jenkinsfile would have 41 stages for plugins, 26 stages for Shared, etc. It can be done in Jenkinsfile and so the shell would not throw exception but status would be set instead and goes to the next stage. I do not know how to detect in GitSCM which sub-folder(s) received but I guess this can be investigated. Then it can be a kind of switch-case over committed folders in Jenkinsfile. This means that every time another stage/sub-folder is shown in Pipeline which will be messy in the UI. :(
On Sat, Oct 7, 2017 at 4:17 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > There are 6 svn locations without any special complexity that are waiting > for > a volunteer for git migration for a few years but nobody does anything > about: > I started 3 days ago to ask for help about it and got pretty no feedback > [1] > > then there are the 4 complex svn locations (plugins, shared, resources, > doxia- > tools) that require much more work: I suppose we can't tell git migration > is > abandoned, but it will require someone to work on it seriously > Remember that the key question [2] is: do we transform these 4 svn > locations > into 41 +26 + 6 + 5 = 78 independent git repos? > Yes, I told that Jenkins configuration is one key aspect we need a strategy > about, in parallel with git strategy. > > then there will be the remaining cases where we need to decide: lower > impact, > lower priority. > > > Summary: nothing is abandoned, but: > - simple cases: no volunteer to do the job > - hard cases: is there a volunteer either to define a strategy or do some > work > on it? > > > Regards, > > Hervé > > [1] https://lists.apache.org/thread.html/ > edf3642a7bdd515f0cad421c25589741819446463614bf0515e56dbe@ > %3Cdev.maven.apache.org%3E > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git > +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos > > Le vendredi 6 octobre 2017, 20:35:45 CEST Arnaud Héritier a écrit : > > But did we completely abandoned the idea of moving everything to git ? > > The CI setup was the main stop for it ? > > > > On Fri, Oct 6, 2017 at 8:05 PM, Hervé BOUTEMY <herve.bout...@free.fr> > wrote: > > > I was expecting the usual litany > > > > > > what I'm not confident currently with pipeline on Maven core is that we > > > have > > > for example the "maven-3.x-jenkinsfile/MNG-6242 - build #1 - null" > > > message, > > > with this "null" part that makes me wonder if we are using it as > expected. > > > > > > And for large multi-module svn trunks (the ones we don't migrate to > git: > > > mainly plugins and shared), is there a solution to rebuild just changed > > > modules? > > > > > > ideally, the rebuild when a SNAPSHOT dependency is published would have > > > been a > > > plus, but this is sufficiently a rare use that I won't be extremist > > > > > > > > > Then IIUC, this migration job is one additional TODO for me... > > > > > > Regards, > > > > > > Hervé > > > > > > Le vendredi 6 octobre 2017, 17:46:53 CEST Arnaud Héritier a écrit : > > > > I agree that we should use pipeline nowdays > > > > perhaps a shared lib if we want to standardize some stuffs and a set > of > > > > multi-branches jobs (or org folder but it requires GitHub :( ) > > > > > > > > On Fri, Oct 6, 2017 at 9:16 AM, Stephen Connolly < > > > > > > > > stephen.alan.conno...@gmail.com> wrote: > > > > > On Fri 6 Oct 2017 at 06:32, Hervé BOUTEMY <herve.bout...@free.fr> > > > > > > wrote: > > > > > > I just fixed a few failing jobs [1] to have again a usable > Jenkins. > > > > > > > > > > > > Now I'm facing some issues, I suppose caused by newer Jenkins > > > > > > versions: > > > > > > - Maven 3.0.5 causes NoSuchMethodError: o.c.plexus.util.xml.pull. > > > > > > > > > > MXParser > > > > > > > > > > > [2] > > > > > > - I had to switch to JDK 8 for maven-plugin-tools job, since JDK > > > > > > causes > > > > > > > > > failures (looks like Jenkins uses a hack to inject JDK 7 as a > tool > > > > > > while > > > > > > > > > the > > > > > > build JVM is Java 8) > > > > > > > > > > > > Should we drop Maven 3.0.5 builds and JDK 7? > > > > > > Notice I didn't check which is the minimum Maven version > required... > > > > > > > > > > > > Or perhaps simply don't use the Jenkins Maven plugin with this > Maven > > > > > > > > > > 3.0.5 > > > > > > > > > > > or > > > > > > JDK 7 configuration: default build as Jenkins Maven plugin with > JDK > > > > > > 8 + > > > > > > > > > latest > > > > > > Maven, and other configurations as scripted jobs? > > > > > > > > > > http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-> > > > > > > > type-considered-evil.html > > > > > > > > <http://javaadventure.blogspot.ie/2013/11/jenkins-> > > > > > > > maven-job-type-considered-evil.html?m=1> > > > > > > > > We should stop using the evil job type as it’s minimum Java > version is > > > > > dictated by Jenkins’ Java minimum. > > > > > > > > > > > We need to define our common strategy and have a consistent > > > > > > configuration > > > > > > for > > > > > > every job understood by everybody > > > > > > > > > > I recommend Jenkinsfile and the `withMaven` wrapper > > > > > > > > > > > Regards, > > > > > > > > > > > > Hervé > > > > > > > > > > > > [1] https://builds.apache.org/view/M-R/view/Maven/ > > > > > > > > > > > > [2] > > > > > > https://builds.apache.org/view/M-R/view/Maven/job/maven-> > > > > > > > > > > > plugin-tools-jdk-1.7/162/console > > > > > > > > > > > ------------------------------------------------------------ > > > > > > --------- > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > -- > > > > > > > > > > Sent from my phone > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
