-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add immediate deletion of groups #168
Conversation
can you rebase on master? |
@dariozachow MR rebased on master |
Unfortunately this only works for subgroups. Is there some way we can filter for this error |
I would just skip the newly introduced deletion statement if the group to delete is on the root level. Determine if it's a root group, I would by testing |
sounds good to me |
Signed-off-by: Benjamin Bühlmann <[email protected]>
…ve=true' Signed-off-by: Benjamin Bühlmann <[email protected]>
@dariozachow delete logic adjusted as discussed |
Description of your changes
On GitLab Premium and Ultimate, the delete action on a group just marks the group as deleted. By default, the group will be deleted seven days in the future. To delete the group immediately two rest calls are needed:
/groups/:id
which marks the group in the "pending for deletion" state (docs)/groups/:id
with attributespermanently_remove=true
andfull_path
set. The group will be deleted immediate.This change introduce the optional fields
PermanentlyRemove
andFullPath
on the GitLab group resource. This allows the user to enforce an immediate deletion of GitLab groups.The same behavior exist by deleting projects (see #121, #149) and could be implemented in the same way as done here for groups. Before this feature can be implemented for projects, one needs to extend the xanzy/go-gitlab client with
DeleteProjectOptions
along the lines of DeleteGroupOptions.I have:
make reviewable test
to ensure this PR is ready for review.How has this code been tested
Provider has been built locally and deployed on a AKS cluster. Deletion of GitLab Groups has been successfully end to end tested with and without PermanentlyRemove and FullPath fields set.