On Sat, Oct 7, 2017 at 4:17 AM, Hervé BOUTEMY <[email protected]> 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] > I completely missed this email. Sorry > > 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 > yes > 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. > yes I remember that it was a part of the problem. We have to define the granularity of new repos and then recreate all CI jobs We can always with git use submodules or subtrees to have independent repos (for plugins for exemple) but with a common reactor pom to build all of them. Nowadays using the Maven Job is creating a lot of issues and for sure I cannot advice to use it. Like you saw the recent upgrade of Jenkins core avoids to use a JDK < 8 with these jobs :( In the Jenkins community we have hundred of plugins (repositories [3]) in independent repositories and all of them are build automatically [4] and the CI configuration is simplified [5] [3] https://github.com/jenkinsci [4] https://ci.jenkins.io/job/Plugins/ [5] https://github.com/jenkins-infra/pipeline-library I don't say it is perfect but it is technically possible I did such migration many many years ago, thus I can probably help if we define all together what we want to do ... > > 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 <[email protected]> > 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 < > > > > > > > > [email protected]> wrote: > > > > > On Fri 6 Oct 2017 at 06:32, Hervé BOUTEMY <[email protected]> > > > > > > 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: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > -- > > > > > > > > > > Sent from my phone > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
