As Olivier mentioned, that GitBox plugin plus some relatively simple pipelines would make it fairly simple to make every Commons component easily buildable in Jenkins just like how Maven set up their projects. Well, hopefully a little more optimized since their setup occasionally figures out how to spawn off a zillion builds, but that might be more so due to builds triggering downstream dependent builds and such.
The pipeline templates plugin is something installable in the new ci-builds.apache.org environment which could be used to further reduce the boilerplate of pipelines by creating a template pipeline which the various Commons components can all specify parameters to (similar to the parent pom). On Thu, 23 Jul 2020 at 08:01, Gilles Sadowski <gillese...@gmail.com> wrote: > > Hello. > > Le jeu. 23 juil. 2020 à 13:21, Olivier Lamy <ol...@apache.org> a écrit : > > > > On Thu, 23 Jul 2020 at 20:57, Gilles Sadowski <gillese...@gmail.com> wrote: > > > > > Hi. > > > > > > 2020-07-23 12:38 UTC+02:00, Olivier Lamy <ol...@apache.org>: > > > > Hi > > > > As you know the current Jenkins infra is migrating to another CI server. > > > > The current commons-* builds in the old Jenkins infra have been created > > > > manually and this will be a pain to transfer to the new one and to keep > > > > maintaining manually. > > > > In the Maven project we have plenty of maven-* git repo so we have > > > created > > > > a dedicated Jenkins plugin (which is used by other TLP such netbeans) > > > which > > > > scan the gitbox server to get repo based on regular expression or name > > > > content and create the build reusing the same build file. > > > > And this is done without duplicating the build configuration for every > > > > single git repository.... It's done once and updated for all repos when > > > > this configuration change (no need to touch manually every single git > > > > repository) > > > > Each git repo contains a simple Jenkinsfile saying which jdks to use in > > > > case the component has different needs. > > > > I'm happy to help to duplicate similar configuration for commons. > > > > Just let me know. > > > > > > +1 > > > > > > How does it work with projects having several Jenkins builds > > > (e.g. one for running SonarQube)? > > > > > > > can be a parameter as well. > > look at this file > > https://github.com/apache/maven-site-plugin/blob/master/Jenkinsfile > > Wow, it's rather terse: Configuration could hardly seem simpler. :-) > If it just works (TM) for all Commons components, we could (should > IMO) make this a required CI system (as a PMC decision to ensure > a yet to be reached consensus about what is required from a commit > to the "master" branch), letting of course anyone willing to handle > additional CI systems for building GH PRs. > > > we can imagine having a parameter sonarQube: true/false (default might be > > false) > > Fine. > > Thanks, > Gilles > > > > > cheers > > > > Olivier > > > > > > > > On Thu, 23 Jul 2020 at 16:39, Stefan Bodewig <bode...@apache.org> wrote: > > > > > > > >> On 2020-07-23, Stefan Bodewig wrote: > > > >> > > > >> > My preference would be for using less of github rather than more. But > > > >> > I'm probably alone with that. > > > >> > > > >> Of course I'm not. Sorry Gilles. :-) > > > >> > > > >> Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
