## Summary Several `Deprecated:` annotations on the project option structs do not match what the GitLab REST API implements. Two groups: 1. `NameRegexDelete` on the container expiration policy structs refers to an API field that does not exist. The rename it assumes was proposed in 2020, closed without being merged, and is still an open upstream backlog item. The field it declares as replaced, `NameRegex`, is the only one that works. 2. Four fields in `CreateProjectOptions` are annotated "No longer supported in recent versions" although they are declared, documented and functional on current GitLab — and the identical fields in `EditProjectOptions` carry no such annotation. Both groups surface as `staticcheck` SA1019 in downstream projects, which leaves users with the choice of migrating to a field that does not exist or suppressing the warning. Verified with client-go `v3.15.0` against a self-managed GitLab `19.4.1-ee`. ## 1. `NameRegexDelete` does not exist in the GitLab REST API Current annotations: ```go // projects.go:1022 — ContainerExpirationPolicyAttributes (write) NameRegexDelete *string `url:"name_regex_delete,omitempty" json:"name_regex_delete,omitempty"` ... // Deprecated: Is replaced by NameRegexDelete and is internally hardwired to its value. NameRegex *string `url:"name_regex,omitempty" json:"name_regex,omitempty"` // projects.go:587 — ContainerExpirationPolicy (read) NameRegexDelete string `json:"name_regex_delete"` ... // Deprecated: use NameRegexDelete instead NameRegex string `json:"name_regex"` ``` ### Upstream status: the rename never happened - [`gitlab-org/gitlab!30108`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/30108) "Rename name_regex to name_regex_delete", opened 2020-04-21, **closed without merging** on 2020-04-29. Review flagged it as a breaking change with no deprecation path, and the author closed it: *"I had a good chat with the PM and we agreed that it was better to leave things as they are right now since there is no benefit to cleaning this up at the moment."* - [`gitlab-org/gitlab#371404`](https://gitlab.com/gitlab-org/gitlab/-/work_items/371404) "Deprecate container cleanup policies `name_regex` and replace it with `name_regex_delete`", opened 2022-08-19, **still open**, labelled `backlog::prospective`. - [`gitlab-org/gitlab#300404`](https://gitlab.com/gitlab-org/gitlab/-/work_items/300404) "name_regex_delete not returned in project API", opened 2021-01-29, closed 2022-02-07 as `stale` / `auto closed` without a fix. The GitLab REST documentation was nonetheless rewritten as though the rename had shipped, including an inline note in the example response reading `// to be deprecated in GitLab 13.0 in favor of name_regex_delete`. I am reporting the documentation side separately to `gitlab-org/gitlab`. ### The field is absent from every layer At tag `v19.4.1-ee`: | Layer | File | Contains | |---|---|---| | REST params | [`lib/api/helpers/projects_helpers.rb#L147-154`](https://gitlab.com/gitlab-org/gitlab/-/blob/v19.4.1-ee/lib/api/helpers/projects_helpers.rb#L147-154) | `cadence`, `keep_n`, `older_than`, `name_regex`, `name_regex_keep`, `enabled` | | REST response | [`lib/api/entities/container_expiration_policy.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/v19.4.1-ee/lib/api/entities/container_expiration_policy.rb) | exposes `name_regex`, `name_regex_keep` (plus cadence, enabled, keep_n, older_than, next_run_at) | | Model | [`app/models/container_expiration_policy.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/v19.4.1-ee/app/models/container_expiration_policy.rb) | attributes and validations on `name_regex`, `name_regex_keep` | | GraphQL | [`app/graphql/types/container_expiration_policy_type.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/v19.4.1-ee/app/graphql/types/container_expiration_policy_type.rb) | fields `name_regex`, `name_regex_keep` | Because the REST parameter is never declared, Grape discards it silently. Note that in the REST layer `name_regex` *is* the delete pattern — its declared description reads "Container expiration policy regex for image removal". ### Reproduction Two requests of identical shape; only the key name differs. ``` PUT /projects/:id?container_expiration_policy_attributes[enabled]=true &container_expiration_policy_attributes[cadence]=1d &container_expiration_policy_attributes[keep_n]=5 &container_expiration_policy_attributes[older_than]=14d &container_expiration_policy_attributes[name_regex_keep]=KEEP-ME &container_expiration_policy_attributes[name_regex_delete]=DELETE-ME → 200, cadence/enabled/keep_n/older_than/name_regex_keep all applied, name_regex unchanged at ".*", no name_regex_delete in the response ``` ``` … same request, name_regex=DELETE-ME instead of name_regex_delete → 200, name_regex = "DELETE-ME" ``` Every other key in the first request was accepted, so the request shape is valid — only that one key is discarded. The same holds for `POST /projects`. `name_regex_delete` never appears in any response. ### Suggested change - Drop the `Deprecated` annotation from `NameRegex` in both structs. It is the field the API implements, for reading and for writing, and upstream decided against renaming it. - Remove `NameRegexDelete` from both structs, or document that the API neither accepts nor returns it. As it stands, setting it is a silent no-op and reading it always yields the zero value. ## 2. Four fields marked "No longer supported in recent versions" still work ```go // projects.go:992-1009 — CreateProjectOptions // Deprecated: No longer supported in recent versions. CIForwardDeploymentEnabled *bool // Deprecated: No longer supported in recent versions. IssuesTemplate *string // Deprecated: No longer supported in recent versions. MergeRequestsTemplate *string // Deprecated: No longer supported in recent versions. ServiceDeskEnabled *bool ``` On GitLab 19.4.1-ee all four are declared as API parameters and documented 4–5 times each in `doc/api/projects.md`. `ci_forward_deployment_enabled` is declared in `optional_update_params_ce`; `issues_template`, `merge_requests_template` and `service_desk_enabled` in the EE helper. Live writes: | Parameter | Sent | Result | |---|---|---| | `ci_forward_deployment_enabled` | `false` | applied, previous value `true` | | `issues_template` | `PROBE-ISSUE` | applied | | `merge_requests_template` | `PROBE-MR` | applied | | `service_desk_enabled` | `true` | unchanged — Service Desk was not enabled in the test environment, so this is not a valid data point | `EditProjectOptions` declares the identical four fields (`projects.go:1119`, `1139`, `1149`, `1183`) without any deprecation annotation, so the library contradicts itself for the same API parameter. ### Suggested change Remove the annotations, or — if specific GitLab versions did drop support — name the version and apply the annotation consistently to `CreateProjectOptions` and `EditProjectOptions`. ## Environment - client-go `v3.15.0` - self-managed GitLab `19.4.1-ee` - GitLab source references at tag `v19.4.1-ee`