<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ## Mass-integrations Vision Today, GitLab supports two ways of setting up integrations. One is a _per-project_ integration, where each integration is configured on an integration-by-integration, project-by-project basis. Alternatively, self-hosted administrators are able to set up Service Templates, which allow for _all projects on that instance_ to inherit the settings on project creation. There are a number of limitations and drawbacks to these features, and this proposal seeks to define a vision for a more robust set of features that allow for instance administrators, group owners, and individual project owners to have deep control over how these settings work. The goal is to make it easy for organizations with thousands of projects to set up complex and sophisticated inheritance, allowing all of those projects to automatically have the correct project settings on a day-one, and on an ongoing basis. These changes should affect **_all_** types of Project services in time, and be the default for any new Project Services that are added. **Key highlights** * This will be accomplished by refining and expanding both Integrations **and** Service Templates. They will diverge slightly in functionality, and will both also be moved to additional contexts. Integrations will be moved "up" to both Groups and Instances, and Service Templates will move "down" to Groups. * Changes to Integrations will include adding a sophisticated inheritance model will allow for overrides at both the Group and Project level, letting individual projects tweak their settings to their specific needs. * Changes to Service Templates will include _removing_ the automatic addition on new-project-creation, instead making them act more like a "template" and less like a "default" value. ## Integrations v2 ### Project-level Integrations Project-level integrations will remain functionally unchanged from their current state. Any projects with services currently configured will continue to act as normally, and nothing should require migration in this new model. However, these new features will be added: **Project-level integrations now inherit Group-level integration values by default** This inherited integration is a one-to-many relationship. When a group-level integration is created, _all projects_ within that group immediately inherit that integration (unless otherwise configured). When a change is made to the group-level integration, that change is reflected directly in each of the projects. **If inheritance is available, all fields on the project-level are optional, and override the inherited setting.** Project-level overrides only affect that project. These can be enabled/disabled at the Group level (configurable), but when available, they allow each project to directly override a specific field. Changes at the Group level do not affect that override, as the overriding value takes precedent over the inherited value. **Project-level integrations can choose to _disable_ this inheritance.**. If the parent-integration allows it (configurable), the Project-level integration can disable the inheritance entirely. This allows projects to have either _no_ integration, or a completely bespoke set of values that are unaffected by inheritance. #### User Stories * As a project owner, I want my project to inherit the Group integrations, so that I don't have to set them myself. * As a project owner with specific integration needs that differ from my Group, I want to be able to override the settings on a per-field basis, so that I can set custom settings specific to my project. * As a project owner who _does not want an integration_, I want to be able to disable the inheritance entirely. * As a project owner with a project inheriting settings, I want those inherited settings clearly displayed in the Project Service page, so it's clear where those settings are coming from and what they are. * As a project owner with a project owner overriding inherited settings, I want those overrides clearly labeled and the original value displayed, so that it's clear what I'm overriding and what the overridden value was. ### Group-level Integrations In the same fashion that Project-level integrations function, Groups will alow gain the ability to add integrations. This integration will apply (by default, but configurable) to all projects within that Group. Like Projects, Groups will inherit the values from an Instance-level integration, if available. **Group-level integrations inherit instance-level integraion values by default.** This inherited integration is a one-to-many relationship. When a Instance-level integration is created, _all Groups_ within that instance immediately inherit that integration (unless otherwise configured). When a change is made to the Instance-level integration, that change is reflected directly in each of the Groups (and thereby, Projects). **If inheritance is available, all fields on the Group-level are optional, and override the inherited setting.** Group-level overrides only affect that Group. These can be enabled/disabled at the Instance level (configurable), but when available, they allow each Group to directly override a specific field. Changes to values at the Instance level do not affect that override, as the Group-level value takes precedent over the Instance-level value. **The Group-level integration can control whether Projects can disable the inheritance.** The default setting should be to _allow_ Projects to disable the inheritance. If this is set to _deny_, then Projects will always have the Group-level inheritance on. **The Group-level integration can control whether Projects can override values.** The default setting should be to _allow_ Projects to override values. If this is set to _deny_, then Projects will be unable to override values from the inheritance. **The Group-level integration can mask individual values.** On a per-field basis, the Group-level configuration can be set to mask any values, preventing projects inheriting those settings from viewing the value directly in the UI or API. * As a Group owner, I want to be able to set the integration settings for all Projects within my Group, so I don't have to set them all manually. * As a Group owner, I want the Projects in my Group to be able to override individual settings, so they can be customized for specific needs. * As a Group owner, I want to be able to disable the ability for Projects to disable the inheritance or override inherited values, so that I can control what they are using and enforce compliance. * As a Group owner, I want to be able to mask inherited values so that Project owners cannot view those values, so that I'm able to control who has access to credentials or other confidential information. ### Instance-level Integrations In the same fashion that Group-level integrations function, Instances will alow gain the ability to add integrations. This integration will apply (by default, but configurable) to all projects within that Instance. **The Instance-level integration can control whether Groups can disable the inheritance.** The default setting should be to _allow_ Groups to disable the inheritance. If this is set to _deny_, then Groups will always have the Instance-level inheritance on. **The Instance-level integration can control whether Groups can override values.** The default setting should be to _allow_ Groups to override values. If this is set to _deny_, then Groups will be unable to override values from the inheritance. **The Instance-level integration can mask individual values.** On a per-field basis, the Instance-level configuration can be set to mask any values, preventing Groups inheriting those settings from viewing the value directly in the UI or API. * As an Instance administrator, I want to be able to set the integration settings for all Groups within my Instance, so I don't have to set them all manually. * As an Instance administrator, I want the Groups in my Instance to be able to override individual settings, so they can be customized for specific needs. * As an Instance administrator, I want to be able to disable the ability for Groups to disable the inheritance or override inherited values, so that I can control what they are using and enforce compliance. * As an Instance administrator, I want to be able to mask inherited values so that Group owners cannot view those values, so that I'm able to control who has access to credentials or other confidential information. ### Inheritance and Override Model * Project settings inherit from Groups which inherit from Instances. * Project overrides take precedent over Groups which take precent over Instances. * Both the ability to inherit and override can be disabled at the Group and Instance level. All possible inheritance flows: | Instance Value | Group Value | Project Value | Final Value | | ------ | ------ | ------ | ------ | | | | foo | **foo** | | | foo | | **foo** | | foo | | | **foo** | | | foo | baz | **baz** | | foo | | baz | **baz** | | foo | baz | | **baz** | | foo | baz | fizz | **fizz** |