sous-chefs / jenkins

Development repository for the jenkins cookbook
https://supermarket.chef.io/cookbooks/jenkins
Apache License 2.0
424 stars 636 forks source link

jenkins_user updated every run if full_name not specified #411

Open dpetzel opened 8 years ago

dpetzel commented 8 years ago

I am defining a jenkins_user as outlined in the readme, and I am seeing the resource is flagged as updated every chef run.

.. the code for loading the private key from readme
jenkins_user 'mine' do
  public_keys [public_key]
end

NOTE not passing in the full_name attribute

I've done a little debugging, and here is what I'm seeing when the user has already been created. In the create action there is this check:

      if current_resource.exists? &&
         current_resource.full_name == new_resource.full_name &&
         current_resource.email == new_resource.email &&
         current_resource.public_keys == new_resource.public_keys
        Chef::Log.debug("#{new_resource} exists - skipping")

Stepping through each of these in sequence we get the following:

[1] pry(#<Chef::Provider::JenkinsUser>)> current_resource.exists?
=> true

[2] pry(#<Chef::Provider::JenkinsUser>)> current_resource.full_name == new_resource.full_name 
=> false

[3] pry(#<Chef::Provider::JenkinsUser>)> current_resource.full_name
=> "mine"

[4] pry(#<Chef::Provider::JenkinsUser>)> new_resource.full_name
=> nil

Since I've not passed in full_name new_resource.full_name is nil, but current resource has a value, thus evaluating to false. I was able to work around this pretty easily by providing the full_name attribute in my recipe, but figured I'd open this for a future fix

carpnick commented 8 years ago

We hit this too. It was especially bad with Active Directory integration. The full Name was not known by us until we added it to Jenkins. (Service account - and casing was different - we didnt enter it into AD). So we saw this firsthand, and just figured out what the full_name was suppose to be.

Just including another use case you might see this.