Skip to content

Includes sync_remote task on security template

What does this MR do?

Includes the sync_remote task on the Security template. Also updates the rake task documentation to include the new task

Related to https://gitlab.com/gitlab-org/release-tools/-/issues/365

Example

Regular Security Release template

Security patch release: 13.0.6, 12.10.11, 12.9.10

Preparation

Preparation steps should ideally be completed within one day

  • Temporarily disable the scheduled auto-deploy tasks via ChatOps:

    # In Slack
    /chatops run auto_deploy pause
  • Disable Omnibus nightly builds by setting the schedules to inactive: https://dev.gitlab.org/gitlab/omnibus-gitlab/pipeline_schedules.

  • Ensure latest auto-deploy branches are synced across Canonical, Security, and Build:

    # In Slack
    /chatops run mirror status
  • Merge security merge requests using ChatOps

    # In Slack:
    /chatops run release merge --security
  • If any merge requests could not be merged, investigate what needs to be done to resolve the issues. Do not proceed unless it has been determined safe to do so.

  • Ensure security fixes are included in the auto-deploy branch. Fixes are automatically cherry-picked into the auto-deploy branch after they're merged. If they were not chery-picked, you can use the cherry pick script to do it manually.

    • For GitLab
    • For Omnibus GitLab

Auto Deploy tag and deploy to Staging

  • Tag a new auto-deploy version via ChatOps (no need to wait for green build), to create a deployer pipeline that will deploy to staging and create a QA issue:
    # In Slack
    /chatops run auto_deploy tag --security

QA

  • On the deployer pipeline, manually cancel the gprd-cny-change-lock from the deployer pipeline. This will prevent the automatic promotion to Canary.

  • Once the deploy to staging is completed, notify the @appsec-team member so they can validate the security fixes on staging.

  • Once the security fixes been validated on staging, retry the gprd-cny-change-lock job to promote to Canary.

  • If there are no issues reported on canary, proceed to promote the deployment to production.

Packaging

  • Ping the Security Engineers so they can get started with the blog post. The blog post should be done on https://dev.gitlab.org/gitlab/www-gitlab-com

  • Ensure tests are green in CE and green in EE

    # In Slack:
    /chatops run release status --security
  • Tag the security release:

    # In Slack:
      /chatops run release tag --security 13.0.6
      /chatops run release tag --security 12.10.11
      /chatops run release tag --security 12.9.10
    
  • Check that EE and CE packages are built:

Deploy

Release

  • This section should be done in coordination with the Security team, so make sure to confirm with them before proceeding

    # In Slack
    @appsec-team - We are ready to publish the security release packages for 13.0.6, please let us know if the blog post is ready.
  • Publish the packages via ChatOps:

     # In Slack:
      /chatops run publish 13.0.6
      /chatops run publish 12.10.11
      /chatops run publish 12.9.10
    
  • Create the versions:

  • Merge the blog post on https://gitlab.com/gitlab-com/www-gitlab-com

  • In the #content-updates channel, share a link to the blog post.

Sync

  • Sync master and auto-deploy branches for GitLab, GitLab Foss, Omnibus GitLab and Gitaly, via ChatOps:

    # In Slack
    /chatops run release sync_remotes --security
  • Verify all remotes are synced:

    # In Slack
    /chatops run mirror status

    If conflicts are found, manual intervention will be needed to sync the repositories.

Auto-Deploy

  • Re-enable the scheduled auto-deploy tasks via ChatOps:

    # In Slack
    /chatops run auto_deploy unpause
  • Create a new auto-deploy branch from master via ChatOps:

    # In Slack
    /chatops run auto_deploy prepare
  • Enable Omnibus nightly builds by setting the schedules to active https://dev.gitlab.org/gitlab/omnibus-gitlab/pipeline_schedules

Edited by Mayra Cabrera

Merge request reports