Active Maintainer

[kilpatty]

@rodrigc If you are no longer interested in maintaining this project, could you assign some people privileges to build and deploy this plugin?

I know many people (myself included), that use this plugin in Jenkins configurations, and there are some great pull requests on this plugin to make it much better. If you would be so kind as to pass of the maintenance of this plugin, that would be great.

[chales]

bump

[Entea]

bump @rodrigc @tomaswolf @fcamblor @ghaabor @rogerhu @stephenc @ndeloof

[fcamblor]

Hi,

Was at the initiative of the plugin some years ago.

Stopped maintaining it few monthes ago because of several reasons :

• Not enough time
• Hard to follow & integrate Credentials Jenkins feature (which would be particularly interesting on this plugin, see https://issues.jenkins-ci.org/browse/JENKINS-18129)
• Hard to maintain both svn and git implementation (and maybe more), a proposition to modularize the plugin was made (see https://issues.jenkins-ci.org/browse/JENKINS-18124) but would take a lot of time to achieve
• And anyway, I think the way to go is rather to use JenkinsFile allowing to describe job configuration directly into your codebase, and making usage of the plugin totally useless on a per-job manner.

By the way, If someone wants to give some help to @rodrigc / @tomaswolf or take the lead on the project, don't hesitate, I will be happy to see a second life on it :-)
That's how OSS works.

Regards,

[antgel]

@rodrigc @tomaswolf What's going on with this? There's still a lot of interest in the plugin, we are forced to fork and reimplement #23 because it was never merged. The tests on master fail, and there are lots of open issues. Can you give an indication of the status? I think that @shapi78 and / or I would be happy to take over maintanership. @reist Any interest? Cc @jenkinsadmin

[antgel]

@rodrigc @tomaswolf Any clues on this? @guipal Are you involved? Is there anyone out there?

@fcamblor Regarding what you're saying about JenkinsFile, there's lots of configuration in a Jenkins master that's not job-specific. Without this plugin, what's the best practice for bringing up a new master from scratch in a known configuration? We do have Puppet, but it has its limits (maybe we need to explore them further).

[antgel]

Opened https://issues.jenkins-ci.org/browse/JENKINS-53170 to track this.

[fcamblor]

@antgel agreed that the global jenkins configuration config synchronization with SCM is still a valid use case for Jenkins master node.

Note that for slave, I wouldn't encourage it as I guess some discrepancies may exist between slaves and storing it into an SCM may be cumbersome (even if graph oriented SCMs like Git could be helpful by maintaining specific branches per slave typologies)

However, it can be very complicated to know which file to persist and which file to not persist ... particularly given the huge number of plugins (each plugin storing its config into dedicated files)

[antgel]

Yup, it's all about (re)storing that master configuration.

[antgel]

@fcamblor Good to hear from you. I'm a bit confused, on one hand you stopped maintaining because there were several issues, on the other hand you still think it's a valid use case. So should the community be trying to find a new maintainer? Can we encourage you to get involved again? I'm sure that my employer would pay for development of the ability to work with multiple configuration branches in a global repository.

The use case is managing master configurations for environments e.g. dev, qa, prod, via branches, rather than duplicating whole repositories (and having to make sure that they are created manually).