On Sun, 08 Oct 2017 20:27:17 +0200, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
> On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY <herve.bout...@free.fr>
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 <herve.bout...@free.fr>
>>
>> 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: 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
>>
>> --
>
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
