jenkins
jenkins copied to clipboard
jenkins_private_key_credentials forces id to be UUID when human readable text is allowed
Hi
I was attempting to use the jenkins_private_key_credentials lwrp.
I wanted to pass in a human readable ID because I am going to be using these credentials in job configurations created automatically via the DSL. Per the Job DSL documentation, since version 1.2.1 of the credentials plugin, I should be able to find credentials using the ID instead of the description (https://github.com/jenkinsci/job-dsl-plugin/wiki/Migration#finding-credentials-by-description).
Unfortunately, the lwrp is forcing me to make my credential IDs UUID-formatted.... so instead of "github_key", I'm forced to name it something like "aaaaaaaa-aaaa-4aaa-aaaa-aaaaaaaaaaaa" because of: https://github.com/opscode-cookbooks/jenkins/blob/195c379ea321049f0a7842112b5a93bc54fc28c7/libraries/_helper.rb#L50 https://github.com/opscode-cookbooks/jenkins/blob/master/libraries/credentials_private_key.rb#L40
Also, when you manually configure credentials via the Jenkins UI, you are allowed to use regular human readable text as the ID.
Is there any way to remove this check? Or make this check configurable so I can turn it off? I understand this cookbook is for generic jenkins and this is specific to my plugin version so perhaps just allowing it to be configurable would be a good compromise? Those on the latest plugin can turn the check off, those still on the old plugin can stay the same?
Thanks!
+1 Also having the same issue. Also setting it to some fixed UUID. Would be nice to be able to set the human readable ID
On the other hand though, installing the latest LTS installs the older plugin by default, and you then need to update it to the latest Credentials plugin before you'd be able to use the human readable SSH credential feature.
I'm using human readable text too so I just plop in this quick and dirty monkey patch in my cookbook I use this resource in
# Monkey Patch
class Chef
class Resource::JenkinsPrivateKeyCredentials
attribute :id,
kind_of: String,
regex: /.*/, # Accept anything vs Private Key credentials must still have a UUID based ID
default: lazy { SecureRandom.uuid }
end
end
# End Monkey Patch
Unfortunately, @DanielRedOak's hack isn't enough because there are a bunch of checks for UUID
regexps in the code.
In addition, it looks like a bunch of the jenkins_ssh_slave
credentials code is trying to be clever and detect if an "id" or "username" is being passed in.
I would recommend ditching this smartness and requiring a credentials "ID" everywhere or a credentials Resource (which would have that id).
Here's a better workaround:
require 'securerandom'
require 'chef/mixin/params_validate'
begin
orig_verbose, $VERBOSE = $VERBOSE, nil
Jenkins::Helper::UUID_REGEX = /.*/
ensure
$VERBOSE = orig_verbose
end
resource_class = Chef::ResourceResolver.resolve(:jenkins_private_key_credentials)
resource_class.attribute :id,
kind_of: String,
regex: Jenkins::Helper::UUID_REGEX,
default: Chef::Mixin::ParamsValidate.lazy { SecureRandom.uuid }
Since that's replacing the constant it deals with @docwhat's concerns. Note that if you do this, you'll have to make sure to set the credentials
attribute of your jenkins_ssh_slave
to the credentials id because the hacked UUID_REGEX
won't be able to tell if you're giving it a credentials id or a username.
Seems like if someone makes a PR to fix this it'll need to either get rid of the username thing and only use the credentials id, or do some sort of thing where it tries to find it w/ the id first and then looks to see if it can find credentials with that username, etc.
I'm seeing this too. Not sure if this helps, but for me, the human readable name works on initial creation, but then subsequent chef-client runs, it errors:
STDERR: ERROR: Unexpected exception occurred while performing groovy command.
java.lang.NullPointerException: Cannot get property 'plainText' on null object