Quality and Notifications in the Pipeline

The pipeline now has approval and triggers, but it's still missing two things to run for real. First: make sure broken code cannot reach Deploy — run tests as a blocking gate. Second: nobody sits watching the console all day, so the pipeline has to report on its own when it succeeds, fails, or awaits approval. This article (closing Part V) adds both.

Goal

Use tests in the pipeline as a gate that blocks deploy, and set up pipeline status notifications to SNS — verifying notifications are actually sent.

Tests as a blocking gate

Our Build stage already runs pytest (Article 6). In the pipeline that naturally becomes a blocking gate: if a test fails, buildspec returns a non-zero exit code, the Build stage Failed, and the pipeline stops immediately — the Approval and Deploy stages never run. No extra configuration needed; just don't swallow test errors (|| true) as warned in Article 6.

For a large project, you can split this out into a separate Test stage after Build, or add a security scan action (running trivy/checkov in a CodeBuild project) in the same stage with a parallel runOrder. However you organize it, the principle is one: every quality gate sits before Deploy, and any gate that fails stops the pipeline before it touches production. This is what makes a pipeline different from a deploy script — it refuses to carry a broken build forward.

Why notifications are needed

An automated pipeline that reports nothing is dangerous: a deploy that fails at 2 a.m., or a pipeline awaiting approval that nobody knows about, can sit idle for hours. Notifications turn a pipeline from "silently running" into "actively reporting." CodePipeline emits notifications via a notification rule (the CodeStar Notifications service), pushing events to an SNS topic — from there they fan out to email, Slack, or a queue for further processing.

Set up the SNS topic and notification rule

Create an SNS topic as the emission point:

$ TOPIC=$(aws sns create-topic --name awscicd-notifications --query 'TopicArn' --output text)

Allow CodeStar Notifications to publish to the topic (a topic policy for the codestar-notifications.amazonaws.com service), then create a notification rule attached to the pipeline, selecting the events you care about:

$ aws codestar-notifications create-notification-rule \
    --name awscicd-pipeline-notifications \
    --resource arn:aws:codepipeline:ap-southeast-1:111122223333:awscicd-pipeline \
    --detail-type FULL \
    --event-type-ids \
       codepipeline-pipeline-pipeline-execution-succeeded \
       codepipeline-pipeline-pipeline-execution-failed \
       codepipeline-pipeline-manual-approval-needed \
    --targets "TargetType=SNS,TargetAddress=$TOPIC"

The three event-type-ids tell the rule to fire only when the pipeline succeeds, fails, or needs approval — exactly the moments you need to know about. (The first time you create a rule in an account, AWS needs to set up the service-linked role AWSServiceRoleForCodeStarNotifications; if you hit a "could not create the managed rule" error, wait a few minutes for the role to be ready, then retry.)

Confirm the rule is enabled and points at the right topic:

$ aws codestar-notifications describe-notification-rule --arn <rule-arn> \
    --query '[Status,length(EventTypes),Targets[0].TargetAddress]' --output text
ENABLED  3  arn:aws:sns:ap-southeast-1:111122223333:awscicd-notifications

Verify a real notification

To prove the chain works, subscribe an SQS queue to the topic (instead of email, which needs manual confirmation) and read the message. After running the pipeline, a notification lands in SQS:

$ aws sqs receive-message --queue-url <queue> --wait-time-seconds 10 \
    --query 'Messages[0].Body' | ...
detailType: CodePipeline Action Execution State Change
source: aws.codepipeline
detail: {"pipeline": "awscicd-pipeline", "execution-id": "a9a2d677-...",
         "stage": "Approval", ...}

A real notification, from the actual pipeline run: it reports the execution is at the Approval stage (needs approval). In practice, this same message goes to email or a Slack channel, so the on-call person knows the pipeline is waiting on them. When the pipeline Failed or Succeeded, a similar message is fired.

   pipeline event (succeeded / failed / approval-needed)
        │
   notification rule (CodeStar Notifications)
        │  publish
        ▼
   SNS topic awscicd-notifications
        ├──▶ email (subscribe + confirm)
        ├──▶ Slack (via AWS Chatbot)
        └──▶ SQS  ──▶ read the real message (verified)

EventBridge: deeper customization

A notification rule underneath actually sets up an EventBridge rule that catches pipeline events. When you need processing more complex than email/Slack — say, invoking a Lambda to write a metric, open a ticket, or block deploy on an external condition — you write an EventBridge rule directly on the CodePipeline event pattern (source: aws.codepipeline, detail-type: CodePipeline Pipeline Execution State Change) and point its target at Lambda/SNS/SQS. A notification rule is the shortcut for ordinary notifications; EventBridge is the door to any automation around the pipeline.

🧹 Cleanup

Part V done — tear down the pipeline, EC2 target, and notification infrastructure:

$ aws codepipeline delete-pipeline --name awscicd-pipeline
$ aws ec2 terminate-instances --instance-ids <target-iid>
$ aws codestar-notifications delete-notification-rule --arn <rule-arn>
$ aws sns delete-topic --topic-arn <topic>
$ aws sqs delete-queue --queue-url <queue>

Summary

Two things make a pipeline truly usable: tests as a blocking gate (Build runs tests, a failure stops the pipeline before Deploy — every quality gate sits before Deploy), and notifications so the pipeline reports its own status. Notifications are set up with a notification rule (CodeStar Notifications) pointing at an SNS topic, selecting succeeded/failed/approval-needed events, then fanning out to email/Slack/SQS — we read the real message via SQS to confirm. Underneath is EventBridge, which is also the door to any deeper automation around the pipeline.

Part V closes: the pipeline is automated, has approval, has quality gates, has notifications. Part VI is the capstone — wiring the entire series into one complete production pipeline: from a CodeCommit commit, through build and test, to a blue/green deploy onto an Auto Scaling Group behind an ALB, with approval and rollback. The next article builds the target infrastructure for the capstone via the CLI.