Le samedi 7 octobre 2017, 14:48:32 CEST Tibor Digana a écrit : > In my company I have such situation in SVN. Making a tag from subfolder. > Git always makes the tag from the root, right? it looks like git can tag a subfolder: https://github.com/apache/maven-plugins/tree/maven-war-plugin-3.2.0
this is taken from a svn2git mirror, I don't know how this is feasible with a git command > Let's google something... > > On Sat, Oct 7, 2017 at 2:47 PM, Tibor Digana <[email protected]> > > wrote: > > In my company I have such situation. > > Making a tag from subfolder. > > Git always makes the tag from the root, right? > > Let's google something... > > > > On Sat, Oct 7, 2017 at 2:05 PM, Hervé BOUTEMY <[email protected]> > > > > wrote: > >> thanks for your interest and feedback > >> > >> Le samedi 7 octobre 2017, 12:00:32 CEST Tibor Digana a écrit : > >> > 78 is too much. > >> > >> notice that there would also be a question on the git repos naming > >> convention, > >> to avoid flat 78 names but keep at least 3 meaningful groups (plugins, > >> shared, > >> resources: I think this is not absolutely necessary for doxia-tools) > >> > >> > There is no problem to trigger release over sub-folders and tag it with > >> > prefix which is already done in SVN. > >> > >> is it supported by maven-release plugin with git? > >> > >> notice I did not know that git was able to tag only a subtree: but I knew > >> I > >> don't yet understand every aspect of git magic... :) > >> > >> > 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. > >> > >> +1 > >> but I don't know where to look for myself: on that point, I hope to have > >> some > >> help from Jenkinsfile experts > >> and eventually start with svn, to have something before the git migration > >> > >> > 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. :( > >> > >> notice that we can perhaps split the repos in less parts than we have > >> components: on plugins, for example, we already have 4 categories [1] > >> which > >> would avoid 1 repo with 41 plugins, but more something like 6+10+10+15 > >> I suppose we could do the same for shared (reporting folder comes to my > >> mind) > >> > >> The key feasibility issue is the capacity to release a sub-component from > >> git > >> with maven-release-plugin, IMHO > >> (taking apart the git purists idea of 1 lifecycle = 1 git repo) > >> > >> Regards, > >> > >> Hervé > >> > >> > >> [1] http://maven.apache.org/plugins/ > >> > >> > 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] > >> > > > >> > > 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-Migratinganaggregatortreeintoacollec > >> > >> tionofgitrepos > >> > >> > > 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] > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > > > > -- > > Cheers > > Tibor --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
