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

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

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Fixed
    • core
    • Jenkins: 2.303.1
      folder-auth: 1.3
      configuration-as-code: 1.52
    • 2.313

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

       

       

       

      Attachments

        Issue Links

          Activity

            edfa Malin created issue -
            edfa Malin made changes -
            Field Original Value New Value
            Description After upgrading to LTS 2.303.1, Jenkins fails to start at ConfigurationAsCode.init.

            *Log excerpt:*
            {code:java}
            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.
            {code}
            (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.

             

             

             
            After upgrading to LTS 2.303.1, Jenkins fails to start at ConfigurationAsCode.init.

            *Log excerpt:*
            {code:java}
            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.
            ...{code}
            (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.

             

             

             

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

            abhyudaya Abhyudaya Sharma added a comment - Oops, looks like something broke in Jenkins core. Taking a look...
            abhyudaya 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 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?
            edfa 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).

            edfa 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 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?
            edfa 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"
            edfa 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 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 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?
            timja Tim Jacomb added a comment - This issue? https://github.com/jenkinsci/configuration-as-code-plugin/issues/1638
            edfa 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

            edfa 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
            abhyudaya Abhyudaya Sharma made changes -
            Attachment image-2021-09-03-08-47-08-300.png [ 56273 ]
            abhyudaya Abhyudaya Sharma made changes -
            Attachment image-2021-09-03-08-47-54-600.png [ 56274 ]
            abhyudaya Abhyudaya Sharma made changes -
            Attachment image-2021-09-03-08-50-13-200.png [ 56275 ]

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

            Any idea what might cause this behavior?

            edfa Malin added a comment - Any idea what might cause this behavior?
            abhyudaya Abhyudaya Sharma added a comment - edfa this issue is being discussed here:  https://github.com/jenkinsci/configuration-as-code-plugin/issues/1638  
            basil Basil Crow made changes -
            Assignee Abhyudaya Sharma [ abhyudaya ] Basil Crow [ basil ]
            basil Basil Crow made changes -
            Component/s core [ 15593 ]
            Component/s configuration-as-code-plugin [ 23170 ]
            Component/s folder-auth-plugin [ 25627 ]
            basil Basil Crow made changes -
            Labels lts-candidate
            basil Basil Crow made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            basil Basil Crow made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            basil Basil Crow made changes -
            Remote Link This issue links to "jenkinsci/jenkins#5723 (Web Link)" [ 26913 ]
            danielbeck Daniel Beck made changes -
            Labels lts-candidate lts-candidate regression
            basil Basil Crow made changes -
            Link This issue relates to JENKINS-66271 [ JENKINS-66271 ]
            bmunoz Beatriz Muñoz made changes -
            Labels lts-candidate regression 2.303.2-fixed regression
            timja Tim Jacomb added a comment -

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

            timja Tim Jacomb added a comment - This has been fixed on master and is being backported to 2.303.2 as well
            timja Tim Jacomb made changes -
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Resolved [ 5 ]
            markewaite Mark Waite made changes -
            Released As 2,313
            markewaite Mark Waite made changes -
            Released As 2,313 2.313
            markewaite Mark Waite made changes -
            Status Resolved [ 5 ] Closed [ 6 ]

            People

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

              Dates

                Created:
                Updated:
                Resolved: