chatops updated with new blocking logic
Summary
With a new proposal for how to deal with certain labels: &736 (closed) lets update chatops to reflect this proposal:
Leverage label blocks deployments and/or blocks feature-flags as the determination for whether or not what the user is asking for should be prevented or not.
- For Change issues, we may check for active C2's or greater, that are active and contain either of the new blocks labels. If true, the user should not be allowed to proceed
- For incidents, we may check for active S2's or greater, that they are active and contain either of the new block labels. If true, the user should not be allowed to proceed
Proposal
Currently, chatops calls release-tools to perform a "production check", which is a check for:
- Incidents
- Change requests
- Deployment health
- Canary status
-
Send a variable from chatops to release-tools to inform release-tools about the purpose of a production check. If the check is for a deployment, release-tools can check the blocks deployments label. If the check is for a feature flag, release-tools can check the blocks feature-flags label. - gitlab-com/chatops!301 (merged). -
Modify release-tools to check the new labels - gitlab-org/release-tools!1847 (merged).
Implementation
The above proposal was implemented, while maintaining backwards compatibility with the existing severity1, severity2, C1, C2 labels.
To ignore the severity1, severity2 and C1, C2 labels, and use only the blocks deployments and blocks feature-flags labels, enable the use_new_blocking_labels_only
feature flag: https://ops.gitlab.net/gitlab-org/release/tools/-/feature_flags/221/edit. We can only do this when incidents start using the blocks deployments and blocks feature-flags labels.