Incorrect order of gitlab API call formembers, merge_requests_approval_rules, branches provided for a project

[hiaik]

Describe the bug

For the following config

  "project_group/*":
    merge_requests_approval_rules:
      any:
        name: "Any approver in project"
        approvals_required: 0
        rule_type: any_approver
      enforce: true
    project_settings:
      default_branch: main
    branches:
      main:
        protected: true
        push_access_level: 0
        merge_access_level: 0
        code_owner_approval_required: true
      develop: *default_branch_settings
  "project_group/project":
    members:
      groups:
        group_label_1:
          group_access: 30
        group_label_2:
          group_access: 40
    merge_requests_approval_rules:
      develop:
        approvals_required: 1
        name: "develop branch"
        groups:
          - group_label_1
        protected_branches:
          - develop
      main:
        approvals_required: 1
        name: "main branch"
        groups:
          - group_label_2
        protected_branches:
          - main
    branches:
      main:
        allowed_to_merge:
          - group: group_label_1
      develop:
        allowed_to_merge:
          - group: group_label_2

I am getting error:

Request url='.../protected_branches?name=develop', method=POST, json='{"allowed_to_merge": [{"group_id": 21305}], "allowed_to_push": [{"user_id": 2633}, {"user_id": 3598}], "code_owner_approval_required": true, "merge_access_level": 30, "push_access_level": 0, "unprotect_access_level": 40}' failed - expected code(s) [200, 201], got code 422 & body: '{"message":["Merge access levels group does not have access to the project"]}'

If I leave only

  "project_group/project":
    members:
      groups:
        group_label_1:
          group_access: 30
        group_label_2:
          group_access: 40

It runs successfully, and after that I can run entire config successfully.

I assume there is a broken order for gitlab API calls.

GitLabForm version
3.10.0

GitLab version

16.11.1-ee

[amimas]

I wonder if it's a matter of processing the members config first (after project config). Is it possible some other workflow might require a different order of processing? Not sure.

I have been running gitlabform in 2 stages like you mentioned. First stage in the pipeline only handles members of project/group and other permission related settings (i.e. project visibility, or other access settings) for projects. The second stage in the pipeline does all other settings.

Not sure if this should be classified as bug or feature request :)

[hiaik]

Looks like a bug currently from my POV.

[adam-moss]

Looks like a bug currently from my POV.

I agree, where a feature (i.e. approval_rule) has a dependency on some other config existing we should try to execute in the correct order to support that.

[amimas]

That makes sense. PR is welcome.