• job-dsl-plugin 1.78, job-dsl-plugin 1.80

      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.

       

       

          [JENKINS-44681] JobDSL Folder Creation Destroys Credentials

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

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

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

          Omit Rathore added a comment -

          Please provision a way to ignore existing folder

          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.

          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.

          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

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

          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. 

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

          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.

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

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

          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.

          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.

          Jamie Tanna added a comment - - edited

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

          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 

          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?

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

          Jamie Tanna added a comment -

          Happy to say this is now closed folks!

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

          Jamie Tanna added a comment -

          1.80 has also been released to fix this for organisation folders :+1:

          Jamie Tanna added a comment - 1.80 has also been released to fix this for organisation folders :+1:

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

              Created:
              Updated:
              Resolved: