Closed Bug 976639 Opened 11 years ago Closed 10 years ago

Implement Puppet validation and lint in Jenkins

Categories

(Socorro :: Infra, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dmaher, Assigned: dmaher)

References

Details

Much as we do pep8 and pylint checks against Python code, it would be useful to do puppet validation and lint checks against Puppet manifests, too. This would require the Jenkins test environment to have access to Ruby and a handful of gems (notably puppet and puppet-lint), and then : puppet parser validate <manifest.pp> puppet-lint <manifest.pp>
Depends on: 977147
While I am generally happy with the style guide as it stands - and, by extension, the way in which puppet-lint analyses manifests - there are certain aspects of it which we may wish to modify or disable for our use case. Off the top of my head, I'm think that we disable line-length warnings (--no-80chars-check), and the auto-loader check (--no-autoloader_layout-check) - the latter only until we actually start using more than a single manifest file. Regarding :lonnen's comment[1] about the class inheritance check (--no-class_inherits_from_params_class-check), it is my stance that this check should remain active, since Puppet inheritance is a deep, dark morass, and it needs to be treated with the utmost care. Comments ? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=976547#c3
I like the style guide, but the automation is a sticky point. Puppet is edited so rarely that adding ruby to our builds doesn't seem worthwhile. We could add it as an additional step in our CI, but I'm not sure I want to ask users to have ruby and python and node to build from source.
To be fair, by introducing Puppet into the equation at all, we've already (tacitly) made Ruby part of the stack. I'm not advocating that we start developing other components in Ruby per se, nor I am I suggesting that it be a required element for every installation; however, if we choose to distribute code, then we should also choose to validate that code. In this case, that means Ruby availability in our CI. Of course, in any context where somebody actually wants to use those Puppet manifests, they'll need Ruby too. As for Puppet being modified rarely - that's only because I haven't yet been unleashed on it. ;)
pinging :bramwelt and :rhelmer for input
(In reply to Chris Lonnen :lonnen from comment #2) > I like the style guide, but the automation is a sticky point. Puppet is > edited so rarely that adding ruby to our builds doesn't seem worthwhile. We > could add it as an additional step in our CI, but I'm not sure I want to ask > users to have ruby and python and node to build from source. We recently added ruby as a build dependency (for fpm)
Go for it. Now I need to find a go build dep...
Assignee: nobody → dmaher
Status: NEW → ASSIGNED
From :rhelmer on Github: > r+, but do we have puppet-lint on Jenkins already? The puppet-lint is package is installed on Jenkins (via Puppet), as well as installed as a gem, and the two have different versions. Likely what happened is that some<body|thing> installed the gem without looking to see if the package was already present. Both versions are highly outdated. I have modified the package resource in Puppet to ensure the (modern) gem instead of the old and busted package: Index: modules/jenkins/manifests/master.pp =================================================================== --- modules/jenkins/manifests/master.pp (revision 93870) +++ modules/jenkins/manifests/master.pp (working copy) @@ -86,12 +86,13 @@ 'protobuf-compiler', 'protobuf-python', 'protobuf-devel', - 'rubygem-puppet-lint', ]: ensure => present, require => Yumrepo["epel"]; - + 'puppet-lint': + ensure => present, + provider => 'gem'; } service { Furthermore I have updated the gem on Jenkins to 1.1.0 manually: [dmaher@jenkins1.dmz.phx1 ~]$ puppet-lint --version puppet-lint 1.1.0
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 105
You need to log in before you can comment on or make changes to this bug.