[JIRA] (JENKINS-56898) Add support for configuration-as-code

Add support for configuration-as-code

Issue Type:	New Feature
Assignee:	Unassigned
Components:	dependency-check-jenkins-plugin
Created:	2019-04-05 08:46
Priority:	Major
Reporter:	Robin Jansohn

Please add support for configuration-as-code for this plugin so we can use it in a fully automated installation of our Jenkins instance.

Guide for plugin developers:
https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/docs/PLUGINS.md

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

robin.jansohn@zf.com (JIRA)

unread,

Apr 5, 2019, 5:06:02 AM4/5/19

to jenkinsc...@googlegroups.com

Robin Jansohn updated an issue

Jenkins /

Add support for configuration-as-code

Change By:	Robin Jansohn
Labels:	jcasc-compatibility

steve.springett@owasp.org (JIRA)

unread,

Apr 5, 2019, 10:02:02 PM4/5/19

to jenkinsc...@googlegroups.com

Steve Springett commented on

The plugin already supports pipeline. What specific requirement do you have outside of pipeline support?

robin.jansohn@zf.com (JIRA)

unread,

Apr 8, 2019, 3:13:02 AM4/8/19

to jenkinsc...@googlegroups.com

Robin Jansohn commented on

As mentioned in the description I want to configure the plugin when starting Jenkins through code (initial setup, cloning environments, ...). Pipeline has nothing to do with it as far as I can see.

The configuration snippet would look something like this:

 
                                                                unclassified:
  dependencyCheckBuilder:
    globalDataDirectory: "/var/jenkins_home/dependency-check-data/3.0"

steve.springett@owasp.org (JIRA)

unread,

Apr 8, 2019, 10:25:02 AM4/8/19

to jenkinsc...@googlegroups.com

Steve Springett commented on

PRs are welcome

nico@nicorikken.eu (JIRA)

unread,

Jun 22, 2019, 4:31:02 AM6/22/19

to jenkinsc...@googlegroups.com

Nico Rikken commented on

We have a similar use-case, namely changing the URL's to our own NIST proxy. Not something to set on a pipeline-level (and not exposed there). We deploy Jenkins using Helm on our Kubernetes cluster.

We've looked into adding configuration options as a PR. Robin Jansohn adding support seems do-able, documentation you linked above is great. But for now it was easier and faster to deploy the XML configuration from a configmap.

steve.springett@owasp.org (JIRA)

unread,

Jun 24, 2019, 12:59:02 PM6/24/19

to jenkinsc...@googlegroups.com

Steve Springett commented on

In v5.0 of the plugin (once released), there isn't a lot of configuration involved. The Jenkins plugin (the builder anyway) as you know it, doesn't exist anymore.

It's a global tool which is installed. There are no global configuration options and only a few per-job configuration options. In v5, a job will have a textarea form field in which a user can specify any of the CLI arguments detailed here https://jeremylong.github.io/DependencyCheck/dependency-check-cli/arguments.html

Once v5 is released, come back to this thread and see what configuration-as-code would look like for a globally installed tool - which supports everything from Dependency-Check v1.0.0 to present.

nico@nicorikken.eu (JIRA)

unread,

Jun 25, 2019, 2:23:02 AM6/25/19

to jenkinsc...@googlegroups.com

Nico Rikken commented on

Steve Springett Thanks for this clarification. That sounds good, we'll be looking out for v5 then. Thanks for major update!

robin.jansohn@zf.com (JIRA)

unread,

Jun 25, 2019, 2:36:03 AM6/25/19

to jenkinsc...@googlegroups.com

Robin Jansohn commented on

Steve Springett no global configuration options? We currently set the Global Data Directory and as Nico Rikken we also use an internal NIST mirror. Setting this to the same value for each job would massively increase duplicate configuration settings. Please reconsider this design choice as it makes no sense IMHO. Or did I misunderstand your comment?

steve.springett@owasp.org (JIRA)

unread,

Jul 6, 2019, 11:31:02 PM7/6/19

to jenkinsc...@googlegroups.com

Steve Springett commented on

Actually, it should decrease duplication. Use one or more property files and specify them with -p as defined in https://jeremylong.github.io/DependencyCheck/dependency-check-cli/arguments.html The property file will have all the NIST, proxy, and analyzer settings. Use multiple property files for different types of jobs if necessary.

robin.jansohn@zf.com (JIRA)

unread,

Jul 8, 2019, 5:21:01 AM7/8/19

to jenkinsc...@googlegroups.com

Robin Jansohn commented on

I have to disagree. Needing to specify a property file for every dependency check call still leads to duplicate configuration settings (besides the additional nuisance of having to manage another separate property file).

Please don't remove the global configuration options (at least not for the global data directory and NIST mirror settings). It should still be possible to set global defaults which may be overwritten on the job-level if necessary.