-
New Feature
-
Resolution: Unresolved
-
Major
While a traditional project's config.xml can simply be inspected for plugins it is using, which is useful for example to ensure that the project is not loaded in an inappropriate server, this is not true of Pipeline scripts—steps it uses might be defined in various plugins, or metasteps like checkout might have configuration which refers to various plugins.
There should be a way for the job itself to declare which plugins it wants loaded. The simplest approach would simply be a step which fails if some of the requested plugins are missing or too old:
requirePlugins ['junit@1.6', 'parallel-test-executor']
However as this is logically part of the job configuration as a whole, rather than something to be executed at a particular point in the build, it might make more sense as a JobProperty; a build started with missing plugins would immediately fail with an informative message. Using a property does not preclude defining the list from the script itself, using the properties step.
The configuration form for the property or step could use JENKINS-31582 to inspect the last build and suggest which plugins to list.
- depends on
-
JENKINS-31582 Log / document the plugin usage in the flow nodes
-
- Resolved
-
- is duplicated by
-
JENKINS-51557 Plugin Dependency for pipeline files
-
- Fixed but Unreleased
-
- is related to
-
JENKINS-39920 Pipeline job type has no ability to specify the node labels it can run on
-
- Resolved
-
-
JENKINS-39921 Pipeline job type unable to run in specified docker image
-
- Resolved
-
- relates to
-
JENKINS-15003 Track and verify plugins mentioned in configuration XML
-
- Resolved
-
- links to
I've been thinking a lot about this general idea the past couple weeks, and had even considered writing a plugin last weekend before I got sick
I think a more generic "require" syntax would be ideal for example:
Which could be expanded upon with the keyword arguments in groovy to support additional requirement statements in the future, e.g.
I'm curious what hrmpw and abayer think of this syntax.
Mostly agreed, i suggest that the pipeline should abort because of missing dependencies with console outputs stating this Jenkins instance is lacking the required dependencies to execute this pipeline. I generally interpret failures to mean the Pipeline is broken (user error) rather than something requiring a user/administrator cooperation to rectify. I don't have much better reasoning than that, but an abort would catch my gaze a lot sooner than a failure, unfortunately
As far as version restricting goes, in my mind I was thinking on punting on that for now until some more users using any require syntax.