Skip to content

feat(projects): manage merge request approval configuration on Project - #395

Open
alexandre-allard wants to merge 1 commit into
crossplane-contrib:masterfrom
alexandre-allard:feat/mr-approval-settings
Open

feat(projects): manage merge request approval configuration on Project#395
alexandre-allard wants to merge 1 commit into
crossplane-contrib:masterfrom
alexandre-allard:feat/mr-approval-settings

Conversation

@alexandre-allard

Copy link
Copy Markdown

Description of your changes

GitLab exposes project-level merge request approval settings (reset-on-push, author/committer self-approval, reauthentication, etc.) through a dedicated /projects/:id/approvals endpoint that is separate from the main project update API.
This adds an optional approvals block on the existing Project resource, following the same pattern as pushRules, rather than introducing a separate CRD, since these settings have no independent identity or lifecycle apart from the project they belong to.

Fields are only reconciled when approvals is set in the spec, so existing Project resources are unaffected.

approvalsBeforeMerge is intentionally left out of the new approvals block, it's already managed via the existing top-level
ProjectParameters.approvalsBeforeMerge field (a different GitLab API), and duplicating it here would create two reconciliation paths for the same underlying setting.

Note on design:
I went back and forth on whether this should be a separate CRD (similar to the existing ApprovalRule resource) instead of a field on Project.
I ended up embedding it because these settings have no identity or lifecycle independent of the project they belong to, but I'm not fully set on this, so happy to split it out into its own resource if maintainers prefer that instead.

I have:

  • Read and followed Crossplane's [contribution process].
  • Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

Tested it on one of our clusters with real data and we're currently using it in production.

@alexandre-allard
alexandre-allard force-pushed the feat/mr-approval-settings branch from 5820f2c to 31204ab Compare July 30, 2026 09:06
GitLab exposes project-level merge request approval settings
(reset-on-push, author/committer self-approval, reauthentication, etc.)
through a dedicated /projects/:id/approvals endpoint that is separate
from the main project update API. Expose it as an optional `approvals`
block on the existing Project resource, following the same pattern as
`pushRules`, rather than a separate CRD, since it has no independent
identity or lifecycle apart from the project it belongs to.

Fields are only reconciled when `approvals` is set in the spec, so
existing Project resources are unaffected.

Signed-off-by: Alexandre Allard <alexandre.allard@proton.ch>
@alexandre-allard
alexandre-allard force-pushed the feat/mr-approval-settings branch from 31204ab to 32934f5 Compare July 30, 2026 09:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant