Send email on Workflow Run Success/Failure

[NorthRealm]

Closes #23725

/claim #23725

[NorthRealm]

Note: For code reusability, there's a refactor/renaming in mail.go, mail_issue_common.go and mail_test.go in c8b64c7, ed7b2bc

[NorthRealm]

[lunny]

replace #33601

[wxiaoguang]

outdated

And by reading the history discussions:

• Fix #23725: Actions - send Email on Success/Failure #33601 (comment)

I think the concern is not addressed? should we send the email on "workflow job" level, or "workflow run" level? (I am not certain about the details, just FYI)

---

It looks right, the concerns in "Actions - send Email on Success/Failure #33601" should all be addressed. 🙏

[wxiaoguang]

I refer a lot from elsewhere in the whole code base, and I see it potentially reusable/re-applicable if it's been there.

Actually we should never trust existing code, there are bugs and bad-smells. If you just copy-paste existing code, then there will be more bugs and bad-smells.

[wxiaoguang]

Will explain more "bad smells" in old code that I have made changes to:

1. It shouldn't duplicate log.Error when using ServerError which already logs the err
2. It shouldn't show 500 error page when the user input is invalid.
3. It shouldn't set selected active for a dropdown item, selected and active have different meanings
4. It shouldn't duplicate {{if eq ...}}selected{{end}} when using dropdown, the input value is the selected one and the framework already handles it
5. It shouldn't duplicate rel="noopener noreferer", it only makes the translation more difficult (the affect has been explained above)

---

Actually I can tolerate the nits in code (not serious bugs) if the PR was reviewed and merged by others, or I missed some of them. While if I am reviewing or writing code, I will always do my best to avoid the bad smells.

[ankurk91]

@lunny
this will land in 1.25?😬 please

[wxiaoguang]

Yes, it is in 1.25, great thanks to @NorthRealm and reviewers 🎉

You can use it by the nightly build:

• https://dl.gitea.com/gitea/main-nightly/
• https://hub.docker.com/r/gitea/gitea/tags?name=nightly

[ghnp5]

Thank you so much for this!! 🥳🎉🧡

[inxcts]

@NorthRealm
How do I activate this feature? I have set up the mailer and the mailer seems to work. When clicking the Test button in the settings, the email is sent successfully. However, if a Action run fails, I do not get any emails.

[NorthRealm]

@inxcts [service] ENABLE_NOTIFY_MAIL=true

[inxcts]

@inxcts [service] ENABLE_NOTIFY_MAIL=true

I also set this variable to true and restarted Gitea. When an action run fails, I still do net any emails. I still something is still missing.

[NorthRealm]

@inxcts I'm pretty sure that's the key. Manually tested on local instance (localhost) and it's working as intended. Do you have a valid email address in your account? Is your mailbox provider putting gitea emails into spam folder?

[inxcts]

@NorthRealm

@inxcts I'm pretty sure that's the key. Manually tested on local instance (localhost) and it's working as intended. Do you have a valid email address in your account? Is your mailbox provider putting gitea emails into spam folder?

The spam folder is empty. In the mailer section of the app.ini, I have put an email address that is not in use by any Gitea user, it is just used as the email account that Gitea should use. In the "FROM" variable, I have put the email address from my main account.

When navigating to the settings page, the mailer seems to work. When typing an email address and clicking the Test button, the email is sent to my account (the same that should be used for the actions).

[NorthRealm]

@inxcts Enable Gitea trace log and see if anything like New e-mail sending request []: Run failed(failed/cancelled/succeeded) appears. If yes, then I don't see any issue on Gitea. If no, it probably means:

• Event is not triggered (not likely)
• Trigger user not eligible to receive emails.
• Trigger user has disabled action emails. (In current implementation it's independent from the existing email notification preference setting.)
• Trigger user is not you.
• Anywhere else that I have not noticed.

[mailer]
ENABLED = true
SMTP_ADDR = mailbox.host
SMTP_PORT = 465
PROTOCOL = smtps
FROM = [email protected]
USER = [email protected]
PASSWD = 

The above is my (dummy) mailer config. You usually don't "put the email address from your main account."

[inxcts]

@NorthRealm

When I commit something and the action fails, I now get the email. The problem seems to be that the job is scheduled.

name: Nightly on: schedule: - cron: "0 0 * * *"

Is it possible to receive emails here or run the job with my user?

[NorthRealm]

@inxcts I am not familiar with how Gitea determines trigger user. I looked at code base and did not find anywhere clear that logs an existing user as trigger user for a scheduled task. You get the email probably because of push trigger and you become the trigger user.
Prior in #23725 people had other workarounds.
To "run the job with your user", maybe trigger the run manually or with API?

[lunny]

@inxcts Please notice this feature will be released in v1.25

[inxcts]

@inxcts Please notice this feature will be released in v1.25

@lunny I know that this is a 1.25 feature, I am running the latest dev build.

@NorthRealm I think for scheduled builds, the repository owner should receive the emails(just like GitHub does), otherwise no one really knows that actions fail.

[PhantomPhoton]

FWIW, I'm in agreement with inxcts. I'm more interested in receiving notifications for scheduled actions when they fail vs push actions, as with push actions, I'm actively doing something and know to check. Having to check the results manually every morning is a chore I wish to avoid. Just my two cents.

That said, I really appreciate the work and feature and am very thankful for the project.

[ChristopherHX]

I think for scheduled builds, the repository owner should receive the emails(just like GitHub does)

My experience is different. The user who has changed the schedule trigger yaml most recently is the trigger of the run and email recipient on GitHub Actions, here is Gitea Actions the trigger and has no real user as target.

In very rare cases this is the repository owner for multi user projects.

---

There were discussions on how bad GitHubs behavior is, so it might make sense to actually use the repository owner for all non deliverable workflow failure notifications.

Some people might prefer, a repo setting to send all schedule failures to a custom user/team members / receive other event failures of other users as well.

---

Emoji Vote

• 😀 The user who last changed the schedule workflow trigger yaml = trigger + email target, just like GitHub
• 🚀 Use the owner for workflow emails without recipient, but orgs cannot receive emails, then the org owners need to looked up
• 👀 Repository setting to specify target audience of workflow email notifications

[ghnp5]

Thanks!! I suggest repository setting for email address, and if it's not set, default to "last changed".