Send an e-mail notification to project owners for expiring deploy tokens

Release notes

Problem to solve

Application Owners rely on deploy tokens for automation. When these tokens are about to expire, they'd like to be informed so that they can renew the token and the automation doesn't break.

Proposal

Add a new email notification at the project level that sends notifications to project owners before a project deploy token expires.

• deploy token expiring in 60 days
• deploy token expiring in 30 days
• deploy token expiring in 7 days
• send 1 notification per expiring token

Here is the e-mail that is generated for personal access tokens, this can be similar:

!19296 (merged)

Intended users

• Allison (Application Ops)

Feature Usage Metrics

• click-through count from sent e-mail to GitLab

Does this feature require an audit event?

No

Implementation Guide

Implementation will have a lot of overlap with the existing process used to send notifications for expiring personal/project/group access tokens. See PersonalAccessTokens::ExpiringWorker, NotificationService.bot_resource_access_token_about_to_expire, Emails::Profile.bot_resource_access_token_about_to_expire_email and the associated email templates, bot_resource_access_token_about_to_expire_email.html.haml/bot_resource_access_token_about_to_expire_email.text.erb.

• Add columns and indexes to deploy_tokens to store when the expiry notifications were sent. An example of where this was done previously can be found in !165257 (merged).
• Add a new mailer method to Email::Profile, and associated text/html email templates. These will be very similar to bot_resource_access_token_about_to_expire_email, with adjusted wording in the email templates to reflect the type of token. The first iteration will be specific to project deploy tokens (notifications for group tokens will be added in #512196).
• Add a new Sidekiq worker, DeployTokens::ExpiringWorker, that is scheduled to run once a day (similar to the personal access tokens worker, but at a different time of day). This will also be similar to the equivalent ExpiringWorker for personal tokens, and it will have very similar behaviour - iterate over every (project) deploy token that is due for a notification, and generate the email added in the previous step.