merge_requests/approvals is replaced instead of merged

[GianlucaFicarelli]

Hi, it seems that nested configurations defined in both common_settings and group_settings are replaced, instead of merged.

For example, when defining a configuration like this:

common_settings:
  merge_requests:
    approvals:
      approvals_before_merge: 3

group_settings:
  "group_name":
    merge_requests:
      approvals:
        merge_requests_author_approval: true

and running

gitlabform -v --noop -c config.yaml group_name/project_name

The result is

GitLabForm version: 1.21.0 (the latest)
Reading config from file: config.yaml
Connected to GitLab version: 13.10.3-ee (db2e358dba4)
Reading config from file: config.yaml
*** # of groups to process: 0
*** # of projects to process: 1
* [1/1] Processing: group_name/project_name
Processing merge_requests in dry-run mode.
Project group_name/project_name approvals changes:
merge_requests_author_approval: "???" => true

i.e. only merge_requests_author_approval is applied, while I would expect that both the configurations are applied:

• approvals_before_merge from common_settings
• merge_requests_author_approval from group_settings

What is the expected behaviour?
Should the approvals sections be merged together as I was expecting?

[gdubicki]

Thanks for reporting this @GianlucaFicarelli !

I am quite surprised as this is the key feature, we have tests for that and at a first glance I have no idea what went wrong here.

[gdubicki]

Yep, it doesn't work as advertised: https://github.com/egnyte/gitlabform/pull/202/checks?check_run_id=2481356380 :(

[gdubicki]

This issue makes me a bit sad not only as an author of the code that contains the bug but also because no user of the app notices it until now...

But let's move on.

I think that we cannot fix it in v1.x because this may change the behavior of the app for existing users, who were relying on the way the application generates the effective configs per group and project.

That's why I plan to:

• fix it in v2.0,
• add a feature to generate the effective configs per groups and projects to both v1.x and v2.x so the users switching to v2 can do that safely by comparing the outputs between versions,
• release v2.0 beta and start advertising it as a recommended version,

Opinions? :)

[gdubicki]

I have implemented the 2nd bullet point, released in v1.23.0.

Can you please rebase your PR to branch v2, @Pigueiras ?