I'll see if I can record something On 8 October 2017 at 15:01, Hervé BOUTEMY <[email protected]> wrote:
> I don't really understand these answers: a demo, please > > Regards, > > Hervé > > Le dimanche 8 octobre 2017, 20:32:29 CEST Robert Scholte a écrit : > > On Sun, 08 Oct 2017 20:27:17 +0200, Stephen Connolly > > > > <[email protected]> wrote: > > > On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY <[email protected]> > wrote: > > >> I don't get the technical details > > >> but IIUC, you're able to do a PoC with our available git repositories > of > > >> Jenkins job maintenance (easy job creation + easy Jenkinsfile > > >> maintenance), > > > > > > Job created automatically once there is a git repo with a branch with > a > > > Jenkinsfile . No human interaction required after `echo > > > “mavenProjectStdBuild();” > Jenkinsfile && git add Jenkinsfile && git > > > commit “add Jenkinsfile” && git push` > > > > > > Jenkinsfile being just one line `mavenProjectStdBuild` or something > like > > > that. > > > > > > Is that easy enough? > > > > IIRC there is this proposal to let pom modules support directories, pom > > locations (these are already supported) and SCM references. Might be > > interesting for an aggregator pom. > > > > Robert > > > > > and > > > > > >> you're confident that it can scale to the size we're expecting when > > >> we're > > >> splitting the current aggregator svn to many small git repos > > >> > > >> that's it? > > >> > > >> Regards, > > >> > > >> Hervé > > >> > > >> Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit : > > >> > On Sun 8 Oct 2017 at 03:55, Hervé BOUTEMY <[email protected]> > > >> > > >> wrote: > > >> > > TLDR; = > > >> > > Perhaps we can start with 2 proofs of concept: > > >> > > 1. full git clone + Jenkins jobs for the 7 existing git repos > (with > > >> > > >> 6 > > >> > > >> > > additional ones in 2 days) > > >> > > 2. git split of one of the aggregator svn trunk: skins or > > >> > > >> doxia-tools > > >> can > > >> > > >> > > be > > >> > > easy choices since they are light, where plugins or shared are > > >> > > >> perhaps > > >> too > > >> > > >> > > heavy. The one working on this PoC will make his choice > > >> > > > > >> > > then more detailed answer inline that lead to this PoCs proposal > > >> > > > > >> > > Regards, > > >> > > > > >> > > Hervé > > >> > > > > >> > > Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit : > > >> > > > I don't think the devs would work on all artifacts(projects) a > > >> > > >> time. > > >> > > >> > > sure, I think I'm one of the few people working on near everything > > >> > > >> (with > > >> > > >> > > rare > > >> > > exceptions like Surefire, as you noticed :) ) > > >> > > but for usual contributor, there is no issue > > >> > > > > >> > > I'm not a git expert, then I don't know if easy "full Maven clone" > > >> > > >> is > > >> > > >> > > better > > >> > > done with a shell script or some git modules > > >> > > > > >> > > > If the naming convention of repo for a plugin would be > artifactId, > > >> > > >> like > > >> > > >> > > > /maven-clean-plugin, then even easy to figure out which one to > > >> > > >> clone. > > >> > > >> > > > The most likely the dev would just clone one repo she/he is > > >> > > >> interested > > >> > > >> > > > in > > >> > > > at the moment, i.e. repository /maven-clean-plugin, let's say. > > >> > > > It's good to avoid any shared files across them, even I don't > > >> > > >> think > > >> devs > > >> > > >> > > > share some in svn today. The release process would be quite > usual, > > >> > > >> i.e. > > >> > > >> > > one > > >> > > > > >> > > > repo = one project, and new devs already have these experiences > > >> > > >> which > > >> > > >> > > will > > >> > > > > >> > > > be simple for them to adapt faster. > > >> > > > > >> > > +1 > > >> > > the only drawback I see currently is that there is no natural > > >> > > >> grouping, > > >> > > >> > > then > > >> > > we have a flat lit of near 100 git repos without the current > > >> > > >> structure > > >> > > >> > > (plugins, shared components, skins, ...): I think components > > >> > > >> structure > > >> is > > >> > > >> > > useful for maintenability > > >> > > but not really a complete showstopper > > >> > > and perhaps the "Maven full clone" tooling can re-create some > > >> > > >> grouping > > >> to > > >> > > >> > > keep > > >> > > visible structure > > >> > > > > >> > > Now, someone has to know how to create per-component git repo with > > >> > > >> tags > > >> > > >> > > (either by reworking exiting git mirrors, either by restarting > from > > >> > > >> svn), > > >> > > >> > > and > > >> > > that's not me :) > > >> > > > > >> > > given the volume (adding 70 git repos for Maven), we'll have to > tell > > >> > > >> infra > > >> > > >> > > about it. > > >> > > > > >> > > Then there is the Jenkins jobs configuration: > > >> > > - we need easy Jenkinsfile in each repo > > >> > > > >> > so we create a shared Groovy library like the Jenkins project does > and > > >> > > >> the > > >> > > >> > Jenkinsfile becomes `buildPlugin` for all except core > > >> > > > >> > > - we need easy 80 jobs creation (no, I won't manually create 80 > jobs > > >> > > personally) > > >> > > > >> > So I will add SCMNavigator functionality to the ASF git-Jenkins > plugin > > >> > > >> and > > >> > > >> > we just define an org-folder for Maven and all git repos with a > > >> > > >> Jenkinsfile > > >> > > >> > will be auto-maintained. > > >> > > > >> > > And once again, infra will have to be in the loop (at Jenkins side > > >> > > >> this > > >> > > >> > > time), > > >> > > since I fear the load on Jenkins master node won't be light: > perhaps > > >> > > that's > > >> > > where Jenkins folders will be useful, but I'm not a Jenkins expert > > >> > > >> either. > > >> > > >> > If we use an org folder integrated with GitPubSub I do not think > they > > >> > > >> will > > >> > > >> > be overly concerned > > >> > > > >> > > If everything seems feasible to split our svn code into 1 git repo > > >> > > >> per- > > >> > > >> > > component, which will bring us to "full Maven code" being near 100 > > >> > > >> repos, > > >> > > >> > > I'm > > >> > > ok with it. > > >> > > We'll need the help of misc experts on Jenkins and git to prepare > > >> > > >> things > > >> > > >> > > at > > >> > > this scale. > > >> > > > >> > I think one repo per release root is the way to go. > > >> > > > >> > We should start by drawing up a list and amalgamation where > > >> > > >> appropriate: > > >> > Eg > > >> > > > >> > * does it make sense to release maven-deploy-plugin and > > >> > maven-install-plugin independently? Seems we most often make > mirroring > > >> > changes to both, and perhaps it would be better if we forced that > > >> > > >> model? > > >> > > >> > (Don’t answer in this thread, just pointing out an example) > > >> > > >> --------------------------------------------------------------------- > > >> > > >> > > 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] > > >> > > >> -- > > > > > > 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] > >
