[WIP/RFC] Integrate hooks into stack execution graph #722
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.
Make hooks "first-class" citizens in the Stacker execution engine, allowing them to depend on/be depended upon by stacks and targets.
This is not yet 100% complete, but I'm posting to gather some early reviews and advice on the config changes needed.
There are two new top level config. keys introduced:
build_hooks
anddestroy_hooks
. They contain lists of hooks specifications, much like what was already present in{pre,post}_{build,destroy}
. But the hooks in there are expected to order themselves in relation to stacks using therequires
/required_by
keys or lookups (which are now resolved), very much like stacks themselves.Hooks now also should retrieve a
boto3.Session
usingProvider.get_session
, respecting theprofile
andregion
options they now have.Apologies for the size of the changes, but this required some deep refactorings.
Hook
s andTarget
s have changed, hooks now have much more logic, and targets get synthetically generated to help order the "legacy" pre/post action hooks.outputs
variable ofStack
that was manually set by actions is removed, in favor of always asking theProvider
for that information. That might cause a little bit of slowdown in execution, but that can be solved in a more clean way by doing the caching transparently in theProvider
.plan
function was moved to insideAction
s to be able to more easily use it's information.Hook
class.There are a couple of additional unrelated changes currently still in this branch. I initially made them to be able to use the AWS Account ID as part of the bucket name in some tests, but I figured out they are not strictly needed. I will refactor them out, but can still make separate PRs if they seem useful.
Join
s to concatenate variable parts if needed.awsparam
lookup that can interpolate CloudFormation pseudo-parameters into strings. ex:${awsparam AccountID}
This depends on #714. A few tests were refactored to use pytest fixtures when appropriate (for example, to properly handle creation of boto3 clients with different regions).