Fix a situation where deploys would fail if the workspace is in a non-standard location #32
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
DeliverySugar::ChefServer
class expects a node object to exist in order for it to look up thedelivery_knife_rb
( here ) , but that doesn't exist the way it's being called fromDeliveryTruck::Helpers::Deploy
.This PR calls the same
delivery_knife_rb
method from DeliverySugar::DSL but in a way that it can succeed by calling it from the DSL method and then passing it to the non-DSL method.As a point of discussion:
The
rescue
inDeliverySugar::DSL.delivery_workspace
( link ) seems like a bad idea, because it's masking a problem where the node object doesn't exist, causing thechange
method to blow up. That should be revisited, I suspect that this is a problem for any customer that uses a non-standard workspace location.It's not clear to me why the
DeliveryTruck::Helpers::DSL.delivery_chef_server_search
method needs to aliasDeliveryTruck::Helpers::Deploy.delivery_chef_server_search
( link ) - it would be helpful if someone with some history could explain that.