Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
This resolves issue #946 by solving the issue of inherited dependencies. Turns out, the problem was just a small bug with inherited objects in memory. There was a small bug in the ConfigReader that has to do with the way list-joining works on individual stacks and how dependencies are resolved. The basic situation was this: * Sceptre uses the "list_join" strategy to combine StackGroup dependencies with Stack dependencies. * The list_join strategy creates a NEW list by combining A + B... **but only if both A and B exist**. * In the case where the StackGroup dependencies exist _but there are no Stack dependencies_, Sceptre just selects A and passes each stack in that group the exact same dependencies list (i.e. **same object in memory**) from the StackGroup * The process of resolving stacks replaces the stack string with a Stack object _in place_. * If two stacks have inherited the exact same dependencies list because neither of them defined their own dependencies lists, the first stack to be resolved will replace those objects in memory with Stack objects and the second stack to be resolved will receive those Stack objects rather than strings. * In the attempt to resolve the Stack object (believing it's a string), Sceptre will blow up because you cannot call `.replace()` on a Stack instance. But we don't need to do that at all if it's already a Stack. This PR fixes that bug by skipping resolution for dependencies that are already Stack objects.
- Loading branch information