maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Jenkins and Maven 3.0.5 or JDK 7
Date Sun, 08 Oct 2017 18:27:17 GMT
On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY <herve.boutemy@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?

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.boutemy@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > --
> >
> > Sent from my phone
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message