Deprecate pre_receive_secret_detection_enabled GraphQL
Deprecation Summary
Add a brief description of the feature or functionality that is deprecated. Clearly state the potential impact of the deprecation to end users.
Since we have renamed pre_receive_secret_detection
to secret_push_protection
, we also need to rename anything API-related that uses the old name. This issue tracks the deprecation of pre_receive_secret_detection_enabled
GraphQL.
- Rename 'setPreReceiveSecretDetection' GraphQL mutation to 'setSecretPushProtection
- Deprecation issue already complete and merged: !175211 (merged)
- Fields returned by 'setPreReceiveSecretDetection' GraphQL mutation
- Update returned fields from
pre_receive_secret_detection_enabled
tosecret_push_protection_enabled
- We return both fields (same value, different field name) until %18.0
- Update returned fields from
Notes to self (you can ignore this)
Delete these files:
-
app/assets/javascripts/security_configuration/graphql/pre_receive_secret_detection.graphql
ee/app/graphql/mutations/security/ci_configuration/set_pre_receive_secret_detection.rb
Remove from these files:
-
ee/app/graphql/ee/types/mutation_type.rb:197
- Don't need to mount
SetPreReceiveSecretDetection
mutation anymore
- Don't need to mount
-
ee/app/graphql/ee/types/project_type.rb:380
- Don't need to return
pre_receive_secret_detection_enabled
field anymore
- Don't need to return
-
ee/app/graphql/mutations/security/ci_configuration/set_secret_push_protection.rb
- Don't need to return
pre_receive_secret_detection_enabled
field anymore
- Don't need to return
Documentation
Product Usage
Describe why deprecation of this feature is necessary, ideally with dashboards/metrics that show product usage. add links to the documentation
Breaking Change?
Affected Customers
- GitLab.com
- Self-managed
- Dedicated
Deprecation Milestone
17.9
Planned Removal Milestone
18.0
Links
Checklists
Timeline
Rollout Plan
DRIs:
-
Engineers: @serenafang
-
Engineering Manager: @amarpatel
-
Describe rollout plans on GitLab.com
-
Link to a feature flag rollout issue that covers:
- Expected release date on GitLab.com and GitLab version
- Rollout timelines, such as a percentage rollout on GitLab.com
- Creation of any clean-up issues, such as code removal
-
Link to a feature flag rollout issue that covers:
-
Determine how to migrate users still using the existing functionality
-
Document ways to migrate with the tooling available
-
Automate any users who have not yet migrated, but ensure it's a two-way door decision
Communication Plan
DRIs:
- Product Manager: @abellucci
Add links to the relevant merge requests.
- As soon as possible, but no later than the third milestone preceding the major release (for example, given the following release schedule:
17.8, 17.9, 17.10, 17.11, 18.0
–17.9
is the third milestone preceding the major release):- A deprecation announcement entry has been created so the deprecation will appear in release posts and on the general deprecation page.
- Documentation has been updated to mark the feature as deprecated.
- On the major milestone:
- The deprecated item has been removed.
- If the removal of the deprecated item is a breaking change, the merge request is labeled breaking change.
- Document the migration plan for users, clearly outlining the actions they need to take to mitigate the impact of the breaking change.
Development
DRIs:
-
Engineers:
@engineer(s)
-
Engineering Manager:
@EM
-
Measure usage of the impacted product feature
- Evaluate metrics across GitLab.com, Self-Managed, Dedicated
- add issue link
- list any metrics and/or dashboards
-
Create tooling for customers to manually migrate their data or workflows
- add issue link
-
Build mechanism for users to manually enable the breaking change ahead of time
- add issue link
-
Automate the migration for those who do not take any manual steps (ensure the automation can be reverted)
- add issue link
-
Develop rollout plan of breaking change on GitLab.com
- add feature flag rollout issue
-
Dogfood the changes on GitLab.com or a Self-Managed test instance
- add issue link
-
(Optional) Create UI controls for instance admins to disable the breaking change, providing flexibility to Self-Managed / Dedicated customers. Optional as this depends on the breaking change.
- add issue link
Approvals
-
Product Manager
@PM
-
Engineering Manager
@EM
-
Senior Engineering Manager / Director
@senior-eng-leader
-
Group / Director of Product Management
@senior-product-leader
Mentions (as applicable)
-
Product Designer
@ProductDesigner
-
Tech Writer
@TW
-
Software Engineering in Test
@SET
-
Any other stable counterparts based on the product categories:
-
Add Sales/CS counterpart or mention
@timtams
-
Add Support counterpart or mention
@gitlab-com/support/managers
-
Add Marketing counterpart or mention
@cfoster3
-
Add Sales/CS counterpart or mention
Labels
-
This issue is labeled deprecation, and with the relevant
~devops::
,~group::
, and~Category:
labels. - This issue is labeled breaking change if the removal of the deprecated item will be a breaking change.