> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/229161) in GitLab 13.3.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/229161) in GitLab 13.3.
...
@@ -290,13 +313,17 @@ The [`Project#feature_available?`](https://gitlab.com/gitlab-org/gitlab/blob/4cc
...
@@ -290,13 +313,17 @@ The [`Project#feature_available?`](https://gitlab.com/gitlab-org/gitlab/blob/4cc
[`License.feature_available?`](https://gitlab.com/gitlab-org/gitlab/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/ee/app/models/license.rb#L293-300)(EE) methods all implicitly check for
[`License.feature_available?`](https://gitlab.com/gitlab-org/gitlab/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/ee/app/models/license.rb#L293-300)(EE) methods all implicitly check for
a by default enabled feature flag with the same name as the provided argument.
a by default enabled feature flag with the same name as the provided argument.
You'd still want to use an explicit `Feature.enabled?` check if your new feature
isn't gated by a License or Plan.
**An important side-effect of the implicit feature flags mentioned above is that
**An important side-effect of the implicit feature flags mentioned above is that
unless the feature is explicitly disabled or limited to a percentage of users,
unless the feature is explicitly disabled or limited to a percentage of users,
the feature flag check will default to `true`.**
the feature flag check will default to `true`.**
CAUTION: **Caution:**
Due to current limitations of `feature_available?` the YAML definition
for licensed feature flags accepts only `default_enabled: true`.
This is subject to be improved as part of the https://gitlab.com/gitlab-org/gitlab/-/issues/218667.
#### Beta/alpha licensed feature flags
This is relevant when developing the feature using
This is relevant when developing the feature using
[several smaller merge requests](https://about.gitlab.com/handbook/values/#make-small-merge-requests), or when the feature is considered to be an
[several smaller merge requests](https://about.gitlab.com/handbook/values/#make-small-merge-requests), or when the feature is considered to be an
[alpha or beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#alpha-beta-ga), and
[alpha or beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#alpha-beta-ga), and
...
@@ -311,6 +338,23 @@ GitLab.com and self-managed instances, you should use the
...
@@ -311,6 +338,23 @@ GitLab.com and self-managed instances, you should use the
method, according to our [definitions](https://about.gitlab.com/handbook/product/gitlab-the-product/#alpha-beta-ga). This ensures the feature is disabled unless the feature flag is
method, according to our [definitions](https://about.gitlab.com/handbook/product/gitlab-the-product/#alpha-beta-ga). This ensures the feature is disabled unless the feature flag is
_explicitly_ enabled.
_explicitly_ enabled.
CAUTION: **Caution:**
If the `beta_feature_available?` or `alpha_feature_available?` is used
the YAML definition of feature flag needs to use `default_enabled: [false, true]`
as the usage of the feature flag is undefined. These methods are subject to be removed as part of the discusions https://gitlab.com/gitlab-org/gitlab/-/issues/218667.
The resulting YAML should be similar to this:
```yaml
name:scoped_labels
group:group::memory
type:licensed
# The `default_enabled:` is undefined
# as `feature_available?` uses `default_enabled: true`
# as `beta_feature_available?` uses `default_enabled: false`
default_enabled:[false,true]
```
### Feature groups
### Feature groups
Feature groups must be defined statically in `lib/feature.rb` (in the
Feature groups must be defined statically in `lib/feature.rb` (in the