Nothing avoids to have a big git repo with many independent projects but yes it will tag everything in the repo (not really a problem). Same thing when we create a branch.
Tibor I did a script similar to yours in the past: https://gist.github.com/aheritier/8824148 (ok it is a bit complex :-) ) I think we can together create such script with our own constraints/parameters On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana <tibordig...@apache.org> wrote: > Herve, > I think making the tag as I wanted would not be possible in git. > > Let's make it with all 78 projects. > In 2016 I migrated my svn project "audit" located in sub-folder behind > trunk (trunk/libs/audit) to git which is exactly what we need to do in ASF. > > In our case the commands would be 99% the same. The 1% is the source SVN > URL and target GitHub URL. That's all. Then if we provide INFRA with bunch > of commands like these then they will only execute them with their > permissions. > I do not think they will give me admin permissions to make it. > > git svn clone --no-metadata --authors-file=E:\*authors.txt* http:// > ***/svn/***/*trunk/libs/audit audit* > git config --global user.name "*** ***" > git config --global user.email "***@***.***" > git remote add origin https://***@github.com/apache/ > *maven-clean-plugin*.git > git push -u origin --all > > I observed the *authors.txt* from command > *svn log -q* > Each person from between first two pipes, e.g.: > r1234567 | tibordigana | 2015-10-19 02:20:00 > > Every developer added e-mail and full name, i.e.: > tibordigana = Tibor Digana <tibordig...@apache.org> > etc. > > This list of users which should be created in prior to contact INFRA. > Not all users are active after years but it would be nice to include them > too. > This list of users is one thing which cannot be automated! > > > > > On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana <tibordig...@apache.org> > wrote: > > > In my company I have such situation in SVN. 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:47 PM, Tibor Digana < > tibor.dig...@googlemail.com> > > 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 <herve.bout...@free.fr> > >> 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 <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-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 < > >>> 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 > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >>> > >> > >> > >> -- > >> Cheers > >> Tibor > >> > > > > > -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
