Test the dynamic release date logic during 16.4 and 16.5
Context
Starting on the 16.6 milestone, the monthly release date will be moved from the 22nd to the 3rd Thursday of each month. As part of this work, a new SSOT for the release information was introduced (releases.yml
) and the release templates, including monthly and security ones, have been updated to use the new schedule.
This new logic is guarded behind a feature flag that will be enabled during 16.4 and 16.5 to observe behavior
Test
Requirements
-
Enable the dynamic_release_date
feature flag on https://ops.gitlab.net/gitlab-org/release/tools/-/feature_flags
16.4
-
16.4 release candidate is created and deployed to pre -
16.4 is tagged -
September 22nd: -
16.4 is published - [-] Release Manager's permissions consider the release date. #19663 (comment 1572968003)
-
Fix release manager permission by:
-
Fix the active_version
bug on gitlab-release gitlab-org/ruby/gems/gitlab-releases!16 (merged) -
Create a merge request to bump the version on gitlab-release gem gitlab-org/ruby/gems/gitlab-releases!17 (merged) -
Bump the version release-tools gitlab-org/release-tools!2651 (merged)
16.5
-
A monthly release issue is created and assigned to the respective release managers -
The monthly release reflects October 22nd as the release date #19663 (comment 1577649511) -
16.5 release candidate is created and deployed to pre -
16.5 is tagged -
October 22nd: -
16.5 is published -
Release Manager's permissions consider the release date.
-
What to do if something goes wrong?
- [-] Disable the
dynamic_release_date
feature flag https://ops.gitlab.net/gitlab-org/release/tools/-/feature_flags - [-] Wait for the next auto-deploy package to be created
Edited by Mayra Cabrera