Generic before_run/after_run hooks

[cornerman]

I often find myself wanting to do something whenever a stack is run (it might be created or updated or was unchanged).

Use-Case: I create an s3-bucket in a cloudformation stack. Whenever I run this stack, I want to automatically copy certain files to the bucket (and update them if they have changed). So, what I am currently doing is: create a after_create and before_update hook, then do an aws s3 sync within these hooks.

Afaik, the meaning of the before_update hook will be changed to be symmetric with after_update, so this configuration would not work for me anymore. Furthermore, I always have to define multiple hooks and before_update is anyhow not really what I want.

Can we create a more generic hooks, which is run whenever a stack is processed? Any other ideas to achieve this?

[ngfgrant]

@cornerman The opening sentence triggered a memory about another previous issue. Can you check to see if this issue: #208 and #219 is what you were thinking?

[cornerman]

@ngfgrant I think, the use-case is exactly the same as in the two issue you have linked. Though, the before_launch and after_launch hooks might be an easier implementation and less verbose than adding run: always or run: conditional to existing hooks. The question is, do we need to distinguish create and update events here or is it just about a stack being launched. If it is the latter, I would be in favor of the more simple launch hooks (see #748). Or am I overlooking something?

[cornerman]

@ngfgrant I would really love to have a solution for this problem and I am definitely here to help.

Looking at it as a newcomer who started using sceptre this year somewhere in the beginning of June, the related issues #208 and #219 were opened about 2 year ago. This proposal is now here for 3 months. I am not judging any of this, but I think a lot of people would get a lot of value from an update. As described in my previous post, I think that a lot of use-cases can be built by just adding these two generic hooks. And this can be implemented in a very simple way in the current architecture (see #748). How about we just merge that solution and then have time to come up with a more sophisticated solution? If we decide that this was a bad idea or does not fit a new revised scheme of how update hooks work, we can still deprecate these hooks.

[ngfgrant]

Hey @cornerman

I am very grateful that you have taking time to make the tool better.

The honest truth is that with this one I want to test it a bit more and it’s just taken a back burner to the work that Cloudreach want me to work on just now.

I don’t think there will be any issues but need to check how the decorators that are on update and create will interplay here.

It’s definitely not a no but just a case of I’ll try get round to it as soon as I can.

[cornerman]

Thank you very much for your response! I am very grateful for this awesome tool 🥇

Of course, please take your time to evaluate the changes. Let me know if there is something that needs to be improved.

[tgod]

Hi! Is there any update about this feature request?
I think it would be really useful to have hooks like that.