-
Notifications
You must be signed in to change notification settings - Fork 16.4k
Add general-purpose "notifier" concept to DAGs #28569
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Taragolis
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love the idea. Just couple of findings
db0a827 to
ed5d175
Compare
|
What I'm finding out now is that this solution is not backward-compatible for providers |
Maybe we could mark it as Optional feature by raise |
Awesome. Didn't know that existed. Thanks |
013dbb9 to
afc3732
Compare
fb2658d to
ee928bb
Compare
ee928bb to
5c329c8
Compare
|
Good candidate to be added to #28300 - I will add it there once merged. |
|
@jedcunningham @uranusjr @dstandish, can you also take a look |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we put this default value to a module-level constant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also referencing the main branch is probably a bad idea; we want something more permanent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Linked to a previous release, how's that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably better linking to a commit, but I guess we have enough dev infra around this a tag is immutable-ish enough.
e5cb596 to
3a0b79b
Compare
This makes it easy for users to setup notifications for their DAGs using on_*_callbacks It's extensible and we can add it to more providers. Implemented a SlackNotifier in this phase. In the course of this, I extracted a 'Templater' class from AbstractBaseOperator and have both the Notifier & ABO inherit from it. This is necessary in other to avoid code repetition.
Co-authored-by: Tzu-ping Chung <uranusjr@gmail.com>
docs/apache-airflow-providers-slack/notifications/slack_notifier_howto_guide.rst
Show resolved
Hide resolved
kaxil
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add docs for this feature @ephraimbuddy ? Currently this feature is a "hidden" one
Agree we should. |
Seeing this now. There's a doc on it: http://apache-airflow-docs.s3-website.eu-central-1.amazonaws.com/docs/apache-airflow-providers-slack/latest/notifications/slack_notifier_howto_guide.html |
What I think @kaxil (I for sure) mean is that this adds "base" notifier and "generic" approach that could be extended by anyone. Similarly as other "core extensions" - I think we need some generic description on how one can extend and write their own notifiers (or at the very least information that one CAN actually do it) Similar docs are here for logging, extra links, logging, secret backends - look here (there are links to generic airlfow how-tos from there) https://airflow.apache.org/docs/apache-airflow-providers/core-extensions/index.html |
Fixed: #29191 |
This makes it easy for users to setup notifications for their DAGs using on_*_callbacks It's extensible and we can add it to more providers. Implemented a SlackNotifier in this phase.
In the course of this, I extracted a 'Templater' class from AbstractBaseOperator and have both the Notifier & ABO inherit from it. This is necessary in other to avoid code repetition.
Closes: #28405