CRD GitHub repository secrets

[Giomaster]

Description of your changes

Fixes #

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

[Giomaster]

I try to run make reviewable test but i got some errors about some packages (Please, see details below to understand better the issue). Any help must be appreciated 😀

[Feggah]

• I think we shouldn't change the folders structure for fake. Using provider-aws as a model, they use the fake folder inside each resource. We can follow this same pattern.

• There is a problem with this managed resource name. We can't have two resources with the same name: the Kubernetes built-in secret and the repository secret.
  If we try to use kubectl get secret, it won't return the repository secrets. We need to change it, so we can easily get/describe repository secrets without conflicting with K8S secrets. I was thinking in something like githubsecret or ghsecret, any thoughts?

• Last but not least, you need to sign off all your commits. Please, read the crossplane contribution process.

[Feggah]

Checking the GitHub API, the Repository Secret is in Actions group. IMHO the folder structure should be actions/<...>. For example:

• apis/actions/v1alpha1/repositorysecret_types.go
• examples/actions/repositorysecret.yaml
• pkg/clients/actions/repositorysecret.go
• pkg/controller/actions/repositorysecret.go

[Feggah]

Just two more nitpicks.

I have misinterpreted the behavior of the SDK in the method CreateOrUpdate, sorry for my reviews about it :)

[Feggah]

Looks pretty good @Giomaster ! Just added one more nitpick. After this, I will merge the PR.

Thanks! 🚀

[Feggah]

Sorry for my last approval, we may need to modify the code again. I was thinking in one use case and the CRD will not behave as expected.

If the user wants to "import" a secret (I know we can't import it, just create/update), this means that the CRD will update its value to which is defined in the K8S secret reference. But the problem is: the actual request will be an UPDATE (because the Repository Secret already exists in GitHub), but if you describe the resource, it will log that the resource have been CREATED (we expected it to be UPDATED).

This inconsistency is just a detail, but we must log properly to help investigating future issues.

To fix it, we may need to change this code:
https://github.com/stone-payments/provider-github/blob/2679fce4f836ac2c91889ced5d0dcac798582bd5/pkg/controller/actions/repositorysecrets.go#L101-L104
To a GET request, then, the IsUpToDate will return false (because we will compare hashes from the K8S Secret and Status -- which will be empty).

With this false response from IsUpToDate, crossplane-runtime will call Update() instead of Create().

If the GET request doesn't find any secrets, thats because we need to create the secret.

Fixing this, the logs behavior will be fixed :)

The code will be something like this:

sec, _, err := gh.GetRepoSecret(ctx, cr.Spec.ForProvider.Owner, cr.Spec.ForProvider.Repository, meta.GetExternal(name))
if err != nil {
	return managed.ExternalObservation{}, errors.Wrap(err, "cannot get Secret")
}

You still can ignore the error returned by the GetRepoSecret if the response status code is 404, which just means that we need to create the resource.

How to reproduce this issue

1. Create a secret in any repository in GitHub using the interface.
2. Apply the RepositorySecret manifest in Kubernetes with the same external-name as you defined in the step above.
3. kubectl describe the RepositorySecret.

You will see that the log will contain CreatedExternalResource, but it should be UpdatedExternalResource

[Feggah]

LGTM! Great work :)