Let fine-grained tokens read the Duo Agent Platform status check

José M. Requena Plensrequested to merge
gitlab-community/gitlab-org/gitlab:jmrp-granular-pat-agent-execution into master

What does this MR do and why?

A fine-grained personal access token gets null from Project.duoWorkflowStatusCheck, because DuoWorkflowEnablement and DuoWorkflowEnablementCheck declare no authorize_granular_token directive.

Project.duoWorkflowStatusCheck is the only field that returns DuoWorkflowEnablement, and its checks field the only one that returns DuoWorkflowEnablementCheck, so both declare read_project, the permission Project checks, with parent_authorizes: and leave authorization_todo.txt.

DuoWorkflowPermissions already skipped the token check: its only parent, DuoWorkflow, checks read_duo_workflow. It now declares that permission, so its parent_authorizes: line leaves the list too, as agreed in !269587 (comment 4202991029). Nothing changes for any token there. The checks for the user do not change.

This is the Agent Execution domain's merge request, agreed in !267273 (comment 4195231927).

References

Closes #639818

I found this while working on gitlab-mcp-server.

Screenshots or screen recordings

No UI change.

How to set up and validate locally

  1. Create a fine-grained token with Project: Read for a private project with GitLab Duo enabled, as a developer of that project.
  2. Run query { project(fullPath: "<project>") { duoWorkflowStatusCheck { enabled checks { name value } } } } with it.
  3. On master duoWorkflowStatusCheck is null; on this branch it returns the status and its checks.

I ran these steps as the new request spec examples: those that expect data fail on master, and all pass on this branch.

Checks I ran (Ruby 3.3.11)
  • The skipped child type example for each parent field: Project.duoWorkflowStatusCheck and DuoWorkflowEnablement.checks (new), DuoWorkflow.userPermissions (already on master), and a directive pin in each type spec.
  • With master's three types, the four changed spec files give 22 examples, 5 failures: exactly the three pins and the two examples that expect the data. The existing DuoWorkflow.userPermissions example passes on master too, since that declaration changes no result. gitlab:permissions:validate lists the three entries.
  • On this branch: 22 examples, 0 failures, and 2 examples, 0 failures for the userPermissions context of workflows_spec.rb.
  • gitlab:permissions:validate, both compile_docs tasks (no change), RuboCop, the commit linter and Danger's linters pass. Left to the pipeline: Ruby 3.4.10 and the FOSS run.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports