jenkins icon indicating copy to clipboard operation
jenkins copied to clipboard

jenkins_private_key_credentials forces id to be UUID when human readable text is allowed

Open chhsiung opened this issue 9 years ago • 5 comments

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!

chhsiung avatar Jun 09 '15 22:06 chhsiung

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

tchdp avatar Aug 03 '15 21:08 tchdp

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

DanielRedOak avatar Feb 17 '16 18:02 DanielRedOak

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

docwhat avatar Jul 12 '16 20:07 docwhat

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.

b-dean avatar Sep 30 '16 19:09 b-dean

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

chazzly avatar Feb 28 '17 19:02 chazzly