Open irvingpop opened 7 years ago
Yup, there is a rescue here that will always trigger in the Deploy phase. This causes errors in Deploy for instances where the default workspace path is not used (e.g Windows Build Nodes).
I agree that the issue is caused by calling DeliverySugar::ChefServer.new.with_server_config
from within DeliveryTruck::Helpers::Deploy
without passing the node
object thus causing change
to fail to initialize (and triggering the rescue)
Here is the code path that leads to an error (based on my understanding):
DeliveryTruck::Helpers::DSL.delivery_chef_server_search
is calledDeliveryTruck::Helpers::Deploy
method is called (no node
object passed)DeliverySugar::ChefServer
is initialized without argumentsDeliverySugar::DSL.delivery_knife_rb
is calledDeliverySugar::DSL.delivery_workspace
is calledDeliverySugar::DSL.change
is calledchange
object fails to initialize because node
does not existrescue
is triggered in DeliverySugar::DSL.delivery_workspace
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.