[JIRA] (JENKINS-53247) Support JCasC in Config File Provider Plugin

24 views
Skip to first unread message

rempfer@gmail.com (JIRA)

unread,
Aug 27, 2018, 5:03:02 AM8/27/18
to jenkinsc...@googlegroups.com
Stefan Rempfer created an issue
 
Jenkins / Improvement JENKINS-53247
Support JCasC in Config File Provider Plugin
Issue Type: Improvement Improvement
Assignee: Dominik Bartholdi
Components: config-file-provider-plugin
Created: 2018-08-27 09:02
Labels: jcasc-compatibility
Priority: Minor Minor
Reporter: Stefan Rempfer

Currently it's not possible to configure the Config File Provider Plugin with Jenkins Configuration as Code.

I already written some code for that in the JCasC project https://github.com/jenkinsci/configuration-as-code-plugin/pull/477

Because of the roadmap to bring all the custom configurations to the target plugins, Oleg Nenashev suggested to create an issue for that.

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

rempfer@gmail.com (JIRA)

unread,
Aug 27, 2018, 5:08:01 AM8/27/18
to jenkinsc...@googlegroups.com
Stefan Rempfer commented on Improvement JENKINS-53247
 
Re: Support JCasC in Config File Provider Plugin

Just checked if I could bring the compatibility changes as PR but I realized that the Config File Provider Plugin and JCasC plugin uses very different parent plugins dependency.

I'm completely new in the area of Jenkins plugin development, so I've to do some research before.

Any suggestion what's the best way to bring in the compatibility changes?

rempfer@gmail.com (JIRA)

unread,
Aug 28, 2018, 2:29:01 AM8/28/18
to jenkinsc...@googlegroups.com

There is a new feature which discovers descriptors pointed by ManagementLink as RootElements (https://github.com/jenkinsci/configuration-as-code-plugin/pull/480). So it should be enough to add a simple setter for "org.jenkinsci.plugins.configfiles.GlobalConfigFiles.getConfigs()" to make it compatible.

rempfer@gmail.com (JIRA)

unread,
Aug 28, 2018, 3:11:01 AM8/28/18
to jenkinsc...@googlegroups.com
Stefan Rempfer edited a comment on Improvement JENKINS-53247
There is a new feature which discovers descriptors pointed by ManagementLink as RootElements ( [ https://github.com/jenkinsci/configuration-as-code-plugin/pull/480 ] ). So Perhaps it should be 's enough to add a simple setter for "org.jenkinsci.plugins.configfiles.GlobalConfigFiles.getConfigs()" to make it compatible.

rempfer@gmail.com (JIRA)

unread,
Aug 28, 2018, 3:27:01 AM8/28/18
to jenkinsc...@googlegroups.com

The new feature together with the setter isn't enough because the url name is 'configfiles' and the descriptor has the name GlobalConfigFiles

rempfer@gmail.com (JIRA)

unread,
Aug 29, 2018, 3:15:01 PM8/29/18
to jenkinsc...@googlegroups.com

Currently the JCasC plugin couldn't used as optional dependency because of a Java7/ Java 8 clash:

[INFO] --- maven-enforcer-plugin:1.4.1:enforce (display-info) @ config-file-provider ---
[INFO] Restricted to JDK 1.7 yet io.jenkins:configuration-as-code:jar:1.0-rc2:compile contains io/jenkins/plugins/casc/CasCGlobalConfig.class targeted to JDK 1.8
[WARNING] Rule 2: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion failed with message:
Found Banned Dependency: io.jenkins:configuration-as-code:jar:1.0-rc2
Use 'mvn dependency:tree' to locate the source of the banned dependencies.
 

So only the setter for "org.jenkinsci.plugins.configfiles.GlobalConfigFiles.getConfigs()" could be added.
The Configurator registration have to be done in JCasC plugin integration project.

Oleg Nenashev: Would his be suitable for you, even this fits not 100% to the roadmap of JCasC plugin?

Dominik Bartholdi: Is there a plan to baseline the plugin on Java 8?

rempfer@gmail.com (JIRA)

unread,
Aug 29, 2018, 3:17:01 PM8/29/18
to jenkinsc...@googlegroups.com
Stefan Rempfer started work on Improvement JENKINS-53247
 
Change By: Stefan Rempfer
Status: Open In Progress

rempfer@gmail.com (JIRA)

unread,
Aug 29, 2018, 4:55:02 PM8/29/18
to jenkinsc...@googlegroups.com
Stefan Rempfer edited a comment on Improvement JENKINS-53247
Currently the JCasC plugin couldn't used as optional dependency because of a Java7/ Java 8 clash:

{code}

[INFO] --- maven-enforcer-plugin:1.4.1:enforce (display-info) @ config-file-provider ---
[INFO] Restricted to JDK 1.7 yet io.jenkins:configuration-as-code:jar:1.0-rc2:compile contains io/jenkins/plugins/casc/CasCGlobalConfig.class targeted to JDK 1.8
[WARNING] Rule 2: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion failed with message:
Found Banned Dependency: io.jenkins:configuration-as-code:jar:1.0-rc2
Use 'mvn dependency:tree' to locate the source of the banned dependencies.
{code}


So only the setter for "org.jenkinsci.plugins.configfiles.GlobalConfigFiles.getConfigs()" could be added.
The Configurator registration have to be done in  JCasC plugin integration project.

[~oleg_nenashev]: Would his this be suitable for you, even this it fits not 100% to the roadmap of JCasC plugin?

[~domi]: Is there a plan to baseline the plugin on Java 8?

domi@fortysix.ch (JIRA)

unread,
Aug 30, 2018, 12:17:01 AM8/30/18
to jenkinsc...@googlegroups.com

Stefan Rempfer I'm open to this, but I currently don't know the Java Levels required by the latest couple of LTSs

rempfer@gmail.com (JIRA)

unread,
Aug 30, 2018, 1:50:02 PM8/30/18
to jenkinsc...@googlegroups.com

Here the Java Levels of LTS versions based on https://jenkins.io/doc/upgrade-guide/

Jenkins Version Java Version
LTS 2.7.x unknown - nothing defined in the guide
LTS 2.19.x unknown - nothing defined in the guide
LTS 2.32.x unknown / Java 7 for JNLP4 remoting
LTS 2.46.x unknown / Java 7 for JNLP4 remoting
LTS 2.60.x Java 8
LTS 2.73.x Java 8
LTS 2.89.x Java 8
LTS 2.107.x Java 8
LTS 2.121.x Java 8

rempfer@gmail.com (JIRA)

unread,
Aug 30, 2018, 1:51:01 PM8/30/18
to jenkinsc...@googlegroups.com
Stefan Rempfer edited a comment on Improvement JENKINS-53247
Here are the Java Levels levels of the LTS versions based on [https://jenkins.io/doc/upgrade-guide/]

||Jenkins Version||Java Version||
|LTS 2.7.x|unknown - nothing defined in the guide|
|LTS 2.19.x|unknown - nothing defined in the guide|
|LTS 2.32.x|unknown / Java 7 for JNLP4 remoting|
|LTS 2.46.x|unknown / Java 7 for JNLP4 remoting|
|LTS 2.60.x|Java 8|
|LTS 2.73.x|Java 8|
|LTS 2.89.x|Java 8|
|LTS 2.107.x|Java 8|
|LTS 2.121.x|Java 8|

rempfer@gmail.com (JIRA)

unread,
Aug 30, 2018, 1:56:02 PM8/30/18
to jenkinsc...@googlegroups.com
Stefan Rempfer edited a comment on Improvement JENKINS-53247
Currently the JCasC plugin couldn't used as optional dependency because of a Java7/ Java 8 clash:

{code :java }

[INFO] --- maven-enforcer-plugin:1.4.1:enforce (display-info) @ config-file-provider ---
[INFO] Restricted to JDK 1.7 yet io.jenkins:configuration-as-code:jar:1.0-rc2:compile contains io/jenkins/plugins/casc/CasCGlobalConfig.class targeted to JDK 1.8
[WARNING] Rule 2: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion failed with message:
Found Banned Dependency: io.jenkins:configuration-as-code:jar:1.0-rc2
Use 'mvn dependency:tree' to locate the source of the banned dependencies.
{code}
So only the setter for "org.jenkinsci.plugins.configfiles.GlobalConfigFiles.getConfigs()" could be added.
The Configurator registration have to be done in  JCasC plugin integration project.

[~oleg_nenashev] / [~ndeloof] : Would this be suitable for you, even it fits not 100% to the roadmap of JCasC plugin?


[~domi]: Is there a plan to baseline the plugin on Java 8?

rempfer@gmail.com (JIRA)

unread,
Aug 30, 2018, 4:41:01 PM8/30/18
to jenkinsc...@googlegroups.com

rempfer@gmail.com (JIRA)

unread,
Aug 30, 2018, 4:44:02 PM8/30/18
to jenkinsc...@googlegroups.com

nicolas.deloof@gmail.com (JIRA)

unread,
Aug 31, 2018, 3:10:01 AM8/31/18
to jenkinsc...@googlegroups.com

java 8 is indeed required by jenkins core since 2.60.x (March 2017) so I don't see any major reason for a plugin not to adopt java 8. 

On the other side, if you make GlobalConfigFiles#configs a public final PersistedList or have getConfigs() return a PersistedList, then CasC will also detect this attribute and support it without any additional development effort. The other option if you don't want to switch to this specific Collection implementation is to expose adequate getter/setters so CasC can set collection content.

Can also add a `@Symbol` annotation to define preferred name for this component in DSL usage, which includes CasC yaml syntax.

domi@fortysix.ch (JIRA)

unread,
Aug 31, 2018, 7:40:01 AM8/31/18
to jenkinsc...@googlegroups.com

OK, i'll update to LTS 2.60.x as soon as I can - hopefully in the next couple of days...

rempfer@gmail.com (JIRA)

unread,
Aug 31, 2018, 8:13:01 AM8/31/18
to jenkinsc...@googlegroups.com

rempfer@gmail.com (JIRA)

unread,
Aug 31, 2018, 8:34:02 AM8/31/18
to jenkinsc...@googlegroups.com

domi@fortysix.ch (JIRA)

unread,
Aug 31, 2018, 8:43:02 AM8/31/18
to jenkinsc...@googlegroups.com

cool, please just open a PR that will for sure speedup things - thanks!!!

domi@fortysix.ch (JIRA)

unread,
Sep 2, 2018, 3:56:01 PM9/2/18
to jenkinsc...@googlegroups.com

Nicolas De Loof the plugin is now up to Java8, but I'm not sure about the PersistedList - I need a bit of time to investigate this, Its a while ago since I changed that implementation to what it is now and I remember there where many issues about it. 

But there is already an Getter: org.jenkinsci.plugins.configfiles.GlobalConfigFiles#getConfigs() - ist this OK, do you only need a Setter in addition to this one?

What about the config files on folders level? There is also a org.jenkinsci.plugins.configfiles.folder.FolderConfigFileProperty which has about the same functionality as the GlobalConfigFiles, but can exist on each folder. Do you need the same there too?

 

...what 'component' are you talking about to add a '@Symbol'? - three are already two:

  • configFileProvider -> org.jenkinsci.plugins.configfiles.buildwrapper.ConfigFileBuildWrapper.DescriptorImpl
  • configFile -> org.jenkinsci.plugins.configfiles.buildwrapper.ManagedFile.DescriptorImpl

nicolas.deloof@gmail.com (JIRA)

unread,
Sep 3, 2018, 3:23:02 AM9/3/18
to jenkinsc...@googlegroups.com

as there's already a getter GlobalConfigFiles#getConfigs() we only need a matching setter for this property.

 

> What about the config files on folders level? 

CasC do not manage items, we let job-dsl plugin handle this for now. Maybe in future we could also support items, but we focus for short terms on global configuration that is already challenging

 

> ...what 'component' are you talking about to add a '@Symbol'?

GlobalConfigFiles, so one can set `configs` there. if no symbol is set this component will be accessible using CasC as "globalConfigFiles"

nor ConfigFileBuildWrapper.DescriptorImpl neither ManagedFile.DescriptorImpl are considered by CasC as they don't have global configuration to get set.

domi@fortysix.ch (JIRA)

unread,
Sep 3, 2018, 4:00:02 AM9/3/18
to jenkinsc...@googlegroups.com

rempfer@gmail.com (JIRA)

unread,
Sep 3, 2018, 5:25:02 AM9/3/18
to jenkinsc...@googlegroups.com

nicolas.deloof@gmail.com (JIRA)

unread,
Sep 11, 2018, 5:41:02 AM9/11/18
to jenkinsc...@googlegroups.com

Unfortunately as GlobalConfigFiles is not extending GlobalConfiguration there's no way for CasC to discover this component and use it as a candidate for yaml configuration. And ConfigFilesManagement isn't just a link to a valid Descriptor, it owns a dedicated UI.

 

 

nicolas.deloof@gmail.com (JIRA)

unread,
Sep 11, 2018, 6:42:03 AM9/11/18
to jenkinsc...@googlegroups.com

domi@fortysix.ch (JIRA)

unread,
Oct 11, 2018, 4:32:02 AM10/11/18
to jenkinsc...@googlegroups.com
Dominik Bartholdi resolved as Fixed
 

released with 3.3 of config-file-provider

Change By: Dominik Bartholdi
Status: In Progress Resolved
Resolution: Fixed

o.v.nenashev@gmail.com (JIRA)

unread,
May 22, 2019, 7:58:02 AM5/22/19
to jenkinsc...@googlegroups.com
Oleg Nenashev updated an issue
Change By: Oleg Nenashev
Released As: Config File Provider 3.3
Reply all
Reply to author
Forward
0 new messages