-
-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Send email on Workflow Run Success/Failure #34982
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
base: main
Are you sure you want to change the base?
Conversation
replace #33601 |
This comment was marked as resolved.
This comment was marked as resolved.
outdatedAnd by reading the history discussions: I think the concern is not addressed? It looks right, the concerns in "Actions - send Email on Success/Failure #33601" should all be addressed. 🙏 |
GitLab is capable of notifying you when you've "fixed" a pipeline, i.e. if a particular workflow succeeded that previously failed on the same branch. I think it would make sense to implement that if possible (outside of |
@Naxdy Currently, Gitea just mixes all job attempts in a single run, not as GitHub explicitly stating re-run attempts creating a new run ID. Not possible without extra work. Is it actually desired? Personally not adding that here in this PR. afaik GitHub has no notifying successful retries after failure, unless enable successful run notification. |
Thanks for the explanation. And yeah, as of right now, only GitLab has this feature. Perhaps I'll take a crack at it after your PR is merged 🤔 |
Related: #34982 --------- Signed-off-by: NorthRealm <155140859+NorthRealm@users.noreply.github.com> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Is the new table |
@lunny The use of |
I also think it should reuse the existing setting system, instead of introducing a new system. And the existing system is indeed not clear, it needs refactoring and improvements. |
probably just add a "previousRunFailed" property to the event then it should be easy to make conditions for it based on user configuration |
|
||
recipients := make([]*user_model.User, 0) | ||
|
||
if !sender.IsGiteaActions() && !sender.IsGhost() && sender.IsMailable() { |
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.
Why checking sender's preference rather than receivers?
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.
@lunny Currently in the code the sender is the receiver. Only the sender goes receiver list.
#34982 (comment)
#34982 (comment)
Closes #23725
/claim #23725