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

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

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!

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.

 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

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

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.

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

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.

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 

daspilker - any chance the above PR could get reviewed?

Happy to say this is now closed folks!

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