Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

additional chapter on plugin management #59

Closed
wants to merge 3 commits into from
Closed

additional chapter on plugin management #59

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
1263564
additional chapter on plugin management
ndeloof Feb 21, 2018
c32d37d
minor grammar fixes
ndeloof Apr 18, 2018
71075b1
some clarifications
ndeloof Apr 24, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions jep/201/README.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -209,6 +209,10 @@ In some circumstances the Java codebase doesn’t match the web UI forms and rel
object is such a component. For those, we need to provide some dedicated configuration adapter code. Some plugins might need the same.
We have identified credentials-plugin as such a component.

This document do describe the general mechanism but won't get into details for plugin-specific implementations.
We expect plugin which require some custom adapter code to host such a component, and the discussion on the
right model to expose to end user to take place there.

=== Documentation / Schema generation

As configuration-as-code mechanism relies on data-binding mechanism, we can construct a full data model from a live jenkins instance, and
Expand All @@ -230,13 +234,40 @@ The former just uses the configuration-as-code mechanism for initial setup.
The latter would apply the configuration when updates are detected on file. It could benefit some way to lock down configuration for
components configured by the configuration-as-code mechanism to be read-only on web UI.

=== Plugin management
As part of configuring the Jenkins Master we support plugin installation and management. The Configuration-as-Code plugin itself is out-of-scope, it has to be bundled with Jenkins so it can take control on the master. But for all other plugins we want configuration-as-code to offer :

- a high-level, user-friendly way to define "feature" plugins to be installed. Typically, end users want to build GitHub pull requests, they don't care that this will required `token-macro` for some low-level implementation reasons.
- a fully reproducible way to setup a master. Relying on `latest` for transitive dependencies is _not_ an acceptable solution. Upgrades should also be tracked as configuration changes.
- ability to configure infrastructure : private update sites and http proxy to download plugins.

==== Shrink wrap
`npm` is a typical example of a dependency manager which has to support comparable requirements : provide reproducible dependency management in a moving javascript ecosystem. It supports a [`shrinkwrap` file](https://docs.npmjs.com/cli/shrinkwrap) to compute a dependency list from a higher-level definition, and be able to exactly reproduce this setup later.

The Configuration-as-Code plugin can offer plugin management _outside_ Jenkins as a standalone java executable. It can then consume a `plugins.yaml` file, provided as part of the configuraiton, to resolve plugin dependencies and compute a full list of plugins to be installed, which would be stored as `plugins.shrinkwrap` file. This later file can be used to automate plugin installation.

==== Plugin installation
The Configuration-as-Code can consume this shrinkwrap file and compare the requested state _vs_ actual master installation. If some extra plugins have to be installed, it can then setup pluginManager and trigger plugin installation, then restart Jenkins.
As the yaml configuration may have references to plugin components, this process has to be executed _before_ any other configuration.

For flexibility and convenience, the `plugins.shrinkwrap` file is optional, and plugin installation would then just rely on PluginManager to manage transitive dependencies. Configuration-as-Code would then just log a warning about reproducibility.

==== Dependency management
As `plugins.shrinkwrap` computation is executed outside Jenkins, we can offer an alternate implementation for transitive dependency management and dependency resolution. With extra metadata exposed in the Update Center, we could offer some more advanced logic in dependency resolution, not just getting `latest` of all plugins. Such metadata would express known compatibility-breaks, synchronized releases for highly dependent plugins, recommended version, etc. This is typically what Linux package management systems do.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Applying a fixed version configuration should check published security warnings from existing update-center.json and log warnings if the plugin configuration has warnings reported against it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree it would be nice to include some security support here, anyway I'd prefer we don't extensively discuss what plugin management should look like (as noticed by @oleg-nenashev this also would apply to docker image). My major concern here is to offer plugin management with JCasC and reproducibility.

I'd like we discuss plugin management v2.0 in a decidacted JEP. We need security updates, but also actual dependency management, compatibility breaks, recommended ... all sort of things system package manager have implemented but Jenkins doesn't offer. This should be packaged as a standalone tool we could use from JCasC but also docker image or bundled in jenkins.war.




== Backwards Compatibility

Configuration-as-Code is intended to run as an additional Jenkins component (most probably: a plugin) and not require dedicated extension
integrated in Jenkins-core nor specific API implemented by plugins. We only require them to follow some convention in the way they expose
configuration attributes (i.e +DataBoundSetter|Constructor+)

As Configuration-as-Code model is directly compute based on exposed API, this model might change with
Copy link
Contributor

@bitwiseman bitwiseman May 14, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is listed under backward compatibility, but it is as much about "Version Compatibility" (backward and forward). This sounds like a potentially massive pain point for users. As such, this behavior - what doesCasC when the YAML doesn't match the version of Jenkins and/or it's plugins - needs to be more fully described as the customer is almost guaranteed to have to debug YAML config incompatibilities, possibly extensively and often.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes indeed, but this is the price to pay to avoid a new API to be implemented by 1500 plugins and many users to complain their favourite plugin isn't supported.

jenkins-core or plugin upgrades. We don't offer any backward compatibility support. As a user wants
to upgrade Jenkins or plugins, he has to run a test master to confirm his yaml configuration is still
valid. Or he can rely on generated schema for target core+plugin version to validate this file.

== Security

N/A
Expand Down