(maint) Fix expect_upload for module relative paths outside files #3238
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I'll deal with my offenses to the linting gods; but I'm not entirely certain about this patch either way. Even an expect_upload('amodule/resources/bar') is a bit odd, since you'd be inclined to think it was really 'amodule/files/resources/bar'. Not sure what the ideal behavior is here or if this is worth patching. |
The expect_upload() BoltSpec expectation for upload_file calls in plans
handled two cases:
Given a /my/modules/amodule with
/my/modules/amodule/files/foo
/my/modules/amodule/resources/baz
/my/modules/amodule/plans/bar
expect_upload('/some/thing') would correctly match against an
upload_file('/some/thing') in plan bar, because it is not relative to
the modulepath at all, and against an upload_file('amodule/foo'),
because it is relative to amodule, and foo is relative to files,
which expect_upload elides when the MockExecutor runs the source_path
through BotlSpec::MockExecutor#module_file_id.
The edge case that was peculiar was a call to
upload_file('amodule/files/../resources/baz'), which expect_upload
would end up expecting as 'amodule/baz'.
The hidden behavior here is that Bolt::Util.find_file* functionality
will take 'foo/bar' and look for /modulepath/foo/files/bar, which is
mirroring Puppety behavior to find module files relative to the files/
dir.
jpartlow
force-pushed
the
maint-fix-expect-upload-for-module-relative-outside-files
branch
from
6a424e4
to
19f0469
Compare
|
Would also need some fiddling to make the module_file_id tests OS agnostic, or drop them. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The expect_upload() BoltSpec expectation for upload_file calls in plans handled two cases:
Given a /my/modules/amodule with
/my/modules/amodule/files/foo
/my/modules/amodule/resources/baz
/my/modules/amodule/plans/bar
expect_upload('/some/thing') would correctly match against an upload_file('/some/thing') in plan bar, because it is not relative to the modulepath at all, and against an upload_file('amodule/foo'), because it is relative to amodule, and foo is relative to files, which expect_upload elides when the MockExecutor runs the source_path through BotlSpec::MockExecutor#module_file_id.
The edge case that was peculiar was a call to
upload_file('amodule/files/../resources/baz'), which expect_upload would end up expecting as 'amodule/baz'.
The hidden behavior here is that Bolt::Util.find_file* functionality will take 'foo/bar' and look for /modulepath/foo/files/bar, which is mirroring Puppety behavior to find module files relative to the files/ dir.