fix a bug where improper permission enumerations caused gitlab_member_role to fail
What does this MR do and why?
memberRoleCreate and memberRoleUpdate built their mutations with fmt.Sprintf and interpolated the permissions slice straight into the query text. Go renders a []string as [READ_CODE ADMIN_MERGE_REQUEST] — no commas, no quotes — which is not a GraphQL enum list.
The parser fell back to reading it as a global ID, so creating a role with permissions failed with READ_CODE is not a valid global id. That message points at the permission rather than at the malformed list, which is why this was hard to diagnose from the error alone.
Update was affected as well, through %v rather than %s. Both produce the same malformed output.
All four operations now pass arguments through GraphQLQuery.Variables, typed with the input types the schema declares: MemberRoleCreateInput, MemberRoleUpdateInput, MemberRoleDeleteInput, and MemberRoleID for the read. The query documents are now static and the client encodes the values.
That also takes name, description and groupPath out of the query string. The SaaS-only groupPath handling gets simpler as a result: instead of splicing a groupPath: "...", fragment into the mutation text, it is now an entry in the input map.
Two things worth a look:
permissions is now initialised as an empty slice rather than left nil. A nil slice marshals to null, while the old Sprintf produced []. Without this, moving to variables would have quietly changed what an empty permission list sends.
The first step of TestAccGitlabMemberRole_basic now creates a role with two permissions instead of one. This is why the existing suite never caught the bug: a single-element slice renders as [READ_VULNERABILITY], which GraphQL parses happily. The defect only appears at two or more.
Differences
Before: a gitlab_member_role with two or more enabled_permissions could not be created. The request carried permissions: [READ_CODE ADMIN_MERGE_REQUEST] and GitLab replied READ_CODE is not a valid global id. A single permission happened to work.
After: permissions travel in the request body as a JSON array, "permissions":["READ_CODE","ADMIN_MERGE_REQUEST"], and roles create and update normally regardless of how many permissions are set.
How to set up and validate locally
go build ./...
go vet ./internal/provider/
go test ./internal/provider/Acceptance coverage needs a live instance:
TF_ACC=1 go test ./internal/provider/ -run TestAccGitlabMemberRole_basicManually, applying a gitlab_member_role with two or more enabled_permissions now succeeds where it previously failed with is not a valid global id.
Related to
- Fixes #6884 (closed)