Revamp CI/CD permissions documentation

Marcel Amiraultrequested to merge
revamp-cicd-permissions into master

What does this MR do?

This is a cleanup of the CI/CD permissions listed on the main permissions doc. They were split up between two sections, with significant overlap. The permissions in the second table were added 5+ years ago when CI was merged into GitLab, and not maintained as carefully as the main project permissions table, and got out of sync.

Review app: http://main-ee-79614.178.62.207.141.nip.io/ee/user/permissions.html#gitlab-cicd-permissions

Now:

  • Both sections merged into new CI/CD permissions section nested under "Project features".

  • Duplicate entries removed.

  • The permissions for non project members and guest users were not fully detailed, so after extensive testing in the linked issue, we've figured everything out. So now guest permissions are clarified, and non-member permissions are included. These two roles have slightly different permissions based on various settings, so we needed a few variations on the footnotes.

    (I did not find any problems with the permissions for reporter and higher roles.)

  • One security feature was improperly placed and moved into the CI/CD section. As per #8800 (closed), The View Security reports feature is actually talking about the Security tab on individual pipeline details, which is not an ultimate feature and should be listed under the CI/CD permissions.

Caveats / Future plans

I also nested the job permissions under this new permissions section, but have not evaluated that content yet. It just couldn't stay by itself in the old location, so that's a "lift-and-shift" as the MVC, and that content needs to be reviewed in a follow-up.

There is also now one footnote no longer needed in the main project permissions table, but removing that would require updating all the other footnote numbers in the table, so I'll save that for another followup as well.

Related issues

Author's checklist

If you are only adding documentation, do not add any of the following labels:

  • ~"frontend"
  • ~"backend"
  • ~"type::bug"
  • ~"database"

These labels cause the MR to be added to code verification QA issues.

Review checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

  • If the content requires it, ensure the information is reviewed by a subject matter expert.
  • Technical writer review items:
    • Ensure docs metadata is present and up-to-date.
    • Ensure the appropriate labels are added to this MR.
    • If relevant to this MR, ensure content topic type principles are in use, including:
      • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
      • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
      • Any task steps should be written as a numbered list.
      • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
  • Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.
  • Ensure a release milestone is set.
Edited by Marcel Amirault

Merge request reports