Configuration-as-code-plugin: [Feature] Plugin installation

[ewelinawilkosz]

If we install new plugins in the plugin.yml file, how can they be updated without restart as many plugins require restart on update.

[ndeloof]

I don't expect configuration-as-code to fix all jenkins design issues :-P
configuration-as-code could easily _check_ a required list of plugin is installed, as some sort of a company policy check. But installing plugins is a distinct job, which require a restart in most cases, and also hardly can be managed by this plugin from _inside_ jenkins, would need to run priori to it's execution. Better imho to rely on plugins.txt as in docker image.

[ndeloof]

My current thoughts on this feature:

We could implement a dedicated Configurator for a new plugins RootElement and related new management component.

• relies on a map of plugin ID -> version

plugins:
  git: 2.4
  maven: 1.2

• checks PluginManager for installed plugins and compare with required version.
• react on version mismatch or plugin failure by replacing stapler app with an error page to block startup (or System.exit ?).

If we want to offer an equivalent for docker image's install-plugins.sh script we will need one additional step :

• react on missing plugins by triggering installation and restart jenkins.

But this would have to run _after_ jenkins.updateCenter.sites and jenkins.proxy, have been configured, and also the yaml configuration would probably be invalid at parsing time as referenced plugins aren't installed yet (chicken and egg issue).

So we will need to have a special configuration file loaded before all others, to set jenkins.updateCenter.sites, jenkins.proxy, and required plugins, then (maybe after restart) parse other configuration files.
As jenkins.proxy is configured on UI via PluginManager, I suggest we define a special role for a plugins.yaml file to be loaded first and used to configure PluginManager (and only this guy) :

plugins: # alias for PluginManager
  updateSites:
    - "http://jenkins-uc.acme.com"
  proxy:
    name: "proxy.acme.com"
    port: 8080
    userName: foo
    password: ${INJECT}
  required:
    git: 2.4
    maven: 1.2

[MadsNielsen]

Right after we implemented the change that puts all other elements under a fake 'jenkins' root element, should this also be put as a child of this fake root element? So we have:

jenkins: 
   plugins: ...
   mailer: ...

[ewelinawilkosz]

I wouldn't say so - we're putting some elements under 'jenkins' so it mimics UI - we configure Mailer under 'Configure System' in Jenkins and that's the 'jenkins' root element
Plugins have separate subpage, 'Manage Plugins' so in my opinion 'plugins' deserves to be root element itself - if that's possible

[MadsNielsen]

@ewelinawilkosz Super just what i thought! :)

I've started to do a bit of work on this...and i've got something working atleast (I can set proxy on the jenkins instance)...but im not sure im doing it the right way. I can correctly configure a proxy configuration

    @Override
    public PluginManager configure(Object config) throws Exception {
        Map map = (Map) config;
        Configurator<ProxyConfiguration> pc = Configurator.lookup(ProxyConfiguration.class);
        ProxyConfiguration pcc = pc.configure(map.get("proxy"));
        Field f = Jenkins.class.getDeclaredField("proxy");
        f.set(Jenkins.getInstance(), pcc);
        Jenkins.getInstance().save();
        return null;
    }

I'm a bit unsure here, first of all i started out with a root configurator named plugins...and an attribute proxy added in the describe method of type ProxyConfiguration. It's databound so the configure method correcty returns an object we can play with.

What would be the best root element to start with? @ndeloof suggested PluginManager, but some of the stuff i need to set seems to belong to UpdateCenter (I.e sites).

[ndeloof]

I don't think we have any adequate class in jenkins model for this purpose : update sites for sample have no associated UI for configuration. So probably better to define a set of custom data classes that you'll then use to configure plugin manager and other related elements (proxy, etc)

see for sample https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/src/main/java/org/jenkinsci/plugins/casc/core/HudsonPrivateSecurityRealmConfigurator.java#L35

[ndeloof]

By the way, about

Field f = Jenkins.class.getDeclaredField("proxy");
f.set(Jenkins.getInstance(), pcc);

proxy being public, you can just write Jenkins.getInstance.proxy = pcc

[MadsNielsen]

@ndeloof Thanks for the input! I'll try that approach instead.

[ewelinawilkosz]

issue discussed at post-FOSDEM hackathon (https://docs.google.com/document/d/1IlVC9wqYsaa3aO2krYTu6P8olX6K5jZxG4zQwbKXRyc/edit9) with following conclusion:

• Implement “Light solver” based plugin installation scheme in CaC
• Introduce metadata in the update center to make the light solver better than the dumb algorithm

@ndeloof will land his existing code into the repository

User experience: What we’d like to do

• B: just list “git” and “blueocean” and maybe specify their versions, have the dependencies figured out automatically
• KK: provide immutability. Be able to bring bacak the same exact plugin versions a year later

Proposed scenario:

$ cat > Pluginsfile
plugin “git”, “2.3”
plugin “blueocean”, “1.3”

$ cac Pluginfile
(this resolves dependencies, etc, then creates Pluginfile.lock that lists exact versions)
$ git add Pluginfile.lock
(you commit this result to ensure immutability)

# Updating dependencies
$ cac -preferMinimalModification | -preferLatest Pluginfile
(this will update Pluginfile.lock with new dependencies)
$ git commit Pluginfile.lock

see issue #6 above for how to reload this new setting into Jenkins

Also that means we detach plugins from jenkins.yaml and put it in separate file

[ewelinawilkosz]

@ndeloof are you going to work on that one?

[ndeloof]

Yes, I'll work on a proposal next week

[ewelinawilkosz]

let's continue in #104