configuration-as-code-plugin: CasC is unable to reapply GlobalJobDslSecurityConfiguration after Jenkins restart

I firstly observed that behavior when killing our Jenkins pod in K8s and it didn’t get back up. CasC 0.7-alpha was unable to reapply following part of the configuration. It also happened with earlier versions.

security:
  GlobalJobDslSecurityConfiguration:
    useScriptSecurity: false

The exception thrown is:

Caused by: org.jenkinsci.plugins.casc.ConfiguratorException: Invalid configuration elements for type class jenkins.model.GlobalConfigurationCategory$Security : GlobalJobDslSecurityConfiguration

I traced it back to following line not resolving to true after restart for the GlobalJobDslSecurityConfiguration: https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/src/main/java/org/jenkinsci/plugins/casc/GlobalConfigurationCategoryConfigurator.java#L61

The culprit is

descriptor.getCategory() == category

resolving to false after restart.

See PR #255 for failing testcase.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 20 (13 by maintainers)

Commits related to this issue

Failing test case for #253 (contributed by @hawky-4s-) Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com> — committed to jenkinsci/configuration-as-code-plugin by ndeloof 6 years ago

Most upvoted comments

got it:

serialized xml for GlobalJobDslSecurityConfiguration includes an unexpected line:

<category class="jenkins.model.GlobalConfigurationCategory$Security"/>

This is caused by groovy style property used to override getCategory

final GlobalConfigurationCategory category = GlobalConfigurationCategory.get(GlobalConfigurationCategory.Security)

doing so, XStream do consider a filed to be serialized, not just a method override. As a result, on load, XStream do create a fresh new jenkins.model.GlobalConfigurationCategory$Security instance, which is != from the singleton it is supposed to be.

ndeloof on Sep 28, 2018

@ndeloof @ewelinawilkosz I think this issue can be closed :

job-dsl PR has finally been merged and is present in the job-dsl-1.71 release of January
I just applied the following configuration and the error did not occur anymore :

security:
  globaljobdslsecurityconfiguration:
    useScriptSecurity: true

yogeek on Feb 6, 2019