Skip to content

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
  • Fields returned by 'setPreReceiveSecretDetection' GraphQL mutation
    • Update returned fields from pre_receive_secret_detection_enabled to secret_push_protection_enabled
    • We return both fields (same value, different field name) until %18.0

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
  • ee/app/graphql/ee/types/project_type.rb:380
    • Don't need to return pre_receive_secret_detection_enabled field anymore
  • ee/app/graphql/mutations/security/ci_configuration/set_secret_push_protection.rb
    • Don't need to return pre_receive_secret_detection_enabled field anymore

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

!177950 (merged)

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

  • 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:

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):
  • 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

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.

References

Edited by Serena Fang