amimas

Is this somewhat resolved with the inheritance breaking feature, without a big overhaul of config syntax in next major release?? https://gitlabform.github.io/gitlabform/reference/#breaking-inheritance

Maybe `skip` config can be deprecated in future minor release and remove in v3. Would be nice if the tool can print warning if this flag gets used while deprecated.

One work-around could be yaml anchors. You can move the shared configs into one or more yaml anchor and then apply them wherever needed.

From a config syntax perspective, the following can be confusing. ```yaml projects_and_groups: "*?team-red": project_settings: merge_method: ff ``` To me, it is unclear what project I'm applying the config. Maybe add...

I think the inheritance feature might need to be enhanced or clarified where it can be used.

I wonder whether we should consider converting this feature request to be more generic. Ability to retrieve projects using various filter option instead of being restricted to just `topic`. According...

I wonder if bitbucket related config automation should be a separate project. Otherwise this could become a monolith and hard to test/maintain. As for a new name, I struggled with...

I like the idea of `extends` in gitlabform config. It feels more intuitive. Haven't thought too much about referring to multiple config file through cli parameter.

Since `inherit` flag is implemented through #326 , maybe `skip` flag can be deprecated now and be removed in ~v3~ v4? Or, is that still needed?

The proposal looks good to me @gdubicki . For the new syntax of setting custom approval rules: > the values under these keys are like in https://docs.gitlab.com/ee/api/merge_request_approvals.html#create-project-level-rule but: > >...