Remove superseded secretPermission GraphQL mutations

Chaya Danzingerrequested to merge
630579-remove-superseded-secret-permission-mutations into master

What does this MR do and why?

Removes the secretPermissionUpdate and secretPermissionDelete GraphQL mutations. projectSecretsPermissionUpdate and projectSecretsPermissionDelete replaced them in 18.7. The old pair only translated the permissions argument into actions, then called the same services.

Nothing calls them. The web UI calls the replacements. The glab command-line tool does not use Secrets Manager. Only their own request specs referenced them.

This merge request deletes:

  • Mutations::SecretsManagement::Permissions::Update and Mutations::SecretsManagement::Permissions::Delete
  • The two request specs for them
  • Their two mount_mutation lines in ee/app/graphql/ee/types/mutation_type.rb

It keeps SecretPermissionType, the shared examples under ee/spec/support/shared_examples/requests/api/graphql/secrets_management/, the update_secrets_permission and delete_secrets_permission granular token permissions, and the internal events. The project and group mutations still use all of them.

Why remove rather than deprecate

GitLab Secrets Manager reaches General Availability in 19.5, so 19.5 is the last milestone where this removal can happen in one step.

The timing argument, and the risk

The development stages policy allows a breaking change to a Beta feature outside a major release. After General Availability, removing a mutation needs a deprecation in one milestone and a removal in 20.0.

The two mutations carried no experiment: marker, so the GraphQL reference showed them as ordinary mutations with no warning. They were public from 17.11 until now, which is about nine milestones. An API user could have adopted them, so external risk is small but not zero. Internal risk is nil. Product confirmed the removal.

Marking them as experiments now is not an option. The GraphQL styleguide forbids marking an already public schema item as an experiment.

Note for the reviewer on the generated files

public/-/graphql/introspection_result_no_deprecated.json loses the SecretPermission type as well as the two mutations. This is correct generated output.

Why the type drops out of that one file

That file is produced by re-running introspection with remove_deprecated: true in the context, which hides every item that carries a deprecation (lib/gitlab/graphql/deprecations.rb:22). GitLab builds the experiment: marker on top of GraphQL deprecation, as the comment at lib/gitlab/graphql/deprecations.rb:37 states. A GraphQL type list is reachability-based, so a type appears only when a visible field or payload leads to it.

SecretPermission had two kinds of entry point: the two old mutation payloads, which carried no marker and were therefore visible, and the secretPermissions query field, which is experiment: { milestone: '17.10' } and was already hidden in this view. Removing the mutations shut the last visible entry point, so the type became unreachable.

The file itself shows the contrast. Both the secretPermissions and projectSecretsPermissions query fields are hidden, yet ProjectSecretsPermission is still listed, because the non-experiment projectSecretsPermissionUpdate mutation still points at it. SecretPermission no longer has such a mutation.

SecretPermission remains in the real schema in introspection_result.json with all six fields. A client that calls secretPermissions today is unaffected.

I regenerated the experimental GraphQL reference with the rake task, then reverted the parts unrelated to this change. Those generated files are stale on master for other reasons, including AI tool enums, work item widgets and ASCP security boundaries.

Two notes on Danger output

Danger flags the size at over 1,200 lines and suggests a split. Almost all of that is generated files. The hand-written change is about 20 lines across three files: the two mount_mutation lines, two entries in .rubocop_todo/gitlab/authz/permission_check.yml, and the deleted classes and specs. The announcement is already a separate merge request.

Danger also recommends analytics instrumentation review, because the deleted mutations contained track_internal_event calls. No metric is lost. The update_project_secrets_permission and delete_project_secrets_permission events survive, and the project mutations still fire them. The metric definitions under ee/config/metrics/counts_all/ are untouched.

Screenshots or screen recordings

Does not apply. This change has no user interface.

How to set up and validate locally

  1. Open http://localhost:3000/-/graphql-explorer.
  2. Run { __type(name: "Mutation") { fields { name } } }.
  3. Confirm the result lists neither secretPermissionUpdate nor secretPermissionDelete.
  4. Run a projectSecretsPermissionUpdate mutation against a project that has Secrets Manager enabled.
  5. Confirm it still succeeds.

MR acceptance checklist

  • Changelog trailer present: Changelog: removed with EE: true.
  • No new tests needed. This change deletes obsolete specs and adds no behavior.
  • Regenerated the GraphQL reference, the experimental reference, the fine-grained access token page and both introspection schemas.
  • The removal is announced in a separate merge request.

References

Merge request reports