Feature: Gitlab module will not always work with internal service names

[xrow]

SUMMARY

Enabling this switch allows the the gitlab module to communicate over internal host names with the api.

gitlab.example.com <- Public Host / Ingress
gitlab.gitlab.svc:8080 <- Internal Service name in Kubernetes

ISSUE TYPE

• Feature Pull Request
• Refactoring Pull Request

COMPONENT NAME

gitlab

[ansibullbot]

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

[felixfontein]

Thanks for your contribution! Can you please add a changelog fragment? Thanks.

Also, did you check which versions of the Python gitlab library support keep_base_url?

[xrow]

@felixfontein keep_base_url was added in https://github.com/python-gitlab/python-gitlab/releases/tag/v3.8.0 which is 2 years ago. Do I need to add a contraint somewhere? Else feel free to merge.

[felixfontein]

The modules likely also support older versions of python-gitlab, and this PR would break these older versions. (gitlab_branch for example explicitly supports python-gitlab >= 2.3.0.) Can you adjust the PR to only provide the option for versions that support it?

[xrow]

@felixfontein Hi, I am a bit confused. The change affects all the modules, since it is a change in the client used globally. To me it looks more like we shall lift the requirements to >= 3.8.0 for all gitlab modules accept gitlab-runner.

[felixfontein]

To me it looks more like we shall lift the requirements to >= 3.8.0 for all gitlab modules accept gitlab-runner.

That's a breaking change and will not get merged.

[xrow]

Ok that is fine with me... though can you plan it for next major?

[felixfontein]

A breaking change first requires a deprecation, which doesn't exist in this case. Also I don't see why the minimum version should be bumped if this can be easily solved by checking the version of python-gitlab. The file you changed has multiple examples of how that works.

[xrow]

@felixfontein Good point. I see now what you want.

[xrow]

@felixfontein You can review again. Thanks for your tip.

[xrow]

@felixfontein "FATAL: Environment --docker fedora40 is unknown. " Looks like there are temporary runner issues. Nothing i can fix here.

[felixfontein]

@felixfontein "FATAL: Environment --docker fedora40 is unknown. " Looks like there are temporary runner issues. Nothing i can fix here.

Will get fixed by #9552.

[felixfontein]

Restarting CI.

[felixfontein]

Hmm, looks like it didn't help. I guess you have to add another commit, or rebase with latest main.

[xrow]

@felixfontein Ok thanks for the help. Your turn again.

[russoz]

hi @xrow thanks for your contribution.

Your changelog frag needs a small adjustment, other than that it LGTM.

[felixfontein]

Ping @Lunik @Shaps @lgatellier @marwatk @metanovii @nejch @scodeman @sh0shin @suukit @waheedi @zanssa - I hope that some of you might be familiar with keep_base_url and whether it is safe to enable it by default.

[nejch]

Sorry @felixfontein on vacation now so slipped my emails :)

I would personally make this configurable but disabled by default because it's almost like abusing the default external URL on the gitlab instance (gitlab doesn't support multiple external URLs yet). For the most part it works but some list endpoints and redirects might be broken this way IMO but it's been a while so not sure if that's improved.

Here are my thoughts on this from the initial PR for the library: python-gitlab/python-gitlab#2149 (comment)

[xrow]

@nejch

It looks like there is no impact on the external url, because of if not next_url.startswith(self._gl.url):

https://github.com/python-gitlab/python-gitlab/pull/2149/files#diff-cfa2b05f7b559e334405867e2c02564c88032f0dee928f61cba4b84d3d680886R1143