You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is better for uses to have choice that st2.generic.actiontrigger be emitted not only on action complete, but when an action or workflow is transitioned into requested/scheduled/running state.
ISSUE TYPE
Feature Idea
Detail / Background / Motivation
While I was trying to implement a Slack notification at both start and end of the workflow, I noticed that st2.generic.actiontrigger is only emitted when the workflow reaches LIVEACTION_COMPLETED_STATES, which makes me hard to implement a notification for the start of the workflow.
My idea is to use st2.generic.actiontrigger and write a rule that hook state=running|succeeded by criteria, then run a Slack sendMessage action. I think this is the best approach and design because the target workflow that will be notified on start/end is completely separated from any of the notification code. So notification part is like an aspect and we can weave that into any workflow you like by writing a rule. I can clearly keep a separation of responsibility principle. Some examples:
All those configuration parameters needed for notification like tokens, channels, etc does not exist in the workflow code itself
The notification rules can even be placed in a different pack and separated from the release cycle of those core workflows (which are tend to be more important than notifications since they do real business logic)
If you want to weave notification, then you don't need to modify the target workflow. All you need is to write a rule. This makes us easy to add notification to the exchange pack workflows.
This is fairly easy to implement, but an impact to performance needs to be considered. So I think it is better to have a new config parameter and make this feature opt-in, like this.
The text was updated successfully, but these errors were encountered:
SUMMARY
It is better for uses to have choice that
st2.generic.actiontrigger
be emitted not only on action complete, but when an action or workflow is transitioned into requested/scheduled/running state.ISSUE TYPE
Detail / Background / Motivation
While I was trying to implement a Slack notification at both start and end of the workflow, I noticed that
st2.generic.actiontrigger
is only emitted when the workflow reaches LIVEACTION_COMPLETED_STATES, which makes me hard to implement a notification for the start of the workflow.My idea is to use
st2.generic.actiontrigger
and write a rule that hookstate=running|succeeded
by criteria, then run a Slack sendMessage action. I think this is the best approach and design because the target workflow that will be notified on start/end is completely separated from any of the notification code. So notification part is like an aspect and we can weave that into any workflow you like by writing a rule. I can clearly keep a separation of responsibility principle. Some examples:This is fairly easy to implement, but an impact to performance needs to be considered. So I think it is better to have a new config parameter and make this feature opt-in, like this.
The text was updated successfully, but these errors were encountered: