E2e alert triggers email notification
Description of the test
New E2E test for New alerts can send email notification to maintainer and owner users
Maintainer user
- Login as admin, create new user via API
- Create new project via API, add user to project as MAINTAINER
- Navigate to Project Settings -> Monitor -> Alert settings -> Enable send email notification
- Setup and send test alert for HTTP Endpoint integration
- Verify user receive email with title
<project_name> | Alert: <alert_title>
- Verify user receive email with title
- Repeat 1 - 3, Setup and send test alert for Prometheus integration
- Verify user receive email with title
<project_name> | Alert: <alert_title>
- Verify user receive email with title
Owner user
- Login as admin, create new user via API
- Create new project via API, add user to project as OWNER
- Navigate to Project Settings -> Monitor -> Alert settings -> Enable send email notification
- Setup and send test alert for HTTP Endpoint integration
- Verify user receive email with title
<project_name> | Alert: <alert_title>
- Verify user receive email with title
- Repeat 1 - 3, Setup and send test alert for Prometheus integration
- Verify user receive email with title
<project_name> | Alert: <alert_title>
- Verify user receive email with title
Checklist
-
Confirm the test has a testcase:
tag linking to an existing test case in the test case project. -
Note if the test is intended to run in specific scenarios. If a scenario is new, add a link to the MR that adds the new scenario. -
Follow the end-to-end tests style guide and best practices. -
Use the appropriate RSpec metadata tag(s). - Most resources will be cleaned up via the general cleanup task. Check that is successful, or ensure resources are cleaned up in the test:
-
New resources have api_get_path
andapi_delete_path
implemented if possible. -
If any resource cannot be deleted in the general delete task, make sure it is ignored. -
If any resource cannot be deleted in the general delete task, remove it in the test (e.g., in an after
block).
-
-
Ensure that no transient bugs are hidden accidentally due to the usage of waits
andreloads
. -
Verify the tags to ensure it runs on the desired test environments. -
If this MR has a dependency on another MR, such as a GitLab QA MR, specify the order in which the MRs should be merged. -
(If applicable) Create a follow-up issue to document the special setup necessary to run the test: ISSUE_LINK -
If the test requires an admin's personal access token, ensure that the test passes on your local environment with and without the GITLAB_QA_ADMIN_ACCESS_TOKEN
provided.
Edited by Tiffany Rea