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

JobDSL Folder Creation Destroys Credentials

    XMLWordPrintable

Details

    • job-dsl-plugin 1.78

    Description

      When using job-dsl-plugin to create a folder 

      folder(my_folder) { 

        displayname("my_folder_name")

      }

      If the folder exists with Credentials attached to it, they are lost on recreation  . Is there anyway to wrap this in a conditional? if!(folder(my_folder) {blah..blah....}.  I believe the desired behaviour here is to not blow away the credentials attached at the folder level.

       

       

      Attachments

        Issue Links

          Activity

            The credentials on folder level are stored in the folder configuration. When a folder is generated by Job DSL, the whole configuration is replaced by the configuration described in Job DSL. So the credentials get lost, when running the seed job.

            I do not recommend to specify credentials in DSL scripts. But you can use the Jenkins API to copy the existing credentials configuration to the Job DSL definition:

            import jenkins.model.Jenkins
            import hudson.model.Item
            import hudson.model.Items
            
            String FOLDER_CREDENTIALS_PROPERTY_NAME = 'com.cloudbees.hudson.plugins.folder.properties.FolderCredentialsProvider$FolderCredentialsProperty'
            
            Node folderCredentialsPropertyNode
            Item myFolder = Jenkins.instance.getItem('my-folder')
            if (myFolder) {
              def folderCredentialsProperty = myFolder.getProperties().getDynamic(FOLDER_CREDENTIALS_PROPERTY_NAME)
              if (folderCredentialsProperty) {
                String xml = Items.XSTREAM2.toXML(folderCredentialsProperty)
                folderCredentialsPropertyNode = new XmlParser().parseText(xml)
              }
            }
            
            folder('my-folder') {
              if (folderCredentialsPropertyNode) {
                configure { project ->
                  project / 'properties' << folderCredentialsPropertyNode
                }
              }
            }
            
            daspilker Daniel Spilker added a comment - The credentials on folder level are stored in the folder configuration. When a folder is generated by Job DSL, the whole configuration is replaced by the configuration described in Job DSL. So the credentials get lost, when running the seed job. I do not recommend to specify credentials in DSL scripts. But you can use the Jenkins API to copy the existing credentials configuration to the Job DSL definition: import jenkins.model.Jenkins import hudson.model.Item import hudson.model.Items String FOLDER_CREDENTIALS_PROPERTY_NAME = 'com.cloudbees.hudson.plugins.folder.properties.FolderCredentialsProvider$FolderCredentialsProperty' Node folderCredentialsPropertyNode Item myFolder = Jenkins.instance.getItem( 'my-folder' ) if (myFolder) { def folderCredentialsProperty = myFolder.getProperties().getDynamic(FOLDER_CREDENTIALS_PROPERTY_NAME) if (folderCredentialsProperty) { String xml = Items.XSTREAM2.toXML(folderCredentialsProperty) folderCredentialsPropertyNode = new XmlParser().parseText(xml) } } folder( 'my-folder' ) { if (folderCredentialsPropertyNode) { configure { project -> project / 'properties' << folderCredentialsPropertyNode } } }
            marcus_phi Marcus Philip added a comment -

            I think it's incorrect to close this as not a defect. It's not how JobDSL works in general in other cases. Normally it's idempotent. Also the jobDSL folder docs in api viewer says: "Creates or updates a folder".

            Please reconsider.

            marcus_phi Marcus Philip added a comment - I think it's incorrect to close this as not a defect . It's not how JobDSL works in general in other cases. Normally it's idempotent. Also the jobDSL folder docs in api viewer says: "Creates or updates a folder". Please reconsider.

            Thanks daspilker for your solution. That worked out quite well in my case.

            Kind regards

            Jürgen

            jbob_jenkins Jürgen Bobinger added a comment - Thanks daspilker for your solution. That worked out quite well in my case. Kind regards Jürgen
            jedi_lewis Jedi Lewis added a comment -

            We're running into this bug as well, can this be re-opened please? Running "folder()" on an existing folder shouldn't wipe out all metadata attached to the folder. This includes views and folder scoped credentials. 

            Thanks!

            jedi_lewis Jedi Lewis added a comment - We're running into this bug as well, can this be re-opened please? Running "folder()" on an existing folder shouldn't wipe out all metadata attached to the folder. This includes views and folder scoped credentials.  Thanks!
            orathore Omit Rathore added a comment -

            Please provision a way to ignore existing folder

            orathore Omit Rathore added a comment - Please provision a way to ignore existing folder

            I also vote for updating folder properties vs overwriting those. Please add this support. Thanks a bunch in advance.

            nrayapati Naresh Rayapati added a comment - I also vote for updating folder properties vs overwriting those. Please add this support. Thanks a bunch in advance.

             I would also favor an update / merge strategy instead of an hard override. Otherwise it becomes impossible to let users enter the credentials in the live system while maintaining the basic structure of folders via JobDSL.

            f4674bee_ac86_4a7b_8234_5b7802883f6b Riccardo Boettcher added a comment -  I would also favor an update / merge strategy instead of an hard override. Otherwise it becomes impossible to let users enter the credentials in the live system while maintaining the basic structure of folders via JobDSL.

            That worked for me. One suggestion, use getItemByFullName() instead of getItem() to capture the credentials at sub folder level

            mramaraju0461 Venkata Mudunuri added a comment - That worked for me. One suggestion, use getItemByFullName() instead of getItem() to capture the credentials at sub folder level
            sype Sean Sype added a comment -

            This would be nice so we can have separated credentials and allow users access to their "own" without having to re-create every time. 

            sype Sean Sype added a comment - This would be nice so we can have separated credentials and allow users access to their "own" without having to re-create every time. 
            tony_k tony kerz added a comment -

            i have a job that creates jobs in a tree, like:

             

            foo/bar/baz/job-1

            foo/bar/baz/job-2

            etc

             

            and i placed creds at the foo folder level, but every time i create another foo/bar/baz/job-x it blows away the creds at the foo folder!

            not expected behavior and kind of a hassle to work around, i agree with folks on this thread that think that creds at existing folders should not be effected in this way...

             

            tony_k tony kerz added a comment - i have a job that creates jobs in a tree, like:   foo/bar/baz/job-1 foo/bar/baz/job-2 etc   and i placed creds at the foo folder level, but every time i create another foo/bar/baz/job-x it blows away the creds at the foo folder! not expected behavior and kind of a hassle to work around, i agree with folks on this thread that think that creds at existing folders should not be effected in this way...  

            Same issue here - its makes hard in our use case to manage auto-creation of folders and jobs. I would also favor an update/merge strategy instead of a hard override.

            slowikone Bartlomiej Slowik added a comment - Same issue here - its makes hard in our use case to manage auto-creation of folders and jobs. I would also favor an update/merge strategy instead of a hard override.

            The deletion of credentials is so unexpected. I just lost 95 folders with 100s of credentials due to this. I cannot express how frustrating this is.

            I was able to recover most via the Job Config History plugin, but apparently "Secret File" credentials are magic and seem to be truly gone.

            docwhat Christian Höltje added a comment - The deletion of credentials is so unexpected. I just lost 95 folders with 100s of credentials due to this. I cannot express how frustrating this is. I was able to recover most via the Job Config History plugin, but apparently "Secret File" credentials are magic and seem to be truly gone.

            The suggestion in the first comment works, but only if not running in the groovy sandbox, or the user running the job is an admin (otherwise, every change to scripts needs to be approved by an admin).

            gpaciga Gregory Paciga added a comment - The suggestion in the first comment  works, but only if not running in the groovy sandbox, or the user running the job is an admin (otherwise, every change to scripts needs to be approved by an admin).
            jamietanna Jamie Tanna added a comment -

            I've been looking into this today, and have found a way to handle this within the plugin itself (via the IntelliJ debugger). I am going to be working on integrating this into the plugin itself, then will raise a PR on GitHub.

            jamietanna Jamie Tanna added a comment - I've been looking into this today, and have found a way to handle this within the plugin itself (via the IntelliJ debugger). I am going to be working on integrating this into the plugin itself, then will raise a PR on GitHub.
            jamietanna Jamie Tanna added a comment - - edited

            I've raised https://github.com/jenkinsci/job-dsl-plugin/pull/1232 as a suggested fix for this.

            jamietanna Jamie Tanna added a comment - - edited I've raised https://github.com/jenkinsci/job-dsl-plugin/pull/1232 as a suggested fix for this.

            The workaround suggested by daspilker above no longer works in sandbox mode with the latest version of the script-security plugin due to https://issues.jenkins.io/browse/JENKINS-63788 

            gmtm Graham McGregor added a comment - The workaround suggested by daspilker  above no longer works in sandbox mode with the latest version of the script-security plugin due to https://issues.jenkins.io/browse/JENKINS-63788  

            daspilker - any chance the above PR could get reviewed?

            ftclausen Friedrich Clausen added a comment - daspilker  - any chance the above PR  could get reviewed?
            jamietanna Jamie Tanna added a comment -

            Happy to say this is now closed folks!

            jamietanna Jamie Tanna added a comment - Happy to say this is now closed folks!

            People

              jamietanna Jamie Tanna
              smithx10 Bruce Smith
              Votes:
              12 Vote for this issue
              Watchers:
              24 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: