Skip to content

Internal releases: Test the internal release process

📖 Context

To remediate GiLab single-tenant instances within remediation SLAs, a new GitLab internal release strategy is being designed and introduced on &1201 (closed).

GitLab releases have been public by default, introducing a new private release strategy is an uncharted territory that should be thoroughly tested before using it as a remediation tool on high-severity incidents.

This issue aims to test the end-to-end process of an internal release to guarantee the standard workflow works as expected. The testing is split into five phases:

  1. Phase 1 - Internal release initial process
  2. Phase 2 - Ability to generate packages
  3. Phase 3 - Verification of internal package
  4. Phase 4 - Final steps of the internal release

📓 General Requirements

✅ Phase 1: Internal release initial process

Click to expand

Setup

Start the internal release process

Internal release with a specific iteration

Initial announcements.

  • Trigger the internal_release_prepare:start process
  • Verify a Slack alert has been sent to #f_upcoming_release_channel
  • Confirm the internal_release_prepare:notify_dedicated job is executed (this job is no-op)

Observations

Details: #20727 (comment 2321316703)

✅ Phase 2: Creation of an internal release package

First run

Setup:

Job execution

  • Trigger the internal_release_release:start job
  • Verify a Slack alert has been sent to #release_tools_tests
  • Verify the internal_release:trigger_service is successfully executed

Package creation

17.7

17.6

Metadata

17.7

17.6

Slack announcement

  • Verify a Slack alert has been sent to #f_upcoming_release_channel with the job status
Second run

Setup:

Kick off the internal release process

  • Trigger the internal_release_prepare:start process
  • Confirm the internal_release_prepare:check_component_branch_pipeline_status is successfully executed. https://ops.gitlab.net/gitlab-org/release/tools/-/jobs/17444110
    • This job will check the status of the 17.8 and 17.7 branches
  • Confirm the internal_release_prepare:notify_dedicated is successfully executed. This job is a no-op

Job execution

Package creation

17.8

17.7

Metadata

17.8

17.7

Slack announcement

  • Verify a Slack alert has been sent to #f_upcoming_release_channel with the job status

Observations:

✅ Phase 3: Availability of the package

Click to expand

Job execution

  • After 150 minutes the internal package was tagged, confirm the internal_release_verify:start automatically starts
  • Verify a Slack alert has been sent to #f_upcoming_release_channel
  • Verify the internal_release_verify:check_package_build job has successfully executed

Internal packages verification

  • 17.8
  • 17.7

Slack announcement

  • Check the internal_release_verify:check_package_build notify to Slack its completion

Observations:

#20727 (comment 2378982817)

✅ Phase 4: Internal release final steps

Click to expand
  • Trigger the internal_release:finalize:start job on the internal release pipeline
  • Verify a Slack alert has been sent to #f_upcoming_release_channel about the start of this phase
  • Release manager notification
    • Verify a Slack notification was sent to #f_upcoming_release_channel notifying release managers the package is available
    • Verify a comment was added to the internal release task
  • Dedicated: Verify the internal_release_finalize:notify_dedicated is automatically executed (this job is no-op)

Observations

#20727 (comment 2379039440)

Clean up

Follow-ups

Edited by Mayra Cabrera