Tim Knight

The reason this ends up happening, is because in `_merge_configs` in `core.py` it merges together the group and project level settings with project winning if there is a more specific...

@amimas I can give `inherit: false` a try - I've got a Functional Test for it kicking around now in GLF code-base to show as an example. Yeah it would...

@amimas I think we have definetly fallen afoul of specifying some "group" settings under the `group/*` heading, perhaps we need to be clearer in the documentation and feedback, some kind...

@amimas @Anedaar One example I can think of which would be fixed by this is `integrations` ``` group/*: integrations: gitlab-slack-application: use_inherited_settings: false merge_requests_events: true merge_request_channel: maintainers ``` In this scenario...

I think just unit tests work here, I think only self-managed Gitlab could be behind 17 now, their update cadence means gitlab.com is on 18, and "dedicated" instances will be...

@BenediktBertsch I think where you phyiscally put the code and when you call it makes the most sense, I can't think of any neater ways of doing so

Unless we set the version as a global variable on initialisation - in case we need them in other places in future

Sounds good, this should hopefully be a case of updating the relevant processor to support the new APIs in 18.3 We have some functionality existing allowing you to check if...

@hiaik @amimas - If you do re-raise something with GitLab (it is on their end for sure, they do a lot of async processing now), please let me know and...

@amimas I am not sure how well using the key would work, for example we have a ``` saml_group_name: "APPG - Gitlab UCD" ``` So how would GLF correctly parse...