Support job-dsl for string credentials

[jemand771]

i.e.

folder('my-folder') {
  displayName('My Folder')
  properties {
    folderCredentialsProperty {
      domainCredentials {
        domainCredentials {
          domain {
            name('_')
            description('Credentials that should be available everywhere.')
          }
          credentials {
            string {
              scope('GLOBAL')
              id('my-cool-token')
              description('Very secret access token')
              secret(hudson.util.Secret.fromString('aaa'))
            }
          }
        }
      }
    }
  }
}

now works. previously, you'd have to abuse username+password credentials for this (and just put garbage in the username)

Testing done

• try applying the config above with plain-credentials 199.v9f8e1f741799 -> does not work
• build and deploy from this branch
• try applying again -> works

I haven't looked into automated testing yet and am unsure if it's worth bothering for such a trivial change.
mvn clean verify still passes, so no obvious regressions there

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• n/a Link to relevant issues in GitHub or Jira
• n/a Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[jtnord]

generally symbols are global and string is already in use with the credential-binding-plugin . Did you test this with that plugin installed to ensure that

1. the job-dsl script continues to function as expected
2. pipelines using a string credential binding continue to function as expected

[jemand771]

actually, yes, but not intentionally. credentials-binding is installed and I am using withCredentials to access this exact string credential in my real setup.

On the actual implementation, I honestly have no idea what the implications are, if any - the line you linked is what inspired me to make this seemingly trivial change to begin with (I thought @Symbol was what "makes job-dsl work")

[jglick]

symbols are global

They are scoped to an extension type. Check the Javadoc.

[jglick]

Probably, but rather than job-dsl check that this solves a problem in https://github.com/jenkinsci/configuration-as-code-plugin/tree/master/integrations/src/test

[jglick]

(Or could JCasC as a test dep here and put the assertion here.)