[Feature] Plugin installation about configuration-as-code-plugin HOT 12 CLOSED

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

from configuration-as-code-plugin.

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

from configuration-as-code-plugin.

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.

from configuration-as-code-plugin.

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

from configuration-as-code-plugin.

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: ...

from configuration-as-code-plugin.

@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).

from configuration-as-code-plugin.

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

from configuration-as-code-plugin.

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

from configuration-as-code-plugin.

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

from configuration-as-code-plugin.

@ndeloof are you going to work on that one?

from configuration-as-code-plugin.

Yes, I'll work on a proposal next week

from configuration-as-code-plugin.

let's continue in #104

from configuration-as-code-plugin.