Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-66470

folder-auth-plugin causes ConfigurationAsCode.init to fail after LTS 2.303.1

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • core
    • Jenkins: 2.303.1
      folder-auth: 1.3
      configuration-as-code: 1.52
    • 2.313

      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.

       

       

       

          [JENKINS-66470] folder-auth-plugin causes ConfigurationAsCode.init to fail after LTS 2.303.1

          Oops, looks like something broke in Jenkins core. Taking a look...

          Abhyudaya Sharma added a comment - Oops, looks like something broke in Jenkins core. Taking a look...

          Abhyudaya Sharma added a comment - - edited

          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?

          Abhyudaya Sharma added a comment - - edited 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?

          Malin added a comment - - edited

          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).

          Malin added a comment - - edited 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).

          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.

          java.lang.IllegalArgumentException: Unable to infer permission from the given Id: View/Configure

          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?

          Abhyudaya Sharma added a 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. java.lang.IllegalArgumentException: Unable to infer permission from the given Id: View/Configure 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?

          Malin added a comment - - edited

          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:

          folderBased:
                globalRoles:
                - name: "admin"
                  permissions:
                  - id: "Credentials/Create"
                  - id: "Credentials/Delete"
                  - id: "Credentials/ManageDomains"
                  - id: "Credentials/Update"
                  - id: "Credentials/UseItem"
                  - id: "Credentials/UseOwn"
                  - id: "Credentials/View"
                  - id: "Agent/Build"
                  - id: "Agent/Configure"
                  - id: "Agent/Connect"
                  - id: "Agent/Create"
                  - id: "Agent/Delete"
                  - id: "Agent/Disconnect"
                  - id: "Agent/ExtendedRead"
                  - id: "Agent/Provision"
                  - id: "Overall/Administer"
                  - id: "Overall/Manage"
                  - id: "Overall/Read"
                  - id: "Overall/SystemRead"
                  - id: "Job/Build"
                  - id: "Job/Cancel"
                  - id: "Job/Configure"
                  - id: "Job/Create"
                  - id: "Job/Delete"
                  - id: "Job/Discover"
                  - id: "Job/ExtendedRead"
                  - id: "Job/Move"
                  - id: "Job/Read"
                  - id: "Job/WipeOut"
                  - id: "Job/Workspace"
                  - id: "Run/Artifacts"
                  - id: "Run/Delete"
                  - id: "Run/Replay"
                  - id: "Run/Update"
                  - id: "View/Configure"
                  - id: "View/Create"
                  - id: "View/Delete"
                  - id: "View/Read"
                  - id: "SCM/Tag"
                  - id: "Lockable Resources/Reserve"
                  - id: "Lockable Resources/Unlock"
                  - id: "Lockable Resources/View"
                  sids:
                  - "admin"
          

          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"

          Malin added a comment - - edited 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: folderBased:       globalRoles:       - name:  "admin"         permissions:         - id:  "Credentials/Create"         - id:  "Credentials/Delete"         - id:  "Credentials/ManageDomains"         - id:  "Credentials/Update"         - id:  "Credentials/UseItem"         - id:  "Credentials/UseOwn"         - id:  "Credentials/View"         - id:  "Agent/Build"         - id:  "Agent/Configure"         - id:  "Agent/Connect"         - id:  "Agent/Create"         - id:  "Agent/Delete"         - id:  "Agent/Disconnect"         - id:  "Agent/ExtendedRead"         - id:  "Agent/Provision"         - id:  "Overall/Administer"         - id:  "Overall/Manage"         - id:  "Overall/Read"         - id:  "Overall/SystemRead"         - id:  "Job/Build"         - id:  "Job/Cancel"         - id:  "Job/Configure"         - id:  "Job/Create"         - id:  "Job/Delete"         - id:  "Job/Discover"         - id:  "Job/ExtendedRead"         - id:  "Job/Move"         - id:  "Job/Read"         - id:  "Job/WipeOut"         - id:  "Job/Workspace"         - id:  "Run/Artifacts"         - id:  "Run/Delete"         - id:  "Run/Replay"         - id:  "Run/Update"         - id:  "View/Configure"         - id:  "View/Create"         - id:  "View/Delete"         - id:  "View/Read"         - id:  "SCM/Tag"         - id:  "Lockable Resources/Reserve"         - id:  "Lockable Resources/Unlock"         - id:  "Lockable Resources/View"         sids:         -  "admin" 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 "

          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.

          docker run -p 8080:8080 jenkins/jenkins:lts-jdk11 

          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.

          Abhyudaya Sharma added a 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. docker run -p 8080:8080 jenkins/jenkins:lts-jdk11 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.

          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?

          Abhyudaya Sharma added a 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?

          Tim Jacomb added a comment -

          Tim Jacomb added a comment - This issue? https://github.com/jenkinsci/configuration-as-code-plugin/issues/1638

          Malin added a 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

          Malin added a 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

          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.

          Abhyudaya Sharma added a 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.

          Malin added a comment -

          Any idea what might cause this behavior?

          Malin added a comment - Any idea what might cause this behavior?

          Abhyudaya Sharma added a comment - edfa this issue is being discussed here:  https://github.com/jenkinsci/configuration-as-code-plugin/issues/1638  

          Tim Jacomb added a comment -

          This has been fixed on master and is being backported to 2.303.2 as well

          Tim Jacomb added a comment - This has been fixed on master and is being backported to 2.303.2 as well

            basil Basil Crow
            edfa Malin
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: