Skip to content

Add FF for the security release pipeline

Mayra Cabrera requested to merge guard-omnibus-step-behind-ff into master

What does this MR do and why?

Add FF for the security release pipeline

Introduces a feature flag for the security pipeline. Currently it is only guarding the omnibus disable step.

Related to gitlab-com/gl-infra/delivery#19300 (closed)

Tests

The below tests are only showing the First steps section.

With the feature flag disabled (current version)

Click to expand

Security patch release: 16.0.2, 15.11.7, 15.10.8

First steps

  • Set the Due date on this issue with the planned Security publish date

  • Disable Omnibus nightly builds by setting the schedules to inactive: https://dev.gitlab.org/gitlab/omnibus-gitlab/-/pipeline_schedules. This prevents us accidentally revealing vulnerabilities before the release.

  • Post a message on the #quality Slack channel to notify the Quality team that a security release is in progress:

Hello team, the security release has started (<link_to_this_issue>) and Omnibus nightly builds are now disabled. The GitLab ChatOps bot will post a notification to this channel when the security release is complete.

  • Ensure that Canonical, Security and Build repositories are synced:

    # In Slack
/chatops run mirror status

  • Post a comment on https://gitlab.com/gitlab-jh/gitlab-jh-enablement/-/issues/112 to notify JiHU of the upcoming security release.

  • Post a message on the #g_engineering_productivity channel to let them know that the secuirty release preperation has started. EP will use this information to quickly respond to pipeline failures to keep us unblocked

  • Post a message on the #g_runner Slack channel to notify the Runner team that a security release is in progress and that it will be published on the due date.

  • Verify if there are security fixes for projects under GitLab managed versioning model. If there are, adjust this issue following the instructions. This is to synchronize the GitLab and the GitLab runner security release in case there is one planned.

  • Modify the dates below to accurately reflect the plan of action.

  • Verify pipelines on default and stable branches on GitLab are green:

  • Verify pipelines on the GitLab projects are green:

With the feature flag enabled

Click for details

First steps

  • Set the Due date on this issue with the planned Security publish date

  • Disable Omnibus builds by manually running a pipeline in OPS with $SECURITY_RELEASE_PIPELINE set to prepare

  • Post a message on the #quality Slack channel to notify the Quality team that a security release is in progress:

Hello team, the security release has started (<link_to_this_issue>) and Omnibus nightly builds are now disabled. The GitLab ChatOps bot will post a notification to this channel when the security release is complete.

  • Ensure that Canonical, Security and Build repositories are synced:

    # In Slack
/chatops run mirror status

  • Post a comment on https://gitlab.com/gitlab-jh/gitlab-jh-enablement/-/issues/112 to notify JiHU of the upcoming security release.

  • Post a message on the #g_engineering_productivity channel to let them know that the secuirty release preperation has started. EP will use this information to quickly respond to pipeline failures to keep us unblocked

  • Post a message on the #g_runner Slack channel to notify the Runner team that a security release is in progress and that it will be published on the due date.

  • Verify if there are security fixes for projects under GitLab managed versioning model. If there are, adjust this issue following the instructions. This is to synchronize the GitLab and the GitLab runner security release in case there is one planned.

  • Modify the dates below to accurately reflect the plan of action.

  • Verify pipelines on default and stable branches on GitLab are green:

  • Verify pipelines on the GitLab projects are green:

Author Check-list

  • [-] Has documentation been updated?
Edited by Mayra Cabrera

Merge request reports