Notifications

​

Setup

soundcheck:
  notifications:
    enabled: true

​

Migrating from Legacy Soundcheck Notifications

​

What is deprecated

# Deprecated
soundcheck:
  slack:
    token: ${SLACK_OAUTH_TOKEN}
    appToken: ${SLACK_APP_TOKEN}
    signingSecret: ${SLACK_SIGNING_SECRET}

# Deprecated
soundcheck:
  email:
    host: smtp.example.com
    port: 587
    from: soundcheck@example.com
    auth:
      user: ${SMTP_USER}
      pass: ${SMTP_PASS}

​

Migration steps

1. Enable the Backstage Notifications plugin: set soundcheck.notifications.enabled: true
2. Remove the soundcheck.slack and soundcheck.email configuration blocks
3. The supportChannel field on campaigns will be ignored once the legacy systems are removed
4. Install email or slack processors as indicated in the Backstage documentation.

​

Replacement

​

Differences between legacy and new system

1. The new system integrates directly with the open source notifications plugin and benefits from the features there.
2. The new system has additional notification types, and enhanced campaign notifications.
3. Any new features around notifications will only work with the new notification system.
4. Email and Slack are no longer configured within Soundcheck and as part of the campaign fields, but within the notification processors.

​

Notification Allowlist

​

Configuration

soundcheck:
  notifications:
    enabled: true
    allowlist:
      checks:
        - has-readme
        - has-owner
      tracks:
        - micro-certified
      campaigns:
        - q2-reliability-push

​

Behavior

• When allowlist is not configured, all items trigger notifications (backwards-compatible).
• The checks, tracks, and campaigns lists are independent. If only checks is specified, only check notifications are filtered; track and campaign notifications continue for all items.
• When an allowlist is specified for a type (e.g., checks), only items whose IDs appear in that list generate notifications. For example, with the configuration above, a failing check with ID has-readme triggers a notification, but a failing check with ID has-tests does not.
• An empty array (e.g., checks: []) blocks all notifications of that type.
• For campaigns and milestones, the allowlist gates all notification channels (Backstage notifications, Slack, and email). For checks and tracks, it only gates Backstage notifications since these don’t send Slack/email notifications.

​

Notification Types

​

Campaigns

• Campaign Create - owner of Campaign
• Campaign Updated - owner of Campaign
• Campaign Archived - owner of Campaign
• Campaign Deleted - owner of Campaign
• Campaign Milestone Reached - owner of Campaign

​

Checks

• Previously Passing Check is now Failing - owner of entities that are failing this check. If multiple entities a user owns are failing a check, only 1 notification is sent. This only triggers if the previous check state was passed.

​

Tracks

• Previously Certified Track is now Failing - owner of entities that are failing certification. If multiple entities a user owns are failing certification, only 1 notification is sent. This only triggers if the previous certification state was passed.
• Previously Passing Campaign is now Failing - owner of entities that are failing this campaign. If multiple entities a user owns are failing this campaign, only 1 notification is sent. This only triggers if the previous campaign state was passed.