Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lint task breaks, command line works #253

Closed
daenney opened this issue Feb 13, 2014 · 12 comments · Fixed by #255
Closed

lint task breaks, command line works #253

daenney opened this issue Feb 13, 2014 · 12 comments · Fixed by #255

Comments

@daenney
Copy link

daenney commented Feb 13, 2014

I'm currently running into an issue where puppet-lint . works correctly whereas when I call rake lint it blows up at the end.

rake aborted!

/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/puppet-lint-0.3.2/lib/puppet-lint/tasks/puppet-lint.rb:25:in `block (2 levels) in initialize'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/file_utils_ext.rb:58:in `verbose'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/puppet-lint-0.3.2/lib/puppet-lint/tasks/puppet-lint.rb:13:in `block in initialize'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/task.rb:236:in `call'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/task.rb:236:in `block in execute'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/task.rb:231:in `each'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/task.rb:231:in `execute'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/task.rb:175:in `block in invoke_with_call_chain'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/task.rb:168:in `invoke_with_call_chain'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/task.rb:161:in `invoke'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/application.rb:149:in `invoke_task'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/application.rb:106:in `block (2 levels) in top_level'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/application.rb:106:in `each'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/application.rb:106:in `block in top_level'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/application.rb:115:in `run_with_threads'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/application.rb:100:in `top_level'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/application.rb:78:in `block in run'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/application.rb:165:in `standard_exception_handling'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/lib/rake/application.rb:75:in `run'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/rake-10.1.1/bin/rake:33:in `<top (required)>'
/usr/local/var/rbenv/versions/1.9.3-p484/bin/rake:23:in `load'
/usr/local/var/rbenv/versions/1.9.3-p484/bin/rake:23:in `<main>'

Oddly enough it seems to reach the end of its run, the last file which it prints before blowing up is also the last file the command line checks.

Anyone got a clue?

@ghoneycutt
Copy link
Contributor

A link to the code in question would be helpful.

@daenney
Copy link
Author

daenney commented Feb 13, 2014

Yeah so turned out my previous comment about the difference of the command line run versus the rake run was bogus, I wasn't disabling a check that the rake task was disabling.

I can show you the last file it checks before blowing up if that helps?

@ghoneycutt
Copy link
Contributor

Sure.

@daenney
Copy link
Author

daenney commented Feb 13, 2014

It's not exactly pretty but here you go:

class zookeeper (
  $zookeeper_cluster_nodes = hiera('zookeeper_cluster_nodes'),
  $zookeeper_cluster_size  = hiera('zookeeper_cluster_size'),
  $zookeeper_heap_size     = hiera('zookeeper_heap_size'),
) {

  user { 'zookeeper':
    require    => Package['zookeeper'],
    comment    => 'Zookeeper Node',
    shell      => '/bin/false',
    home       => '/var/lib/zookeeper',
    system     => true,
    ensure     => present,
    managehome => true;
  }

  File { owner => 'root', group => 'root', mode => '0755' }
  file {
    '/etc/zookeeper/zoo.cfg':
      content  => template('zookeeper/zoo.cfg.erb'),
      require => Package['zookeeper'],
      notify  => Service['zookeeper'];
  }

  file {
    ["/srv/data/zookeeper","/srv/log/zookeeper"]:
      require => User['zookeeper'],
      owner   => 'zookeeper',
      group   => 'zookeeper',
      mode    => 700,
      ensure  => directory;
  }

  file { 'myid':
    path => "/srv/data/zookeeper/myid",
    content => template('zookeeper/myid.erb'),
    mode => 644,
    require => File["/srv/data/zookeeper"],
  }

  file { 'default_zookeeper':
    path    => "/etc/default/zookeeper",
    source  => 'puppet:///modules/zookeeper/default_zookeeper',
    mode    => 644,
    require => [Package['zookeeper'],
                File["/srv/data/zookeeper"]],
  }

  file { '/etc/logrotate.d/zookeeper':
    owner  => 'root',
    group  => 'root',
    mode   => 0644,
    source => 'puppet:///modules/zookeeper/zookeeper-logrotate',
  }

  file { 'init_zookeeper':
    path    => "/etc/init.d/zookeeper",
    source  => 'puppet:///modules/zookeeper/init_zookeeper',
    mode    => 755,
    require => [Package['zookeeper'],
                File["/srv/data/zookeeper"]],
  }

  file { 'env_zookeeper':
    path    => "/etc/zookeeper/zookeeper-env.sh",
    source  => 'puppet:///modules/zookeeper/zookeeper-env.sh',
    mode    => 644,
    require => [Package['zookeeper'],
                File["/srv/data/zookeeper"]],
  }

  package {
    'zookeeper':
      require => Class['java'],
      ensure  => present;
  }

  service { 'zookeeper':
    require   => [Package['zookeeper'],
                  File["/srv/data/zookeeper"],
                  File["/srv/log/zookeeper"]],
    hasstatus => true,
    enable    => true,
    ensure    => running;
  }

  class { 'zookeeper::icinga::services':
    zookeeper_cluster_nodes => $zookeeper_cluster_nodes,
    zookeeper_cluster_size  => $zookeeper_cluster_size,
    zookeeper_heap_size     => $zookeeper_heap_size,
  }

}

@ghoneycutt
Copy link
Contributor

I was not able to reproduce with Puppet-lint 0.3.2
Here's the Rakefile I used to run rake lint
https://github.com/ghoneycutt/puppet-module-vim/blob/master/Rakefile

@daenney
Copy link
Author

daenney commented Feb 13, 2014

Our repo right now is one big repo with a modules/ dir that contains all the modules.

require 'puppetlabs_spec_helper/rake_tasks'
require 'puppet-lint/tasks/puppet-lint'

EXCLUDED_MODULES = ['acl', 'apt', 'concat_native', 'ntp', 'rabbitmq',
                    'rvm', 'stdlib', 'templatewlv'].collect { |a| "modules/#{a}" }
PuppetLint.configuration.send('disable_80chars')
PuppetLint.configuration.send('disable_class_inherits_from_params_class')
PuppetLint.configuration.send('disable_class_parameter_defaults')
PuppetLint.configuration.ignore_paths = EXCLUDED_MODULES.collect { |a| "#{a}/**/*.pp"}

EXCLUDED_MODULES is a bit of a hack to exclude upstream modules as I don't want those to fail our tests.

@ghoneycutt
Copy link
Contributor

Not sure, though it is not an issue with puppet-lint. Can you please close?

Recommend you look at https://github.com/bodepd/librarian-puppet-simple. It would simplify your setup and give you per module control instead of this global Rakefile.

@daenney
Copy link
Author

daenney commented Feb 13, 2014

I'm not going to redesign my setup right now just for this. Thanks though.

@daenney daenney closed this as completed Feb 13, 2014
@daenney
Copy link
Author

daenney commented Feb 14, 2014

I'm reopening this. I had a look at the traceback and the line of code it explodes on is in tasks/puppet-lint.rb:

          fail if linter.errors? || (
            linter.warnings? && PuppetLint.configuration.fail_on_warnings
          )

@daenney daenney reopened this Feb 14, 2014
@daenney
Copy link
Author

daenney commented Feb 14, 2014

At least, that's the line the rake aborted seems to get triggered by. If I comment out that block the run finished but of course doesn't exit with a non-zero exit code. However calling fail would be to bail out I guess because puppet-lint did find errors but it causes the rake aborted! warning to pop up.

@daenney
Copy link
Author

daenney commented Feb 14, 2014

What I'm getting at is, I understand now why the rake aborted pops up but perhaps there would be a more user friendly way to handle this than trigger a Runtime error?

@daenney
Copy link
Author

daenney commented Feb 14, 2014

It looks like abort() is a lot more friendly in this case and achieves what I mean, the process will end and exit cleanly with a non-zero exit code whereas fail() seems to be more meant to raise Runtime error's for conditions in your own code.

rodjek pushed a commit that referenced this issue Mar 4, 2014
Instead of fail.

Closes #253
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants