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

          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: