Re: Migration of remaining plugins to Git

So the alternate strategy (to what I tested 11 hrs ago) would be to change the release plugin so that it can do its work on a sub-directory safely. cd cd maven-changes-plugin mvn release:prepare mvn release:perform We note after the event that the release was* tagged in SCM with

Re: Migration of remaining plugins to Git

OK, I tried something new. *Goal*: all the plugins in one Git repo (less CI jobs to set up - just one recursive multi-module maven build). *Constraint*: Plugins must be independently releasable. *Test:* Take two modules from the Svn repo and check them in to master (the rest were deleted - test

Re: Migration of remaining plugins to Git

Using JobDSL is effectively another approach It's main avantage is to easily keep the control at Jenkins Admin level of what is done instead of delegating it to projects developers On Sat, Jun 24, 2017 at 8:44 AM, Hervé BOUTEMY wrote: > I was thinking at something like

Re: Migration of remaining plugins to Git

I was thinking at something like the Maven Jenkins Seeding experiment [1] that was done, with its DSL code [2] IIUC, this new Jenkins feature could provide a more generic seeding? Looks promising. Whether we go with first or second option will be a matter of ETA and people wanting to work on

Re: Migration of remaining plugins to Git

+1 for me On Wed, Jun 21, 2017 at 12:02 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Tue 20 Jun 2017 at 20:29, Arnaud Héritier wrote: > > > Stephen knows more the ASF infra than me to tell if it is possible but in > > Jenkins we have the notion of

Re: Migration of remaining plugins to Git

On Tue 20 Jun 2017 at 20:29, Arnaud Héritier wrote: > Stephen knows more the ASF infra than me to tell if it is possible but in > Jenkins we have the notion of organization folder for GitHub which allow to > automatically browse an org in GitHub and create/update/delete >

Re: Migration of remaining plugins to Git

Stephen knows more the ASF infra than me to tell if it is possible but in Jenkins we have the notion of organization folder for GitHub which allow to automatically browse an org in GitHub and create/update/delete multibranches jobs for each repo. If we can also create shared libraries in Jenkins

Re: Migration of remaining plugins to Git

as explained in the git migration status [1], the biggest issue with plugins 1 svn repo to 41 git repo migration is the maintenance of Jenkins job files, with their java + maven version matrix. With Jenkinsfile as worked out in Mavne core, same type of configuration could help us to change our

Re: Migration of remaining plugins to Git

I think the plugins are descoped for a while. How about https://github.com/apache-maven/ ? Luckily GitHub does 302s just find if things get renamed or moved between orgs. - Paul On Mon, Jun 19, 2017 at 3:34 PM, Bindul Bhowmik wrote: > Paul, > > On Mon, Jun 19, 2017

Re: Migration of remaining plugins to Git

Paul, On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant wrote: > Back from Github's suggestions team: "Currently, we don't have the ability > to group repos beyond the organization level, but I'll definitely consider > this a feature request." Until such time, how about grouping

Re: Migration of remaining plugins to Git

Back from Github's suggestions team: "Currently, we don't have the ability to group repos beyond the organization level, but I'll definitely consider this a feature request." - Paul On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant wrote: > I met Chris Wanstrath at a meetup in

Re: Migration of remaining plugins to Git

I met Chris Wanstrath at a meetup in Cincinatti about four years ago, and bent his ear about how fantastic Github-Pages (and Jekyll) was as a CMS. I suggested that if they could add themes for "high school", "community group", etc they could pull in another category of user of the platform, and

Re: Migration of remaining plugins to Git

Polite, yes, just non commital ;-) On Sun 18 Jun 2017 at 23:10, Paul Hammant wrote: > They're always very polite for things that I ask for, but I can't claim to > have suggested anything that got implemented. I've a better hit-rate with > JetBrains and their IDEs. > > - Paul >

Re: Migration of remaining plugins to Git

They're always very polite for things that I ask for, but I can't claim to have suggested anything that got implemented. I've a better hit-rate with JetBrains and their IDEs. - Paul On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Liable to get an

Re: Migration of remaining plugins to Git

Liable to get an answer like: > We don't comment our roadmap publicly I'm afraid (I've gotten that a couple of times for different things... you'd think given that I'm the maintainer of the GitHub Branch Source plugin for Jenkins they might - you know - want to help... but alas) On 18 June 2017

Re: Migration of remaining plugins to Git

Good thought. We could ask about a timeline. On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > They are now adding user grouping... I wonder how long before repo grouping > too > > On Sun 18 Jun 2017 at 17:12, Paul Hammant wrote: > >

Re: Migration of remaining plugins to Git

They are now adding user grouping... I wonder how long before repo grouping too On Sun 18 Jun 2017 at 17:12, Paul Hammant wrote: > Choose one to start with, is what I would do. > > git svn clone of a trunk only, then make that master. branch/tag history > can be retained in

Re: Migration of remaining plugins to Git

Hi, I am currently migrating many projects from sv to git, all of them are on the same svn repo. I am using tools like svn2git https://github.com/nirvdrum/svn2git These tools retain the full history, authors, branches and tags. I can give more info if needed Hope that helps Enrico Il dom 18

Re: Migration of remaining plugins to Git

I updated the page to mark in green the repos that are ready to migrate: just need the job to be done (with the help of infra, I suppose) with immediate one to one migration We can in parallel work on organizing more complex 1 to many migration plan Thank you for your help on this tedious work

Re: Migration of remaining plugins to Git

Choose one to start with, is what I would do. git svn clone of a trunk only, then make that master. branch/tag history can be retained in Subversion but also up on MavenCentral as foo-x.y-sources.jar files. Unless you optimize that git-svn-clone operation by specifying the first Svn commit for

Re: Migration of remaining plugins to Git

yes, git is really ubiquitous now and nowadays could perhaps help some contributions here is our tracking of git migration [1] there are a few entries that we could move if someone takes the job: Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release there are issues to fix when

Re: Migration of remaining plugins to Git

Am 2017-06-18 um 15:45 schrieb Paul Hammant: In order to be able to build a composite 'trunk' for all components of maven (that are org.apache.*) can we move the remaining things left in Subversion to Git, and mirror them to Github? `git submodule` (etc) would be how we'd recreate a developer

Migration of remaining plugins to Git

In order to be able to build a composite 'trunk' for all components of maven (that are org.apache.*) can we move the remaining things left in Subversion to Git, and mirror them to Github? `git submodule` (etc) would be how we'd recreate a developer experience that felt like a single trunk that