Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • delivery delivery
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 571
    • Issues 571
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.comGitLab.com
  • GitLab Infrastructure TeamGitLab Infrastructure Team
  • deliverydelivery
  • Issues
  • #1432
Closed
Open
Issue created Dec 17, 2020 by Mayra Cabrera@mayra-cabrera🔴Maintainer

Identify the deployer job that sends the initial notification

On #1372 (closed), we're wrapping the deployment notifications in a single Slack thread. Logic is roughly the following:

  1. There's an active incident or a problem with the health status, and a deployment to prod starts.
  2. As the deployment progresses, deployer pipeline continuously notifies release-tools about the progress.
  3. release-tools consumes this information and
    • Verifies if this is the first notification it receives and if it's, it posts a message to Slack.
    • If it's not the initial notification, the message is sent as a thread.
Example

Link to Slack message internal only

Screen_Shot_2020-12-17_at_17.11.20

Problem

We don't have a reliable way to identify when the first notification is sent to release-tools, currently we're using gprd-migrations 50%, but this might be unreliable because a deployer pipeline sent the notification at gprd migrations 100% (see this pipeline, gprd-migration job, and the initial notification sent to release-tools as examples).

We could also modify the code to use gprd-migrations instead of gprd-migrations 50%, but that will cause at least one additional message to be posted in the Slack channel.

Let's use this issue to figure out what'd be the best way to identify the initial notification.

Solution

gprd-migrations 50% should be, in fact, the initial deployer job. The problem was around an unnecessary check on the deployer side mangling the triggers towards release-tools

Edited Dec 23, 2020 by Mayra Cabrera
Assignee
Assign to
Time tracking