gitlab modules: deprecate basic auth method

[lgatellier]

SUMMARY

This PR deprecates basic auth for GitLab modules, since this auth method has been removed from GitLab a long time ago (in GitLab 9.5, released in August 2017, if I'm right).

It will allow to remove some specific code from module_utils/gitlab.py and enhance maintainability.

ISSUE TYPE

• Refactoring Pull Request

COMPONENT NAME

gitlab_deploy_key
gitlab_project_badge
gitlab_hook
gitlab_project_variable
gitlab_label
gitlab_instance_variable
gitlab_project_members
gitlab_project_access_token
gitlab_group_access_token
gitlab_merge_request
gitlab_branch
gitlab_project
gitlab_milestone
gitlab_runner
gitlab_protected_branch
gitlab_group_variable
gitlab_user
gitlab_group_members
gitlab_group
gitlab_issue

ADDITIONAL INFORMATION

Another PR will follow to remove this code in community.general v9.0.0

[ansibullbot]

cc @Lunik @Shaps @marwatk @metanovii @nejch @scodeman @sh0shin @suukit @waheedi @zanssa
click here for bot help

[nejch]

LGTM. I seriously doubt there'd still be any GitLab instances out in the wild still supporting basic auth.

Personally I'm also not sure if job token auth makes sense, because none of the current GitLab API resources in the modules here support job token auth. Just for your consideration if you think it would simplify things more. See https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html.

community.general/plugins/module_utils/gitlab.py

Line 109 in cd01a92

gitlab_job_token = module.params['api_job_token']

.

(not sure if this also warrants a changelog entry)

[lgatellier]

Thanks for your review @nejch !

LGTM. I seriously doubt there'd still be any GitLab instances out in the wild still supporting basic auth.

I hope no one still run such old versions. 🤞

Personally I'm also not sure if job token auth makes sense, because none of the current GitLab API resources in the modules here support job token auth. Just for your consideration if you think it would simplify things more. See https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html.

community.general/plugins/module_utils/gitlab.py

Line 109 in cd01a92

gitlab_job_token = module.params['api_job_token']

.

You're right, but I don't know if it makes sense to remove a feature which would be re-added later for another module (like a gitlab release creation for example).

(not sure if this also warrants a changelog entry)

EDIT : I added a changelog fragment, since deprecated_features key is supported.

I'm also not sure about how to handle sanity issues on module.deprecate() call.

A collection maintainer may help us of the last 3 points.

[felixfontein]

Thanks for your contribution!

[lgatellier]

@felixfontein I just applied your remarks 😉

Should I open another PR removing the deprecated code now, or should I do it once 9.0.0 will be released ?

You're right, but I don't know if it makes sense to remove a feature which would be re-added later for another module (like a gitlab release creation for example).

What do you think about that (see details in the previous comments) ?

[felixfontein]

Should I open another PR removing the deprecated code now, or should I do it once 9.0.0 will be released ?

Once this is merged ;) It won't get merged until we have a stable-9 branch, but since that will happen tomorrow, feel free to already create it ;-)

[felixfontein]

Personally I'm also not sure if job token auth makes sense, because none of the current GitLab API resources in the modules here support job token auth. Just for your consideration if you think it would simplify things more. See https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html.

community.general/plugins/module_utils/gitlab.py

Line 109 in cd01a92

gitlab_job_token = module.params['api_job_token']

You're right, but I don't know if it makes sense to remove a feature which would be re-added later for another module (like a gitlab release creation for example).

That's a good question. It would probably be a good idea to move it to a separate docs fragment, and modify the argspec creation in module_utils to add this only when requested.

Then we can deprecate it from the current set of modules, but still use it later for specific modules where this is actually needed.

What do you think?

[felixfontein]

@lgatellier thanks for your contribution!
@nejch thanks for reviewing!

[lgatellier]

That's a good question. It would probably be a good idea to move it to a separate docs fragment, and modify the argspec creation in module_utils to add this only when requested.

Then we can deprecate it from the current set of modules, but still use it later for specific modules where this is actually needed.

What do you think?

Thats a nice solution, thanks for your advice !