Support GitLab group resource with full path

[ahauserv]

What problem are you facing?

I want to create a observe-only GitLab group resource, but I only know the full path of the group, but not the ID.

How could Crossplane help solve your problem?

Similar to the GitLab API and the terraform provider for GitLab, support lookup via the full path and not only the ID.

Example:

apiVersion: groups.gitlab.crossplane.io/v1alpha1
kind: Group
metadata:
  name: team-a-observed
  annotations:
    crossplane.io/external-name: platform/team-a  # At the moment only a numeric ID is supported here
spec:
  managementPolicies:
    - Observe

[markussiebert]

Thanks @ahauserv — this makes sense and we'd support it. A couple of notes on how we'd want it done, since GitLab's identity model matters here.

No new spec field needed — reuse crossplane.io/external-name, mirroring GitLab's own disambiguation. GitLab's GET /groups/:id already accepts either a numeric ID or the URL-encoded full path, and the go-gitlab client already takes any and URL-escapes it, so:

• numeric external-name → treated as the group ID (today's behavior),
• non-numeric → treated as the URL-encoded full path.

The current blocker is just the strconv.Atoi(externalName) gate in the group controller's Observe.

Identity: we must key on the immutable ID, because path/full_path are mutable (a group can be renamed or transferred). So the path should only ever be a bootstrap lookup, after which we track the numeric ID: on the first Observe, resolve the path via GetGroup, then meta.SetExternalName(cr, <id>) and return ResourceLateInitialized: true. From then on the resource tracks the immutable ID and a later rename/transfer is irrelevant.

One thing to be aware of: persisting that pin relies on late-init, which is a distinct management-policy action. So the resource needs LateInitialize in its managementPolicies — for the observe-only case in your example that means:

spec:
  managementPolicies:
    - Observe
    - LateInitialize

With LateInitialize present, the resolved ID is written back to the external-name and pinned. With plain [Observe], the pin won't persist and the provider would just re-resolve the path on every reconcile (fine as long as the path is stable).

The same pattern applies to Projects (project full path), if someone wants to cover both.

We're a community-driven provider, so we'd be very happy to see a PR along these lines — feel free to pick it up, and shout on the issue if you'd like to discuss anything further.

[markussiebert]

One caveat: I'm not 100% sure the external-name pin via late-init behaves exactly as described — I haven't set external-name from within the late-initialize path before. In principle the full-object update that runs on ResourceLateInitialized: true should persist the annotation, but this needs to be tried out to confirm it actually sticks (especially the [Observe, LateInitialize] observe-only combination). So treat the pinning detail as the intended direction rather than a guarantee — worth a quick spike as part of any PR.