Add a new pipeline email service

What does this MR do?

Add a new pipeline email service

What are the relevant issue numbers?

Closes #3976 (closed)

Remaining tasks

• Preserve · and  
• Use XHTML 1.0
• Use the same layout (app/views/layouts/notify.html.haml)
• Digest or not (assets or public)
• A similar email for succeeded pipeline
• Plain text versions for both emails

Screenshots (if relevant)

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6019#note_16594345

Does this MR meet the acceptance criteria?

• CHANGELOG entry added
• Documentation created/updated
• API support added
• Tests
  • PipelinesEmailService
  • SendPipelineNotificationService

Added 1 commit:

• 614cf3ad - Add a new pipeline email service. TODO: email templates and tests

Added 1 commit:

• e6fcec41 - Add a new pipeline email service. TODO: email templates and tests

Added services label

Added 1 commit:

• 34cbc51e - Add a new pipeline email service. TODO: email templates and tests

mentioned in issue #3976 (closed)

mentioned in issue #21277 (closed)

Added 2 commits:

• 97582338 - Fix copy pasta
• 0997cfd7 - We don't need this

Added 1 commit:

• 1bd2327c - Add mock email templates

Latest mockup from @hazelyang

Steps to activate the service:

• Go to /namespace/project/services
• Click on Pipelines emails
• Make sure Active was checked and save
• Click on Test settings
• Go to /rails/letter_opener/
• Check the HTML and text email

Steps to generate pipelines:

• [To be continued...]

Added 4 commits:

• f5c9a409 - Simplify the code
• 193c8d07 - Fix array literal style
• 11dd99d5 - So that it could create the service without having a template
• e83149d5 - send works on strings

Added 2 commits:

• be414d48 - We don't need them
• 5de54a71 - no longer TODO

@annabeldunstone Do you know how to create pipelines to test this? If so, could you please let me know if you could start working on this, according to the step described in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6019#note_14781853 ? You could find the existing mock template at:

• app/views/notify/pipeline_failed_email.html.haml
• app/views/notify/pipeline_failed_email.text.erb
• app/views/notify/pipeline_succeeded_email.html.haml
• app/views/notify/pipeline_succeeded_email.text.erb

All the required data should already be in the mock template. If I missed anything, please let me know, and let me know if you have any questions you would like to know.

Personally, I install and run GitLab runner, and I just use an existing project to generate pipelines. So they're real data. If you would like to do this, too, please let me know and I'll write step by step instruction to do this. Otherwise, I could try to write some scripts to generate some fake data.

Thanks!

@mikegreiling is actually going to be working on the front end for these emails cc @godfat

Thanks for the heads up!

Reassigned to @mikegreiling

@mikegreiling Please let me know if you have any questions.

Thanks @godfat, I'll start working on this on Tuesday after Labor Day weekend and I'm sure I'll have a few questions.

Haha, cool. Looking forward to your questions :)

mentioned in issue #21930 (closed)

Alright, I've read through everything in #3976 (closed) and this merge request discussion and I have a few questions.

1. Do you have any examples of similarly rich email templates that we've implemented for notifications in the past? Most of the emails I've received from GitLab have been very basic styled html containing the contents of a comment or an issue note with the following footer:

   

2. How and where will we store image assets for this email? Pieces like the branch icon and the red x must be externally hosted images in order to reliably appear in an html email (icon fonts will not work).

   

   Other considerations:

   • if we host it ourselves on a GitLab-operated CDN, then this will be relied on by self-hosted GitLab installations and that feels wrong.
   • if we host the assets within the GitLab installation itself then we have to worry about cases where maybe it is hosted on a closed system or company intranet where the assets are inaccessible to an email client attempting to fetch images.
   • perhaps mailgun or other email delivery services offer image hosting as a service like mailchimp does with marketing email assets. perhaps there is an API we can tie into? however we are then tightly coupling ourselves with one or two particular email delivery services.

3. Related to my concerns above, I'm not sure about the footer in this mockup template. It does not seem to account for the fact that the notification may be coming from a self-hosted GitLab installation. I think it should mention the url of the installation from which it originated, and perhaps nix the GitLab corporate address.