Automatic merge of gitlab-org/gitlab master

changelogs/unreleased/change-clusters-helm-major-version-default-to-3.yml

+---
+title: Change clusters.helm_major_version default to 3
+merge_request: 50399
+author:
+type: changed

db/migrate/20201221213415_change_clusters_helm_major_version_default_to_3.rb

+# frozen_string_literal: true
+
+class ChangeClustersHelmMajorVersionDefaultTo3 < ActiveRecord::Migration[6.0]
+  DOWNTIME = false
+
+  def change
+    change_column_default(:clusters, :helm_major_version, from: 2, to: 3)
+  end
+end

db/schema_migrations/20201221213415

+8c123da6a380524c7269ffc67ea0e533a415d3c6eddf96cee4025ea152fc7582
\ No newline at end of file

db/structure.sql

@@ -11128,7 +11128,7 @@ CREATE TABLE clusters (
     management_project_id integer,
     cleanup_status smallint DEFAULT 1 NOT NULL,
     cleanup_status_reason text,
-    helm_major_version integer DEFAULT 2 NOT NULL
+    helm_major_version integer DEFAULT 3 NOT NULL
 );
 
 CREATE TABLE clusters_applications_cert_managers (

doc/subscriptions/self_managed/index.md

@@ -59,7 +59,7 @@ GitLab has several features which can help you manage the number of users:
 - Enable the [**Require administrator approval for new sign ups**](../../user/admin_area/settings/sign_up_restrictions.md#require-administrator-approval-for-new-sign-ups)
   option.
 - Enable the [User cap](../../user/admin_area/settings/sign_up_restrictions.md#user-cap)
-  option. **Available in GitLab 13.6 and later**.
+  option. **Available in GitLab 13.7 and later**.
 - [Disable new sign-ups](../../user/admin_area/settings/sign_up_restrictions.md), and instead manage new
   users manually.
 - View a breakdown of users by role in the [Users statistics](../../user/admin_area/index.md#users-statistics) page.

doc/user/admin_area/settings/sign_up_restrictions.md

@@ -37,6 +37,9 @@ To require administrator approval for new sign ups:
 1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**.
 1. Select the **Require admin approval for new sign-ups** checkbox, then select **Save changes**.
 
+In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/273258), if an administrator disables this setting, the users in pending approval state are
+automatically approved in a background job.
+
 ## Require email confirmation
 
 You can send confirmation emails during sign up and require that users confirm
@@ -47,20 +50,39 @@ To enforce confirmation of the email address used for new sign ups:
 1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**.
 1. Select the **Enable email restrictions for sign ups** checkbox, then select **Save changes**.
 
-In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/273258), if an administrator disables this setting, the users in pending approval state are
-automatically approved in a background job.
-
 ## User cap **(CORE ONLY)**
 
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4315) in GitLab 13.6.
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4315) in GitLab 13.7.
+> - It's [deployed behind a feature flag](../../feature_flags.md), enabled by default.
+> - It's recommended for production use.
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-user-cap). **(CORE ONLY)**
 
 When the number of billable users reaches the user cap, any user who is added or requests access must be
 [approved](../approving_users.md#approving-a-user) by an administrator before they can start using
 their account.
 
-If an administrator increases or removes the user cap, the users in pending approval state will be
+If an administrator increases or removes the user cap, the users in pending approval state are
 automatically approved in a background job.
 
+### Enable or disable User cap **(CORE ONLY)**
+
+User cap is under development but ready for production use.
+It is deployed behind a feature flag that is **enabled by default**.
+[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
+can opt to disable it.
+
+To disable it:
+
+```ruby
+Feature.disable(:admin_new_user_signups_cap)
+```
+
+To enable it:
+
+```ruby
+Feature.enable(:admin_new_user_signups_cap)
+```
+
 ## Soft email confirmation
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47003) in GitLab 12.2.

doc/user/packages/container_registry/index.md

@@ -666,6 +666,23 @@ For example, you may have two individual images, one for `amd64` and another for
 
 As a workaround, you should include the architecture in the tag name of individual images. For example, use `mygroup/myapp:1.0.0-amd64` instead of using sub repositories, like `mygroup/myapp/amd64:1.0.0`. You can then tag the manifest list with `mygroup/myapp:1.0.0`.
 
+### The cleanup policy doesn't delete any tags
+
+In GitLab 13.6 and earlier, when you run the cleanup policy,
+you may expect it to delete tags and it does not.
+
+This issue occurs when the cleanup policy was saved without
+editing the value in the **Remove tags matching** field.
+
+This field had a grayed out `.*` value as a placeholder.
+Unless `.*` (or other regex pattern) was entered explicitly into the
+field, a `nil` value was submitted. This value prevents the
+saved cleanup policy from matching any tags.
+
+As a workaround, edit the cleanup policy. In the **Remove tags matching**
+field, enter `.*` and save. This value indicates that all tags should
+be removed.
+
 ### Troubleshoot as a GitLab server admin
 
 Troubleshooting the GitLab Container Registry, most of the times, requires

ee/config/feature_flags/experiment/show_trial_status_in_sidebar_experiment_percentage.yml

----
-name: show_trial_status_in_sidebar_experiment_percentage
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50090
-rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/281019
-milestone: '13.8'
-type: experiment
-group: group::conversion
-default_enabled: false

ee/spec/helpers/projects_helper_spec.rb

@@ -102,7 +102,7 @@ RSpec.describe ProjectsHelper do
       allow(helper).to receive(:current_user).and_return(user)
     end
 
-    it do
+    specify do
       expect(helper.group_project_templates_count(parent_group.id)).to eq 1
     end
 
@@ -111,7 +111,7 @@ RSpec.describe ProjectsHelper do
         template_project.update!(marked_for_deletion_at: Date.current)
       end
 
-      it do
+      specify do
         expect(helper.group_project_templates_count(parent_group.id)).to eq 0
       end
     end
@@ -449,7 +449,7 @@ RSpec.describe ProjectsHelper do
     context 'when project has delayed deletion enabled' do
       let(:enabled) { true }
 
-      it do
+      specify do
         deletion_date = helper.permanent_deletion_date(Time.now.utc)
 
         expect(subject).to eq "Deleting a project places it into a read-only state until #{deletion_date}, at which point the project will be permanently deleted. Are you ABSOLUTELY sure?"
@@ -459,7 +459,7 @@ RSpec.describe ProjectsHelper do
     context 'when project has delayed deletion disabled' do
       let(:enabled) { false }
 
-      it do
+      specify do
         expect(subject).to eq "You are going to delete #{project.full_name}. Deleted projects CANNOT be restored! Are you ABSOLUTELY sure?"
       end
     end