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? 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
