<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=40916776&issueIid=6832) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=40916776&issueIid=6832) </details> <!--IssueSummary end--> ## Summary The nested `push_rules` block on `gitlab_group` silently drops user-supplied zero values (`false`, `0`, `""`) when building the create-time API payload. As a result, configurations that intentionally set a field to its zero value are never written to GitLab and the plan diff for the resource persists forever. In the specific case that motivated this report: an instance-level push-rules template enforces `reject_unsigned_commits = true`. We wanted to override it to `false` on a specific group. No HCL combination achieves that with the current provider behavior. ## Affected version `gitlab` provider `v19.0.0` (and earlier — the code path predates v19; this is not a v18→v19 regression). ## Suspected root cause (code-read, not maintainer-confirmed) I traced this by reading the v19.0.0 source. Marking as suspected because I have not added trace logging to confirm the runtime control flow; the analysis is purely from reading the source. Treat as a starting hypothesis for a maintainer to confirm or correct. `expandAddGroupPushRuleOptions` uses `d.GetOk` for each field: https://gitlab.com/gitlab-org/terraform-provider-gitlab/-/blob/v19.0.0/internal/provider/sdk/resource_gitlab_group.go#L1278-1334 ```go if v, ok := d.GetOk("push_rules.0.reject_unsigned_commits"); ok { options.RejectUnsignedCommits = gitlab.Ptr(v.(bool)) } ``` If the documented behavior of `schema.ResourceData.GetOk` applies here (returns `ok=false` for any Go zero value), then this call cannot distinguish "field omitted from HCL" from "field explicitly set to `false`/`0`/`""`". Every field set to its zero value would stay at `nil` in `AddGroupPushRuleOptions`. The create logic then has: https://gitlab.com/gitlab-org/terraform-provider-gitlab/-/blob/v19.0.0/internal/provider/sdk/resource_gitlab_group.go#L1166-1187 ```go if (gitlab.AddGroupPushRuleOptions{}) != addOptions { client.Groups.AddGroupPushRule(...) } else { // Don't create new push rules for defaults for group } ``` If the GetOk hypothesis above is right, the consequences would be: 1. **All fields zero** → struct equals empty struct → API call skipped → no push_rule created → state stays `[]` → plan diff every cycle. 2. **At least one field non-zero** → API call fires, but `false`/zero fields are still omitted from the payload → GitLab fills them with the instance template default → user's intended `false` override is silently ignored. What I'm reasonably sure of (observed, not inferred): - `terraform apply` succeeds. - `GET /groups/<id>/push_rule` returns **404** afterwards (= no push_rule object exists on the group). - Subsequent `terraform plan` shows `push_rules: [] -> [{reject_unsigned_commits=false, rest=null}]` and reports `0 to add, 1 to change, 0 to destroy`. The diff is stable across many apply cycles. - Removing the `push_rules{}` block from HCL eliminates the diff entirely. What's inferred and not yet confirmed: - That the empty-struct skip is actually the path being taken (vs. some other branch). - That the same trap affects `expandEditGroupPushRuleOptions` symmetrically (I read it but didn't repro the update path independently). - Whether companion non-zero fields actually behave as I described in (2) above — I reasoned from the source but did not test. ## Steps to reproduce GitLab instance with a push-rules template that has `reject_unsigned_commits = true` set at the instance level (Admin Area → Push Rules). ```hcl resource "gitlab_group" "test" { name = "drift-repro" path = "drift-repro" push_rules { reject_unsigned_commits = false } } ``` ``` terraform apply # succeeds, but no push_rule created on the group (verify: GET /groups/<id>/push_rule returns 404) terraform plan # shows the resource as `update`, push_rules: [] -> [{reject_unsigned_commits=false, rest=null}] # ... and that diff persists across every apply, forever. ``` Verified by inspecting plan JSON: `prior_state.push_rules = []`, `planned_values.push_rules = [{reject_unsigned_commits=false, rest=null}]`, `change.after_unknown.push_rules = {}` (not computed-unknown — genuinely planned as that literal value). ## Proposed fix Distinguish "not set" from "set to zero" when building the options struct. The historical SDK v2 helper for this was `d.GetOkExists`. It's deprecated but still works and is the standard workaround in the SDK v2 era. Alternatively: - Use `d.GetRawConfig` / `d.GetRawPlan` to inspect whether the attribute is null in config vs. set to zero. - Migrate the resource to terraform-plugin-framework, which represents "null" and "zero" distinctly in the type system. The cleanest narrow fix: replace each `d.GetOk("push_rules.0.<field>")` in `expandAddGroupPushRuleOptions` and `expandEditGroupPushRuleOptions` with `d.GetOkExists` (or framework-style null checks if migrating). The empty-struct early-return at the create site (`(gitlab.AddGroupPushRuleOptions{}) != addOptions`) would also need to change: today it preserves backward compat with old HCL that declares an empty `push_rules{}` block, but with the GetOkExists fix the right behavior is "if any field is explicitly set in config, send the API call". An explicit flag (e.g. `len(d.Get("push_rules").([]interface{})) > 0`) would do. ## Workarounds users have today None inside the provider's nested block. Out-of-band options: - Set per-project `gitlab_project_push_rules` on every project under the group (standalone resource works because `gitlab_project_push_rules` doesn't share this code path with the nested `gitlab_group.push_rules`). - Manage the group-level rule via `null_resource` + `local-exec` calling the GitLab API directly (e.g. `glab api PUT /groups/:id/push_rule -F reject_unsigned_commits=false`). ## References - `gitlab_group` resource doc (nested push_rules schema): https://gitlab.com/gitlab-org/terraform-provider-gitlab/-/blob/main/docs/resources/group.md - GitLab API for group push rules: https://docs.gitlab.com/api/group_push_rules/ - Related: the same `d.GetOk` pattern likely affects every other zero-valued field in the same expand functions on this resource.