Add latest changes from gitlab-org/gitlab@master

app/assets/javascripts/environments/mixins/environments_mixin.js

@@ -145,7 +145,7 @@ export default {
 
     deleteEnvironment(environment) {
       const endpoint = environment.delete_path;
-      const mountedToShow = environment.mounted_to_show;
+      const { onSingleEnvironmentPage } = environment;
       const errorMessage = s__(
         'Environments|An error occurred while deleting the environment. Check if the environment stopped; if not, stop it and try again.',
       );
@@ -153,7 +153,7 @@ export default {
       this.service
         .deleteAction(endpoint)
         .then(() => {
-          if (!mountedToShow) {
+          if (!onSingleEnvironmentPage) {
             // Reload as a first solution to bust the ETag cache
             window.location.reload();
             return;

app/assets/javascripts/environments/mount_show.js

@@ -15,7 +15,7 @@ export default () => {
     data() {
       const environment = JSON.parse(JSON.stringify(container.dataset));
       environment.delete_path = environment.deletePath;
-      environment.mounted_to_show = true;
+      environment.onSingleEnvironmentPage = true;
 
       return {
         environment,

changelogs/unreleased/224447-add-default_branch_name-to-applicationsettings-model.yml

+---
+title: Add default_branch_name to application_setteings
+merge_request: 35282
+author:
+type: other

db/migrate/20200624222443_add_default_branch_name_to_application_settings.rb

+# frozen_string_literal: true
+
+class AddDefaultBranchNameToApplicationSettings < ActiveRecord::Migration[6.0]
+  DOWNTIME = false
+
+  # rubocop:disable Migration/AddLimitToTextColumns
+  # limit is added in db/migrate/20200625190458_add_limit_to_default_branch_name_to_application_settings
+  def change
+    add_column :application_settings, :default_branch_name, :text
+  end
+  # rubocop:enable Migration/AddLimitToTextColumns
+end

db/migrate/20200625190458_add_limit_to_default_branch_name_to_application_settings.rb

+# frozen_string_literal: true
+
+class AddLimitToDefaultBranchNameToApplicationSettings < ActiveRecord::Migration[6.0]
+  include Gitlab::Database::MigrationHelpers
+
+  DOWNTIME = false
+
+  disable_ddl_transaction!
+
+  def up
+    add_text_limit :application_settings, :default_branch_name, 255
+  end
+
+  def down
+    remove_text_limit :application_settings, :default_branch_name
+  end
+end

db/structure.sql

@@ -9144,6 +9144,8 @@ CREATE TABLE public.application_settings (
     enforce_pat_expiration boolean DEFAULT true NOT NULL,
     compliance_frameworks smallint[] DEFAULT '{}'::smallint[] NOT NULL,
     notify_on_unknown_sign_in boolean DEFAULT true NOT NULL,
+    default_branch_name text,
+    CONSTRAINT check_51700b31b5 CHECK ((char_length(default_branch_name) <= 255)),
     CONSTRAINT check_d03919528d CHECK ((char_length(container_registry_vendor) <= 255)),
     CONSTRAINT check_d820146492 CHECK ((char_length(spam_check_endpoint_url) <= 255)),
     CONSTRAINT check_e5aba18f02 CHECK ((char_length(container_registry_version) <= 255))
@@ -23452,7 +23454,9 @@ COPY "schema_migrations" (version) FROM STDIN;
 20200623170000
 20200623185440
 20200624075411
+20200624222443
 20200625045442
+20200625190458
 20200626130220
 \.
 

doc/user/group/saml_sso/group_managed_accounts.md

+---
+type: reference, howto
+stage: Manage
+group: Access
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# Group Managed Accounts **(PREMIUM)**
+
+CAUTION: **Warning:**
+This is a [Closed Beta](https://about.gitlab.com/handbook/product/#closed-beta) feature.
+
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/709) in GitLab 12.1.
+> - It's deployed behind a feature flag, disabled by default.
+
+When [SSO for Groups]](index.md) is being enforced, groups can enable an additional level of protection by enforcing the creation of dedicated user accounts to access the group.
+
+With group-managed accounts enabled, users are required to create a new, dedicated user linked to the group.
+The notification email address associated with the user is locked to the email address received from the configured identity provider.
+Without group-managed accounts, users can link their SAML identity with any existing user on the instance.
+
+When this option is enabled:
+
+- All users in the group will be required to log in via the SSO URL associated with the group.
+- After the group-managed account has been created, group activity will require the use of this user account.
+- Users can't share a project in the group outside the top-level group (also applies to forked projects).
+
+Upon successful authentication, GitLab prompts the user with options, based on the email address received from the configured identity provider:
+
+- To create a unique account with the newly received email address.
+- If the received email address matches one of the user's verified GitLab email addresses, the option to convert the existing account to a group-managed account. ([Introduced in GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/-/issues/13481).)
+
+Since use of the group-managed account requires the use of SSO, users of group-managed accounts will lose access to these accounts when they are no longer able to authenticate with the connected identity provider. In the case of an offboarded employee who has been removed from your identity provider:
+
+- The user will be unable to access the group (their credentials will no longer work on the identity provider when prompted to SSO).
+- Contributions in the group (e.g. issues, merge requests) will remain intact.
+
+## Assertions
+
+When using group-managed accounts, the following user details need to be passed to GitLab as SAML
+assertions to be able to create a user.
+
+| Field           | Supported keys |
+|-----------------|----------------|
+| Email (required)| `email`, `mail` |
+| Full Name       | `name` |
+| First Name      | `first_name`, `firstname`, `firstName` |
+| Last Name       | `last_name`, `lastname`, `lastName` |
+
+## Feature flag **(PREMIUM ONLY)**
+
+Currently the group-managed accounts feature is behind a feature flag: `group_managed_accounts`. The flag is disabled by default.
+To activate the feature, ask a GitLab administrator with Rails console access to run:
+
+```ruby
+Feature.enable(:group_managed_accounts)
+```
+
+## Project restrictions for Group-managed accounts
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12420) in GitLab 12.9.
+
+Projects within groups with enabled group-managed accounts are not to be shared with:
+
+- Groups outside of the parent group.
+- Members who are not users managed by this group.
+
+This restriction also applies to projects forked from or to those groups.
+
+## Outer forks restriction for Group-managed accounts
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34648) in GitLab 12.9.
+
+Groups with group-managed accounts can disallow forking of projects to destinations outside the group.
+To do so, enable the "Prohibit outer forks" option in **Settings > SAML SSO**.
+When enabled, projects within the group can only be forked to other destinations within the group (including its subgroups).
+
+## Credentials inventory for Group-managed accounts **(ULTIMATE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/38133) in GitLab 12.8.
+
+Owners who manage user accounts in a group can view the following details of personal access tokens and SSH keys:
+
+- Owners
+- Scopes
+- Usage patterns
+
+To access the Credentials inventory of a group, navigate to **{shield}** **Security & Compliance > Credentials** in your group's sidebar.
+
+This feature is similar to the [Credentials inventory for self-managed instances](../../admin_area/credentials_inventory.md).
+
+## Limiting lifetime of personal access tokens of users in Group-managed accounts **(ULTIMATE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/118893) in GitLab 12.10.
+
+Users in a group managed account can optionally specify an expiration date for
+[personal access tokens](../../profile/personal_access_tokens.md).
+This expiration date is not a requirement, and can be set to any arbitrary date.
+
+Since personal access tokens are the only token needed for programmatic access to GitLab, organizations with security requirements may want to enforce more protection to require regular rotation of these tokens.
+
+### Setting a limit
+
+Only a GitLab administrator or an owner of a Group-managed account can set a limit. Leaving it empty means that the [instance level restrictions](../../admin_area/settings/account_and_limit_settings.md#limiting-lifetime-of-personal-access-tokens-ultimate-only) on the lifetime of personal access tokens will apply.
+
+To set a limit on how long personal access tokens are valid for users in a group managed account:
+
+1. Navigate to the **{settings}** **Settings > General** page in your group's sidebar.
+1. Expand the **Permissions, LFS, 2FA** section.
+1. Fill in the **Maximum allowable lifetime for personal access tokens (days)** field.
+1. Click **Save changes**.
+
+Once a lifetime for personal access tokens is set, GitLab will:
+
+- Apply the lifetime for new personal access tokens, and require users managed by the group to set an expiration date that is no later than the allowed lifetime.
+- After three hours, revoke old tokens with no expiration date or with a lifetime longer than the allowed lifetime. Three hours is given to allow administrators/group owner to change the allowed lifetime, or remove it, before revocation takes place.

doc/user/group/saml_sso/scim_setup.md

@@ -175,7 +175,7 @@ For role information, please see the [Group SAML page](index.md#user-access-and-
 To rescind access to the group, we recommend removing the user from the identity
 provider or users list for the specific app.
 
-Upon the next sync, the user will be deprovisioned, which means that the user will be removed from the group. The user account will not be deleted unless using [group managed accounts](index.md#group-managed-accounts).
+Upon the next sync, the user will be deprovisioned, which means that the user will be removed from the group. The user account will not be deleted unless using [group managed accounts](group_managed_accounts.md).
 
 ## Troubleshooting
 

lib/gitlab/background_migration.rb

@@ -33,6 +33,7 @@ module Gitlab
 
           next unless job.queue == self.queue
           next unless migration_class == steal_class
+          next if block_given? && !(yield migration_args)
 
           begin
             perform(migration_class, migration_args) if job.delete

spec/lib/gitlab/background_migration_spec.rb

@@ -47,6 +47,25 @@ RSpec.describe Gitlab::BackgroundMigration do
 
           described_class.steal('Bar')
         end
+
+        context 'when a custom predicate is given' do
+          it 'steals jobs that match the predicate' do
+            expect(queue[0]).to receive(:delete).and_return(true)
+
+            expect(described_class).to receive(:perform)
+              .with('Foo', [10, 20])
+
+            described_class.steal('Foo') { |(arg1, arg2)| arg1 == 10 && arg2 == 20 }
+          end
+
+          it 'does not steal jobs that do not match the predicate' do
+            expect(described_class).not_to receive(:perform)
+
+            expect(queue[0]).not_to receive(:delete)
+
+            described_class.steal('Foo') { |(arg1, _)| arg1 == 5 }
+          end
+        end
       end
 
       context 'when one of the jobs raises an error' do