Remove support for release notes in create tag API (remove remove_release_notes_from_tags_api feature flag)
Originally tags had 1<=>0/1 relation with releases(you couldn't have than 1 release per tag). So in the initial implementation it was sensible to create releases via tags API. But than we changed that, and today you can have many releases assigned to the same tag. So creating/updating releases using tags API may be ambiguous(e.g. we don't know what release to update if there are multiple).
This API is superseded by the Releases API.
It was deprecated in 11.7, so we should finally remove it:
- https://gitlab.com/gitlab-org/gitlab/blob/ea5c474169b13278b21efc285e097b63cf831454/lib/api/tags.rb#L65
- https://gitlab.com/gitlab-org/gitlab/blob/ea5c474169b13278b21efc285e097b63cf831454/lib/api/tags.rb#L108
- https://gitlab.com/gitlab-org/gitlab/blob/ea5c474169b13278b21efc285e097b63cf831454/lib/api/tags.rb#L140
** If you stil use this API, please migrate to releases API: https://docs.gitlab.com/ee/api/releases/ **
Only a few users use this API: This API is being used by some people: https://dashboards.gitlab.net/d/api-rails-controller/api-rails-controller?orgId=1&from=now-24h%2Fm&to=now%2Fm&var-PROMETHEUS_DS=Global&var-environment=gprd&var-stage=main&var-controller=Grape&var-action=GET%20%2Fapi%2Fprojects%2F:id%2Freleases&var-action=GET%20%2Fapi%2Fprojects%2F:id%2Freleases%2F:tag_name&var-action=GET%20%2Fapi%2Fprojects%2F:id%2Freleases%2F:tag_name%2Fassets%2Flinks&var-action=HEAD%20%2Fapi%2Fprojects%2F:id%2Freleases&var-action=POST%20%2Fapi%2Fprojects%2F:id%2Freleases&var-action=DELETE%20%2Fapi%2Fprojects%2F:id%2Freleases%2F:tag_name&var-action=PUT%20%2Fapi%2Fprojects%2F:id%2Freleases%2F:tag_name
But usage is very low.
FF rollout summary
This issue is to rollout removal of releases part of tags API on production,
that is currently behind the remove_release_notes_from_tags_api
feature flag.
Owners
- Team: grouprelease
- Most appropriate slack channel to reach out to:
#g_release
- Best individual to reach out to: @vshushlin
- PM: @kbychu
The Rollout Plan
We originally just planned to remove this API, bug added the feature flas as means to quickly revert it, so I'll just enable this FF for everyone, leave it for a couple days, and remove
- Enable for everyone on .com
- Remove FF
Expectations
What are we expecting to happen?
, so they may complain.
But usage is very low.
What might happen if this goes wrong?
What can we monitor to detect problems with this?
Rollout Steps
Preparation before production rollout
-
Ensure that the feature MRs have been deployed to both production and canary. -
/chatops run auto_deploy status <merge-commit-of-your-feature>
-
-
Check if the feature flag change needs to be accompanied with a change management issue. Cross link the issue here if it does. -
Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production. If a different developer will be covering, or an exception is needed, please inform the oncall SRE by using the @sre-oncall
Slack alias. -
Ensure that documentation has been updated (More info). -
Announce on the feature issue an estimated time this will be enabled on GitLab.com. -
If the feature flag in code has an actor, enable it on GitLab.com for testing groups/projects. -
/chatops run feature set --<actor-type>=<actor> <feature-flag-name> true
- I added actor, but will enable for everyone, usage of this API is super low, so we won't notice anything on
gitlab-org
group.
-
-
Verify that the feature works as expected. Posting the QA result in this issue is preferable.
Global rollout on production
-
Incrementally roll out the feature. - Enable the feature globally on production environment.
-
/chatops run feature set remove_release_notes_from_tags_api true
-
- Enable the feature globally on production environment.
-
Announce on the feature issue that the feature has been globally enabled. -
Cross-post chatops slack command to #support_gitlab-com
. (more guidance when this is necessary in the dev docs) and in your team channel -
Wait for at least one day for the verification term.
Release the feature
After the feature has been deemed stable, the clean up should be done as soon as possible to permanently enable the feature and reduce complexity in the codebase.
-
Create a merge request to remove <feature-flag-name>
feature flag. Ask for review and merge it.-
Remove all references to the feature flag from the codebase. -
Remove the YAML definitions for the feature from the repository. -
Create a changelog entry.
-
-
Ensure that the above MR has been deployed to both production and canary. If the merge request was deployed before the code cutoff, the feature can be officially announced in a release blog post. -
/chatops run auto_deploy status <merge-commit>
-
-
Close the feature issue to indicate the feature will be released in the current milestone. -
Clean up the feature flag from all environments by running these chatops command in #production
channel:-
/chatops run feature delete <feature-flag-name> --dev
-
/chatops run feature delete <feature-flag-name> --staging
-
/chatops run feature delete <feature-flag-name>
-
-
Close this rollout issue.
Rollback Steps
-
This feature can be disabled by running the following Chatops command:
/chatops run feature set remove_release_notes_from_tags_api false