feat: Support for Self-Hosted Gitlab.

[jmj0502]

Solves #78

• A new function was added to the file clients/gitlabClient.go; the generateGitlabClient function will generate a common client or client with a custom URL extracted from the configurations provided by the user.
• The gitlabClientURL config key was added to list of ConfigAvailableKeys on the file cmd/config/main.go file.

[jmj0502]

@dimabru Hey! Hope you're doing great!

I started to implement the feature and I'm taking the path you mentioned (adding a key to the ConfigurationManager). However, I have some questions. How can I define a Key using the Set method on the ConfigurationManager? (I haven't found any example on the docs).

I know you might be busy, so feel free to answer when you have some free time c:

[dimabru]

Hey @jmj0502,
Sorry for the late response :)
You can simply use configurationManager.Set("key", "value")

What I suggest to do here is this:
Users should be able to add a configuration key that will point the gitlab client to a custom url address
Add a new key here:

allero/cmd/config/main.go

Line 11 in 7e9c8cd

var ConfigAvailableKeys = []string{"token"}

I suggest gitlabClientUrl

Once you're done with that, users should be able to run allero config set gitlabClientUrl <some-url>

Then, you will need to add a custom url to the gitlabClient.go file - I'm not sure how, need to check their documentation.
You can access any keys given using configurationManager.get("somekey") to get the required value

Please let me know if there's anything else I can help with, and thanks a lot for the contribution!

[jmj0502]

@dimabru Hey! Thanks for the guidance. I think I'm done! We just need to test using a real custom gitlab URL (I don't have any), based on the dummy test I performed, I would say the feature is almost done.

[dimabru]

@jmj0502 ok great!
let's start with undrafting this pr so we can properly review it :)

Make sure to change the pr title to match commit convention

[jmj0502]

@dimabru Donee! The title and the description were updated, in order to meet the provided commit convention.
I'll be waiting for you comments!

[dimabru]

hey @jmj0502,
quick update on your PR: we are looking for someone with local gitlab who can test it for us before we merge. once we make sure it works, we will proceed.

Sorry for the inconvenience and once again, thanks for contributing :)

[jmj0502]

@dimabru Hey! Hope you're doing great!

No worries! I'll be ready in case any change is needed 👍

[rndmh3ro]

I'l test it tomorrow!

[rndmh3ro]

Here's what I did:

# clean state
> rm /home/segu/.allero/repo_files/*

export GITLAB_TOKEN=glpat-; export TOKEN=glpat-

./allero config set gitlabClientURL https://git.example.com

./allero fetch gitlab 7001/cust/
Start fetching gitlab group 7001

> ./allero validate gitlab

[...]

Summary
+-----------------------+----+
| Owners                |  2 |
+-----------------------+----+
| Repositories          |  2 |
+-----------------------+----+
| Pipelines             |  0 |
+-----------------------+----+
| Total rules evaluated | 11 |
+-----------------------+----+
| Failed rules          |  0 |
+-----------------------+----+

/home/segu/.allero/repo_files/gitlab.json is filled with the repositories of the group 7001, but not the subgroup cust.
So only top-level projects from 7001 are fetched, not from 7001/cust/.

When I run ./allero fetch gitlab 7001/cust/ no projects are fetched at all (the json-file is empty).

So I guess the new implementation does work. However there are some other features that need to be implemented in order for it to be useful.

Also archived repositories are also fetched which is unexpected for me.

[jmj0502]

@rndmh3ro Hey! Hope you're doing well! Sorry for the late reply (I've been busy at work) and thanks for this huge help. Cool! The bugs are probably related with missing configurations at the gitlab client level, I'll work on the improvements and let you know when I'm done so you can test again.