when running for a single group, its subgroups should be included

[exaV]

There is currently a unintuitive behaviour when it comes to running config for a single group.

Consider the following config file:

csi/*:
        project_settings:
            allow_merge_on_skipped_pipeline: false

csi/my-subgroup/*
      group_members:
          users:
              myself:
                  access_level: maintainer

csi/my-subgroup/project-a:
            allow_merge_on_skipped_pipeline: true
csi/project-b:
            allow_merge_on_skipped_pipeline: true

Here we define some settings for projects inside the top level csi group. We also specifically add some users as group members to the group csi/my-subgroup. Unfortunately settings for that subgroup are only applied when we run with ALL_DEFINED or ALL or csi/my-subgroup but not when we run for csi. Considering the behaviour of ALL I find this a bit counter-intuitive.

Example output:
pipx run gitlabform csi:

🏗 GitLabForm version: 3.8.0 = the latest stable 😊

Getting requested groups or projects...
:: # of groups to process: 1 <---------------------------------------- subgroup is excluded
:: # of projects to process: 2

pipx run gitlabform ALL_DEFINED:

Getting requested groups or projects...
:: # of groups to process: 2 <---------------------------------------- subgroup is included
:: # of projects to process: 2

What should happen:
Running pipx run gitlabform csi should also update all subgroups of csi.

[exaV]

As far as I can tell this could be accomplished by using the https://docs.gitlab.com/ee/api/groups.html#list-a-groups-descendant-groups api after having loaded the group here https://github.com/gitlabform/gitlabform/blob/main/gitlabform/lists/groups.py#L28

We would also have to consider "excluded" groups afterwards.

[amimas]

It sounds like a bug and I agree with you about the expected behaviour. I've been using ALL_DEFINED so far. Maybe @gdubicki can help confirm the issue or suggest something.

PRs are welcome. @exaV - will you be able to help with this?

[amimas]

This came up during the above PR review.

I feel the subgroups should also be included. Otherwise it's an unintuitive behaviour. If anyone doesn't want a subgroup to be processed, they can use the skip_groups key in the config to control what subgroup to be excluded. It can be argued that listing every subgroup in the config is tedius and maybe an additional CLI flag is needed to indicate all subgroup processing should be excluded; e.g. gitlabform csi --skip-subgroups would work the way it does today.

This feels like a potentially breaking change and is best to be handled so that a major version is released with this change.

@gdubicki @jimisola - What do you think?

@exaV - will you be able to help contribute this change?

[gdubicki]

I completely agree - it should work this way, but it's a breaking change that should increase the major version. But because we version the configuration files we can do it safely with gitlabform v4 requiring config_version: 4. If you would have still version 3 of the config then we would print a link to the upgrade guide that would say about the change and about the --skip-subgroups flag to use if you want to keep the old behaviour.

[gdubicki]

Please check out an initial proposal for implementing this here https://github.com/gitlabform/gitlabform/wiki/Current-and-proposed-way-of-selecting-targets