Enable variable_inside_variable by default

app/presenters/ci/build_runner_presenter.rb

@@ -33,7 +33,7 @@ module Ci
     end
 
     def runner_variables
-      if Feature.enabled?(:variable_inside_variable, project)
+      if Feature.enabled?(:variable_inside_variable, project, default_enabled: :yaml)
         variables.sort_and_expand_all(project, keep_undefined: true).to_runner_variables
       else
         variables.to_runner_variables

config/feature_flags/development/variable_inside_variable.yml

@@ -5,4 +5,4 @@ rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/297382
 milestone: '13.11'
 type: development
 group: group::runner
-default_enabled: false
+default_enabled: true

doc/ci/variables/where_variables_can_be_used.md

@@ -63,11 +63,12 @@ because the expansion is done in GitLab before any runner gets the job.
 
 #### Nested variable expansion
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48627) in GitLab 13.10.
-> - It's [deployed behind a feature flag](../../user/feature_flags.md), disabled by default.
-> - It can be enabled or disabled for a single project.
-> - It's disabled on GitLab.com.
-> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enabling-the-nested-variable-expansion-feature). **(FREE SELF)**
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48627) in GitLab 13.10. [Deployed behind the `variable_inside_variable` feature flag](../../user/feature_flags.md), disabled by default.
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/297382) in GitLab 14.3.
+> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/297382) in GitLab 14.3.
+
+FLAG:
+On self-managed GitLab, by default this feature is available. To hide the feature per project or for your entire instance, ask an administrator to [disable the `variable_inside_variable` flag](../../administration/feature_flags.md).
 
 GitLab expands job variable values recursively before sending them to the runner. For example:
 
@@ -86,29 +87,6 @@ References to unavailable variables are left intact. In this case, the runner
 [attempts to expand the variable value](#gitlab-runner-internal-variable-expansion-mechanism) at runtime.
 For example, a variable like `CI_BUILDS_DIR` is known by the runner only at runtime.
 
-##### Enabling the nested variable expansion feature **(FREE SELF)**
-
-This feature comes with the `:variable_inside_variable` feature flag disabled by default.
-
-To enable this feature, ask a GitLab administrator with [Rails console access](../../administration/feature_flags.md#how-to-enable-and-disable-features-behind-flags) to run the
-following command:
-
-```ruby
-# For the instance
-Feature.enable(:variable_inside_variable)
-# For a single project
-Feature.enable(:variable_inside_variable, Project.find(<project id>))
-```
-
-To disable it:
-
-```ruby
-# For the instance
-Feature.disable(:variable_inside_variable)
-# For a single project
-Feature.disable(:variable_inside_variable, Project.find(<project id>))
-```
-
 ### GitLab Runner internal variable expansion mechanism
 
 - Supported: project/group variables, `.gitlab-ci.yml` variables, `config.toml` variables, and

lib/gitlab/ci/variables/collection.rb

@@ -90,7 +90,7 @@ module Gitlab
         end
 
         def sort_and_expand_all(project, keep_undefined: false)
-          return self if Feature.disabled?(:variable_inside_variable, project)
+          return self if Feature.disabled?(:variable_inside_variable, project, default_enabled: :yaml)
 
           sorted = Sort.new(self)
           return self.class.new(self, sorted.errors) unless sorted.valid?