Breaking changes proposals for GitLabForm 2.*

[gitlabform]

Breaking changes proposals for GitLabForm 2.*

[weakcamel]

The only other part of syntax I find slightly unclear and potentially to be considered while bumping the major version is the configuration of groups.

Currently there are group_settings which are actually applicable to projects in a group and there are e.g. group_secret_variables which are under common_settings.

As Gitlab seems to allow more and more options to be defined on group level (plus there is a ticket to implement instance level settings - https://gitlab.com/gitlab-org/gitlab-foss/issues/3897), it would be clearer to distinguish that.

[amimas]

@gdubicki - Should this be closed?

[rbartuzel]

Hi @gdubicki !

As I understand you are going to migrate some functionalities of GitLabForm to using a new version of API that enforce some breaking changes in configuration.

Are you going to implement Protected branch in the way described here https://docs.gitlab.com/ee/api/protected_branches.html with all possible configuration options including Branch protection on user basis or it should be implemented as a separate issue like #99?

[gdubicki]

Hey @rbartuzel !

Frankly I don't currently have the time to work on big changes to GitLabForm, like 2.0. So if anyone wants more of Protected branches API features it would be best to create PRs for specific things. Update: see #227.

[glensc]

If the breaking change is format of the config file, please include a converter! :)

[gdubicki]

I have developed a proposal of a config syntax for v2.

It splits group configs from the projects configs to avoid ambiguity that @weakcamel has mentioned above (But btw: group_settings ARE settings for the group as they operate on the API for groups, not projects - https://docs.gitlab.com/ee/api/groups.html . However by the nature of the group which is a container for projects, effectively they do apply mostly to projects within it.).

Thanks to that split we can introduce new selectors for the configuration of groups and projects, including personal ones (#106). This will allow choosing groups and projects by using regexp patterns (which is a feature that there is no ticket for, but that we would benefit from it at Egnyte).

Please check out #138 and share your opinions. :)

[gdubicki]

I have just pushed an updated proposal of the config syntax. 😅

As I have tried using the splitted version in practice (for Egnyte's config) it turned out that strict separation of groups and projects makes configuration that relates to the same things split into 2 possibly distant configuration fragments. The reason for that is exactly the fact that I mentioned above - groups are basically containers for projects...

UPDATE: ...BUT at the same time I did prefix all the config sections applying to projects with "project_" and similarly for groups - "group_". This way we DO have the distinction between these 2 types of configs.

So please check out the updated config example in #138. ;)