feat: support project importURLSecretRef

[BoxBoxJason]

Description of your changes

After a long time lost in the abyss, Closes #48

This PR makes it possible to use importUrl from a secret reference in the Project CRD !
There was also a small refactor to put the UpdateStringFromSecret in a common section to be reusable (and already reused) in multiple packages.

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

• I have a self hosted gitlab instance in my homelab (I can share the link with reviewers if required)
• I don't use docker (and I don't have it installed), instead I use podman on my Fedora 43 (Workstation) machine
• I setup a kind cluster with the KIND_EXPERIMENTAL_PROVIDER=podman, using kind create cluster --name gitlab
• I install the crossplane helm chart
  1. helm repo add crossplane-stable https://charts.crossplane.io/stable
  2. helm install crossplane --namespace crossplane-system --create-namespace crossplane-stable/crossplane
• I build the go code make go.build and then run it ./_output/bin/linux_amd64/provider --debug
• I create the secret with my PAT (admin permissions) k create secret generic gitlab-credentials -n crossplane-system --from-literal=token=EXAMPLE_VALUE
• I apply the providerconfig manifest:

  apiVersion: gitlab.m.crossplane.io/v1beta1
  kind: ProviderConfig
  metadata:
    name: gitlab-provider
    namespace: default
  spec:
    baseURL: https://REDACTED_URL/
    credentials:
      source: Secret
      method: PersonalAccessToken
      secretRef:
        namespace: crossplane-system
        name: gitlab-credentials
        key: token

(This requires having the source authorized on the gitlab instance)

• I apply the examples/instance/project.yaml (with a tweak to use importUrlSecretRef)
• I check that the project is created and no errors appears.
• I update the CRD with new values and check again for errors / that they are applied
• I delete the gitlab project manually and confirm that they are reconciled
• I delete the resource and check that nothing new happens, the resource gets deleted properly

[henrysachs]

@BoxBoxJason would you be so kind and merge master into your branch so the pipeline hopefully succeeds?

[henrysachs]

can you fix the lint error please? @BoxBoxJason

[BoxBoxJason]

can you fix the lint error please? @BoxBoxJason

Hey there, I have rebased the branch and the CI now passes without issues, I was waiting for #284 to reduce the cyclomatic complexity introduced in #281

Things are functionnal now 😄

[henrysachs]

Hey, nice work on the DeepCopy approach in Observe — that makes sense to me!

I have a question about Create though: the comment says "this is only required for observation, as this is the only method where spec can be updated" — but could you double-check whether UpdateCriticalAnnotations after Create() returns does a full client.Update(ctx, managed) to persist the external-name annotation? If so, I think the mutated ImportURL (with the resolved secret value) would end up in the Custom Resource's spec.forProvider.importUrl field — visible to anyone with read access to the CR.

A second thing I noticed in Observe: the secret gets resolved into current (the DeepCopy), but isProjectUpToDate at line 183 reads &cr.Spec.ForProvider where ImportURL is still nil. Doesn't that mean drift on the import URL would never be detected when using ImportURLSecretRef? And wouldn't ResourceLateInitialized (!cmp.Equal(current, &cr.Spec.ForProvider)) always be true since current.ImportURL differs from the original?

Would be great if you could verify — might be that I'm missing something here!

[BoxBoxJason]

Hey there @henrysachs, sorry about that PR, I clearly did not test it properly.

Good catch about the two infinite update loops caused by the improper comparisons in late initialization / up to date tests. The creation was successful but the drift was not detected.
Fortunately, it did not have a real impact because updating the import URL cannot be done through the UI. It can only be updated via the API, and doing so does not update anything in the content of the git repository, it only changes the value of import_url.
This was fixed anyway because it messed with the status of the crossplane resource.

This time I also tested with an authenticated repository to import and found out that the import_url returned by the GitLab API is sanitized (user info is removed from the URL), meaning that a credentials update cannot be detected using the API (which does not have a big impact, since updating import_url after project creation does not do anything as of gitlab 18.8.2). That was an undected bug in the pre existing importUrl field, which is now fixed 😁

You are also correct about the deep copy mechanism needed to be used in all methods, as the sensitive url with credentials did end up in the CR (Although I cannot confirm if it was due to "Create" and / or "Update" call).

Tell me what you think about this revised version.