-
Notifications
You must be signed in to change notification settings - Fork 87
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
Normalize file resource titles #176
Conversation
I'll investigate these build failures. I can't reproduce them locally but I suspect the integration tests are also not running locally... |
You can run all of the integration tests like so:
In this case the one integration test that seems to be failing is this one:
It looks like Puppet doesn't like the space between Also 🤞 that #178 will improve things on our Travis CI builds. |
We've noticed a problem at Braintree along the lines of: file { '/foo': ensure => directory, } file { '/bar': ensure => directory, require => File['/foo/'], } This catalog compiles and is valid, but fails validation in octocatalog-diff. It seems that puppet itself attempts to normalize file resource titles (and indeed can normalize any type of resource title, given that a methodology exists in the resource type). See: https://github.com/puppetlabs/puppet/blob/4.10.x/lib/puppet/type/file.rb#L42 This commit attmepts to mimic that (and lifts the regex directly from the 4.10.x branch of puppet, because it doesn't matter in puppet 5 since reference validation is built-in).
It's days like these that I'm reminded that I'm really not an app developer anymore. ^_^ Integration tests passed locally after fixing that spacing issue and you know, actually running them - I've squashed the fixes and hopefully the builds pass in CI this time around. :) |
Hey @ahayworth great news -- it looks like CI is passing now. 😸 👍 Are you finished working on this now, and ready for me to put it through our normal pre-release testing? Or do you still have additional work before we test it? |
As far as I know, it’s done. This solves the problems we were seeing in our env. Test away! 😁
- Andrew Hayworth
… On Feb 14, 2018, at 4:13 PM, Kevin Paulisse ***@***.***> wrote:
Hey @ahayworth great news -- it looks like CI is passing now. 😸 👍
Are you finished working on this now, and ready for me to put it through our normal pre-release testing? Or do you still have additional work before we test it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Sounds great, thank you!
- Andrew Hayworth
… On Feb 28, 2018, at 3:42 PM, Kevin Paulisse ***@***.***> wrote:
I've merged this into #180 so my current plan is to test #180 internally at GitHub and then once that is 👍 merge both at the same time.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Overview
This pull request slightly relaxes validation for (require/before/subscribe/notify) and friends on file resource types. Or rather, more closely matches puppet behavior.
We've noticed a problem at Braintree along the lines of:
This catalog compiles and is valid, but fails validation in octocatalog-diff.
It seems that puppet itself attempts to normalize file resource titles (and indeed
can normalize any type of resource title, given that a methodology exists in the
resource type). See:
https://github.com/puppetlabs/puppet/blob/4.10.x/lib/puppet/type/file.rb#L42
This commit attmepts to mimic that (and lifts the regex directly from the 4.10.x
branch of puppet, because it doesn't matter in puppet 5 since reference validation
is built-in).
This fixes #174 . NB - I made a mistake in the original commit message around which specific resource requirements were incorrectly flagged as invalid; this PR message is accurate.
Checklist
rake
in your checkout directory, or review the CI job triggered whenever you push to a pull request.rake coverage:spec
or ignoring untestable sections of code with# :nocov
comments. If you need help getting to 100% coverage please ask; however, don't just submit code with no tests.