Repository navigation
[JENKINS-66470] folder-auth-plugin causes ConfigurationAsCode.init to fail after LTS 2.303.1 #12149
Description
After upgrading to LTS 2.303.1, Jenkins fails to start at ConfigurationAsCode.init.
Log excerpt:
2021-08-27 11:36:49.205+0000 [id=30] SEVERE jenkins.InitReactorRunner$1#onTaskFailed: Failed ConfigurationAsCode.init
java.lang.IllegalArgumentException: Unable to infer permission from the given Id: View/Configure
at io.jenkins.plugins.folderauth.misc.PermissionWrapper.checkPermission(PermissionWrapper.java:100)
at io.jenkins.plugins.folderauth.misc.PermissionWrapper.(PermissionWrapper.java:49)
Caused: java.lang.reflect.InvocationTargetException
at jdk.internal.reflect.GeneratedConstructorAccessor27.newInstance(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.tryConstructor(DataBoundConfigurator.java:173)
Caused: io.jenkins.plugins.casc.ConfiguratorException: permissionWrapper: Failed to construct instance of class io.jenkins.plugins.folderauth.misc.PermissionWrapper.
...
(See attached file for full startup log)
Further information about my environment:
I have a docker image pulling latest (jenkins/jenkins:lts-jdk11) and that installs a couple of plugins (including configuration-as-code and folder-auth). I noticed my configuration as code config file stopped working after the release of 2.303.1.
I've tested downgrading my image to the previous LTS image (jenkins/jenkins:2.289.3-jdk11) and all errors disappear, making me believe the issue is caused by an incompatibility between the two plugins and the 2.303.1 LTS release.
Removing my entire 'folderBased:' section from my JCasC yaml file also circumvents the errors on LTS 2.303.1.
Originally reported by 
edfa, imported from: folder-auth-plugin causes ConfigurationAsCode.init to fail after LTS 2.303.1
- assignee: basil
- status: Closed
- priority: Critical
- component(s): core
- label(s): 2.303.2-fixed, regression
- resolution: Fixed
- resolved: 2021-09-17T15:58:14+00:00
- votes: 0
- watchers: 6
- imported: 2025-11-24
Raw content of original issue
After upgrading to LTS 2.303.1, Jenkins fails to start at ConfigurationAsCode.init.
Log excerpt:
2021-08-27 11:36:49.205+0000 [id=30] SEVERE jenkins.InitReactorRunner$1#onTaskFailed: Failed ConfigurationAsCode.init java.lang.IllegalArgumentException: Unable to infer permission from the given Id: View/Configure at io.jenkins.plugins.folderauth.misc.PermissionWrapper.checkPermission(PermissionWrapper.java:100) at io.jenkins.plugins.folderauth.misc.PermissionWrapper.<init>(PermissionWrapper.java:49) Caused: java.lang.reflect.InvocationTargetException at jdk.internal.reflect.GeneratedConstructorAccessor27.newInstance(Unknown Source) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.tryConstructor(DataBoundConfigurator.java:173) Caused: io.jenkins.plugins.casc.ConfiguratorException: permissionWrapper: Failed to construct instance of class io.jenkins.plugins.folderauth.misc.PermissionWrapper. ...(See attached file for full startup log)
Further information about my environment: I have a docker image pulling latest (jenkins/jenkins:lts-jdk11) and that installs a couple of plugins (including configuration-as-code and folder-auth). I noticed my configuration as code config file stopped working after the release of 2.303.1.
I've tested downgrading my image to the previous LTS image (jenkins/jenkins:2.289.3-jdk11) and all errors disappear, making me believe the issue is caused by an incompatibility between the two plugins and the 2.303.1 LTS release.
Removing my entire 'folderBased:' section from my JCasC yaml file also circumvents the errors on LTS 2.303.1.
environment
Jenkins: 2.303.1<br/>
folder-auth: 1.3<br/>
configuration-as-code: 1.52
Activity
jenkins-infra-bot commentedon Aug 27, 2021
Remote link associated with this issue:
jenkins-infra-bot commentedon Aug 27, 2021
Raw content of original comment:
Oops, looks like something broke in Jenkins core. Taking a look...
jenkins-infra-bot commentedon Aug 27, 2021
Raw content of original comment:
Hi edfa. I cannot reproduce this issue with Jenkins 2.303.1, configuration-as-code 1.52, java version "1.8.0_181", Windows 10 21H1. Can you please share your configuration yaml? From what I can tell, nothing major has changed either in Jenkins core or jcasc. `View/Configure` is a part of our tests (see https://github.com/jenkinsci/folder-auth-plugin/blob/master/src/test/resources/io/jenkins/plugins/folderauth/casc/config3.yml#L33
If you change your id to `hudson.model.View.Configure`, does the issue still persist?
jenkins-infra-bot commentedon Aug 31, 2021
Raw content of original comment:
Sure, I'll have a look on my end!
Edit:
Ok, the biggest difference I see is that I'm running jdk11
`java --version` within the container returns:
$ java --version openjdk 11.0.12 2021-07-20 OpenJDK Runtime Environment Temurin-11.0.12+7 (build 11.0.12+7) OpenJDK 64-Bit Server VM Temurin-11.0.12+7 (build 11.0.12+7, mixed mode)I remember reading in the patch notes that Jenkins would switch to jdk11 containers by default by 2.303.1, but I was already running that prior to updating so odd that it'd break now.
Edit2:
Switching `View/Configure` with `hudson.model.View.Configure` does solve the error.
If you want a copy of my yaml I'd have to clean it up a bit so I don't share sensitive information, but the only roles I have in it at this point is "admin" with all permissions added to it and a "Read/Build" one with `Agent/Build`, `Agent/Connect`, `Overall/Read`, `View/Read` (this role does not trigger any errors though).
jenkins-infra-bot commentedon Sep 1, 2021
Raw content of original comment:
Hi edfa, I verified that folder-auth v1.3 works with configuration-as-code-plugin v1.52 on jenkins/jenkins:lts-jdk11. Since `hudson.model.View.Configure` does work, the permission is loaded properly into Jenkins. Moreover, as `View/Read` works without any problems and as the plugin handles both `View/Read` and `View/Configure` identically, I am inclined to think that this error may have been thrown because of some minor error in your configuration.
This error is thrown only when the plugin is not able to find a permission with the given id. If possible, could you please share the config of the roles that have View/Configure?
jenkins-infra-bot commentedon Sep 2, 2021
Raw content of original comment:
The conf I use is pretty much grabbed from JCasC's "View Configuration" screen and pasted into a yaml file. The admin role, which was auto created by Jenkins prior to me copying it to my yaml, is the only one that includes the `View/Configure` permission, so I don't see how the conf could be faulty. Especially when the same conf works fine in all previous versions I've run it in.
This is the admin role conf:
When you are testing, are you using a completely new and pristine Jenkins installation?
I'm trying to think of other possible variables in my setup that could differ. Aside from mine being inside a container (running linux) I'm using JCasC for the initial install only, which means I only tell Jenkins to read the yaml config at first start-up. I also bypass the startup wizard with
ENV JAVA_OPTS "-Djenkins.install.runSetupWizard=false"jenkins-infra-bot commentedon Sep 2, 2021
Raw content of original comment:
Yes, I did use a clean Jenkins install. I used the jenkins/jenkins:lts-jdk11 image from DockerHub and ran it using Docker Desktop for windows.
I manually skipped the setup wizard and installed configuration-as-code and folder-auth from the update center. Then I copied this configuration into the container and used the 'reload from configuration file or URL' option from the JCasC UI.
Your config looks perfectly fine to me. Skipping the setup wizard also shouldn't have any impact because that is what happens during the plugin tests. Is there anything else about your environment that could lead to this error?
To be honest, I am really confused by this error. The fact that `View/Read` does not cause an issue while `View/Configure` does is quite weird, especially since they are both defined in the same class on adjacent lines. and haven't been changed for 10 years.
jenkins-infra-bot commentedon Sep 2, 2021
Raw content of original comment:
Hi oleg_nenashev and timja, I went through the Jenkins core and configuration-as-code change logs and commit histories and did not find anything that would lead to this error? Would you have an idea about what is happening here?
jenkins-infra-bot commentedon Sep 2, 2021
Raw content of original comment:
This issue? jenkinsci/configuration-as-code-plugin#1638
jenkins-infra-bot commentedon Sep 3, 2021
Raw content of original comment:
I did some testing and created a repo with a "minimal" install where I get a solid repo of this issue. Maybe it will help: https://github.com/vonEdfa/test-jenkins-66470
jenkins-infra-bot commentedon Sep 3, 2021
Raw content of original comment:
Thanks edfa! I can see the error now. On attaching a remote debugger, I can see that the `View` PermissionGroup is not loaded.
However, during the tests, the `View` PermissionGroup is present.
jenkins-infra-bot commentedon Sep 6, 2021
Raw content of original comment:
Any idea what might cause this behavior?
jenkins-infra-bot commentedon Sep 7, 2021
Raw content of original comment:
edfa this issue is being discussed here: jenkinsci/configuration-as-code-plugin#1638
jenkins-infra-bot commentedon Sep 17, 2021
Raw content of original comment:
This has been fixed on master and is being backported to 2.303.2 as well