Add latest changes from gitlab-org/gitlab@master

.dockerignore

@@ -1,9 +1,9 @@
 # `build_from_dir` can't find Dockerfile when `.dockerignore` is "*"
 # See https://github.com/swipely/docker-api/issues/484
-# Ignore all folders except qa/, config/initializers and the root of lib/ since
+# Ignore all folders except the following files we need to build the QA image:
-# the files we need to build the QA image are in these folders.
-# Following are the files we need:
 # - ./config/initializers/0_inject_enterprise_edition_module.rb
+# - ./config/feature_flags
+# - ./ee/config/feature_flags
 # - ./ee/app/models/license.rb
 # - ./lib/gitlab_edition.rb
 # - ./lib/gitlab/utils.rb
@@ -28,7 +28,9 @@
 /docker/
 /ee/bin/
 /ee/changelogs/
-/ee/config/
+/ee/config/events/
+/ee/config/metrics/
+/ee/config/routes/
 /ee/db/
 /ee/fixtures/
 /ee/lib/

app/controllers/projects/merge_requests_controller.rb

@@ -87,6 +87,7 @@ class Projects::MergeRequestsController < Projects::MergeRequests::ApplicationCo
     :rebase,
     :discussions,
     :pipelines,
+    :coverage_reports,
     :test_reports,
     :codequality_mr_diff_reports,
     :codequality_reports,

app/policies/merge_request_policy.rb

@@ -14,7 +14,7 @@ class MergeRequestPolicy < IssuablePolicy
     prevent :accept_merge_request
   end
 
-  rule { can?(:update_merge_request) }.policy do
+  rule { can?(:update_merge_request) & is_project_member }.policy do
     enable :approve_merge_request
   end
 

app/views/profiles/accounts/show.html.haml

@@ -17,9 +17,9 @@
 .row.gl-mt-3.js-search-settings-section
   .col-lg-4.profile-settings-sidebar
     %h4.gl-mt-0
-      = s_('Profiles|Two-Factor Authentication')
+      = s_('Profiles|Two-factor authentication')
     %p
-      = s_("Profiles|Increase your account's security by enabling Two-Factor Authentication (2FA)")
+      = s_("Profiles|Increase your account's security by enabling two-factor authentication (2FA).")
   .col-lg-8
     %p
       #{_('Status')}: #{current_user.two_factor_enabled? ? _('Enabled') : _('Disabled')}
@@ -35,9 +35,9 @@
   .row.gl-mt-3.js-search-settings-section
     .col-lg-4.profile-settings-sidebar
       %h4.gl-mt-0
-        = s_('Profiles|Social sign-in')
+        = s_('Profiles|Service sign-in')
       %p
-        = s_('Profiles|Activate signin with one of the following services')
+        = s_('Profiles|Connect a service for sign-in.')
     .col-lg-8
       = render 'providers', providers: button_based_providers, group_saml_identities: local_assigns[:group_saml_identities]
     .col-lg-12

config/feature_flags/development/delayed_project_import_schedule_worker.yml

@@ -1,8 +0,0 @@
----
-name: delayed_project_import_schedule_worker
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87438
-rollout_issue_url: https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1681
-milestone: '15.0'
-type: development
-group: group::scalability
-default_enabled: false

doc/administration/operations/puma.md

@@ -279,6 +279,96 @@ To switch from Unicorn to Puma:
 1. Optional. For multi-node deployments, configure the load balancer to use the
    [readiness check](../load_balancer.md#readiness-check).
 
+## Troubleshooting Puma
+
+### 502 Gateway Timeout after Puma spins at 100% CPU
+
+This error occurs when the Web server times out (default: 60 s) after not
+hearing back from the Puma worker. If the CPU spins to 100% while this is in
+progress, there may be something taking longer than it should.
+
+To fix this issue, we first need to figure out what is happening. The
+following tips are only recommended if you do not mind users being affected by
+downtime. Otherwise, skip to the next section.
+
+1. Load the problematic URL
+1. Run `sudo gdb -p <PID>` to attach to the Puma process.
+1. In the GDB window, type:
+
+   ```plaintext
+   call (void) rb_backtrace()
+   ```
+
+1. This forces the process to generate a Ruby backtrace. Check
+   `/var/log/gitlab/puma/puma_stderr.log` for the backtrace. For example, you may see:
+
+   ```plaintext
+   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `block in start'
+   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `loop'
+   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:36:in `block (2 levels) in start'
+   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:44:in `sample'
+   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:68:in `sample_objects'
+   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:68:in `each_with_object'
+   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:68:in `each'
+   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:69:in `block in sample_objects'
+   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:69:in `name'
+   ```
+
+1. To see the current threads, run:
+
+   ```plaintext
+   thread apply all bt
+   ```
+
+1. Once you're done debugging with `gdb`, be sure to detach from the process and exit:
+
+   ```plaintext
+   detach
+   exit
+   ```
+
+GDB reports an error if the Puma process terminates before you can run these commands. 
+To buy more time, you can always raise the
+Puma worker timeout. For omnibus users, you can edit `/etc/gitlab/gitlab.rb` and
+increase it from 60 seconds to 600:
+
+```ruby
+gitlab_rails['env'] = {
+        'GITLAB_RAILS_RACK_TIMEOUT' => 600
+}
+```
+
+For source installations, set the environment variable.
+Refer to [Puma Worker timeout](../operations/puma.md#change-the-worker-timeout).
+
+[Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
+
+#### Troubleshooting without affecting other users
+
+The previous section attached to a running Puma process, which may have
+undesirable effects on users trying to access GitLab during this time. If you
+are concerned about affecting others during a production system, you can run a
+separate Rails process to debug the issue:
+
+1. Log in to your GitLab account.
+1. Copy the URL that is causing problems (for example, `https://gitlab.com/ABC`).
+1. Create a Personal Access Token for your user (User Settings -> Access Tokens).
+1. Bring up the [GitLab Rails console.](../operations/rails_console.md#starting-a-rails-console-session)
+1. At the Rails console, run:
+
+   ```ruby
+   app.get '<URL FROM STEP 2>/?private_token=<TOKEN FROM STEP 3>'
+   ```
+
+   For example:
+
+   ```ruby
+   app.get 'https://gitlab.com/gitlab-org/gitlab-foss/-/issues/1?private_token=123456'
+   ```
+
+1. In a new window, run `top`. It should show this Ruby process using 100% CPU. Write down the PID.
+1. Follow step 2 from the previous section on using GDB.
+
 ## Related topics
 
 - [Use a dedicated metrics server to export web metrics](../monitoring/prometheus/puma_exporter.md)

doc/administration/troubleshooting/debug.md

@@ -166,94 +166,6 @@ in Omnibus, run as root:
 Many of the tips to diagnose issues below apply to many different situations. We use one
 concrete example to illustrate what you can do to learn what is going wrong.
 
-### 502 Gateway Timeout after Unicorn spins at 100% CPU
-
-This error occurs when the Web server times out (default: 60 s) after not
-hearing back from the Unicorn worker. If the CPU spins to 100% while this in
-progress, there may be something taking longer than it should.
-
-To fix this issue, we first need to figure out what is happening. The
-following tips are only recommended if you do not mind users being affected by
-downtime. Otherwise skip to the next section.
-
-1. Load the problematic URL
-1. Run `sudo gdb -p <PID>` to attach to the Puma process.
-1. In the GDB window, type:
-
-   ```plaintext
-   call (void) rb_backtrace()
-   ```
-
-1. This forces the process to generate a Ruby backtrace. Check
-   `/var/log/gitlab/puma/puma_stderr.log` for the backtrace. For example, you may see:
-
-   ```plaintext
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `block in start'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `loop'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:36:in `block (2 levels) in start'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:44:in `sample'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:68:in `sample_objects'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:68:in `each_with_object'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:68:in `each'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:69:in `block in sample_objects'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:69:in `name'
-   ```
-
-1. To see the current threads, run:
-
-   ```plaintext
-   thread apply all bt
-   ```
-
-1. Once you're done debugging with `gdb`, be sure to detach from the process and exit:
-
-   ```plaintext
-   detach
-   exit
-   ```
-
-If the Puma process terminates before you are able to run these
-commands, GDB reports an error. To buy more time, you can always raise the
-Puma worker timeout. For omnibus users, you can edit `/etc/gitlab/gitlab.rb` and
-increase it from 60 seconds to 600:
-
-```ruby
-gitlab_rails['env'] = {
-        'GITLAB_RAILS_RACK_TIMEOUT' => 600
-}
-```
-
-For source installations, set the environment variable.
-Refer to [Puma Worker timeout](../operations/puma.md#change-the-worker-timeout).
-
-[Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
-
-#### Troubleshooting without affecting other users
-
-The previous section attached to a running Unicorn process, and this may have
-undesirable effects for users trying to access GitLab during this time. If you
-are concerned about affecting others during a production system, you can run a
-separate Rails process to debug the issue:
-
-1. Log in to your GitLab account.
-1. Copy the URL that is causing problems (for example, `https://gitlab.com/ABC`).
-1. Create a Personal Access Token for your user (User Settings -> Access Tokens).
-1. Bring up the [GitLab Rails console.](../operations/rails_console.md#starting-a-rails-console-session)
-1. At the Rails console, run:
-
-   ```ruby
-   app.get '<URL FROM STEP 2>/?private_token=<TOKEN FROM STEP 3>'
-   ```
-
-   For example:
-
-   ```ruby
-   app.get 'https://gitlab.com/gitlab-org/gitlab-foss/-/issues/1?private_token=123456'
-   ```
-
-1. In a new window, run `top`. It should show this Ruby process using 100% CPU. Write down the PID.
-1. Follow step 2 from the previous section on using GDB.
-
 ### GitLab: API is not accessible
 
 This often occurs when GitLab Shell attempts to request authorization via the

doc/api/graphql/reference/index.md

@@ -5481,7 +5481,8 @@ Input type: `VulnerabilityFindingDismissInput`
 | <a id="mutationvulnerabilityfindingdismissclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
 | <a id="mutationvulnerabilityfindingdismisscomment"></a>`comment` | [`String`](#string) | Comment why finding should be dismissed. |
 | <a id="mutationvulnerabilityfindingdismissdismissalreason"></a>`dismissalReason` | [`VulnerabilityDismissalReason`](#vulnerabilitydismissalreason) | Reason why finding should be dismissed. |
-| <a id="mutationvulnerabilityfindingdismissid"></a>`id` | [`VulnerabilitiesFindingID!`](#vulnerabilitiesfindingid) | ID of the finding to be dismissed. |
+| <a id="mutationvulnerabilityfindingdismissid"></a>`id` **{warning-solid}** | [`VulnerabilitiesFindingID`](#vulnerabilitiesfindingid) | **Deprecated:** Use `uuid`. Deprecated in 15.2. |
+| <a id="mutationvulnerabilityfindingdismissuuid"></a>`uuid` | [`String`](#string) | UUID of the finding to be dismissed. |
 
 #### Fields
 

doc/ci/runners/saas/macos_saas_runner.md

@@ -18,6 +18,8 @@ CI/CD minutes used on GitLab SaaS macOS runners are included in your CI/CD minut
 
 Refer to the CI/CD minutes [cost factor](../../../ci/pipelines/cicd_minutes.md#cost-factor) for the cost factor applied to the GitLab SaaS macOS runners.
 
+Jobs handled by macOS shared runners on GitLab.com **time out after 2 hours**, regardless of the timeout configured in a project.
+
 ## Access request process
 
 While in limited availability, to run CI jobs on the macOS runners, GitLab SaaS customer namespaces must be explicitly added to the macOS `allow-list`. Customers who participated in the beta have already been added.

doc/integration/github.md

@@ -218,4 +218,4 @@ To fix this issue, you must activate GitHub sign-in in GitLab:
 1. On the top bar, in the top right corner, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Account**.
-1. In the **Social sign-in** section, select **Connect to GitHub**.
+1. In the **Service sign-in** section, select **Connect to GitHub**.

doc/integration/kerberos.md

@@ -125,8 +125,8 @@ If you're not an administrator:
 1. In the top-right corner, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Account**.
-1. In the **Social sign-in** section, select **Connect Kerberos SPNEGO**.
+1. In the **Service sign-in** section, select **Connect Kerberos SPNEGO**.
-   If you don't see a **Social sign-in** Kerberos option, follow the
+   If you don't see a **Service sign-in** Kerberos option, follow the
    requirements in [Enable single sign-on](#enable-single-sign-on).
 
 In either case, you should now be able to sign in to your GitLab account

doc/user/group/saml_sso/index.md

@@ -398,9 +398,7 @@ For example, to unlink the `MyOrg` account:
 1. On the top bar, in the top right corner, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Account**.
-1. In the **Social sign-in** section, select **Disconnect** next to the connected account.
+1. In the **Service sign-in** section, select **Disconnect** next to the connected account.
-
-![Unlink Group SAML](img/unlink_group_saml.png)
 
 ## Group Sync
 

doc/user/project/import/bitbucket.md

@@ -58,7 +58,7 @@ For user contributions to be mapped, each user must complete the following befor
    If they don't match, modify the public name in the Atlassian account settings to match the
    username in the Bitbucket account settings.
 
-1. Connect your Bitbucket account in [GitLab profile social sign-in](https://gitlab.com/-/profile/account).
+1. Connect your Bitbucket account in [GitLab profile service sign-in](https://gitlab.com/-/profile/account).
 
 1. [Set your public email](../../profile/index.md#set-your-public-email).
 
@@ -97,7 +97,7 @@ If you've accidentally started the import process with the wrong account, follow
 the username in the Bitbucket account settings must match the public name in the Atlassian account
 settings. If these names match but user mapping still fails, the user may have modified their
 Bitbucket username after connecting their Bitbucket account in the
-[GitLab profile social sign-in](https://gitlab.com/-/profile/account).
+[GitLab profile service sign-in](https://gitlab.com/-/profile/account).
 
 To fix this, the user must verify that their Bitbucket external UID in the GitLab database matches their
 current Bitbucket public name, and reconnect if there's a mismatch:
@@ -106,7 +106,7 @@ current Bitbucket public name, and reconnect if there's a mismatch:
 
 1. In the API's response, the `identities` attribute contains the Bitbucket account that exists in
    the GitLab database. If the `extern_uid` doesn't match the current Bitbucket public name, the
-   user should reconnect their Bitbucket account in the [GitLab profile social sign-in](https://gitlab.com/-/profile/account).
+   user should reconnect their Bitbucket account in the [GitLab profile service sign-in](https://gitlab.com/-/profile/account).
 
 1. Following reconnection, the user should use the API again to verify that their `extern_uid` in
    the GitLab database now matches their current Bitbucket public name.

locale/gitlab.pot

@@ -29456,9 +29456,6 @@ msgstr ""
 msgid "Profiles|Account scheduled for removal."
 msgstr ""
 
-msgid "Profiles|Activate signin with one of the following services"
-msgstr ""
-
 msgid "Profiles|Active"
 msgstr ""
 
@@ -29513,6 +29510,9 @@ msgstr ""
 msgid "Profiles|Connect %{provider}"
 msgstr ""
 
+msgid "Profiles|Connect a service for sign-in."
+msgstr ""
+
 msgid "Profiles|Connected Accounts"
 msgstr ""
 
@@ -29591,7 +29591,7 @@ msgstr ""
 msgid "Profiles|Incoming email token was successfully reset"
 msgstr ""
 
-msgid "Profiles|Increase your account's security by enabling Two-Factor Authentication (2FA)"
+msgid "Profiles|Increase your account's security by enabling two-factor authentication (2FA)."
 msgstr ""
 
 msgid "Profiles|Invalid password"
@@ -29678,15 +29678,15 @@ msgstr ""
 msgid "Profiles|Select a service to sign in with."
 msgstr ""
 
+msgid "Profiles|Service sign-in"
+msgstr ""
+
 msgid "Profiles|Set new profile picture"
 msgstr ""
 
 msgid "Profiles|Set your local time zone."
 msgstr ""
 
-msgid "Profiles|Social sign-in"
-msgstr ""
-
 msgid "Profiles|Some options are unavailable for LDAP accounts"
 msgstr ""
 
@@ -29720,7 +29720,7 @@ msgstr ""
 msgid "Profiles|Title"
 msgstr ""
 
-msgid "Profiles|Two-Factor Authentication"
+msgid "Profiles|Two-factor authentication"
 msgstr ""
 
 msgid "Profiles|Type your %{confirmationValue} to confirm:"

qa/Dockerfile

@@ -40,8 +40,9 @@ COPY ./config/initializers/0_inject_enterprise_edition_module.rb /home/gitlab/co
 # Copy VERSION to ensure the COPY succeeds to copy at least one file since ee/app/models/license.rb isn't present in FOSS
 # The [b] part makes ./ee/app/models/license.r[b] a pattern that is allowed to return no files (which is the case in FOSS)
 COPY VERSION ./ee/app/models/license.r[b] /home/gitlab/ee/app/models/
-COPY ./config/bundler_setup.rb /home/gitlab/config/
+COPY VERSION ./ee/config/feature_flag[s] /home/gitlab/ee/config/feature_flags/
 COPY ./config/feature_flags /home/gitlab/config/feature_flags
+COPY ./config/bundler_setup.rb /home/gitlab/config/
 COPY ./lib/gitlab_edition.rb /home/gitlab/lib/
 COPY ./lib/gitlab/utils.rb /home/gitlab/lib/gitlab/
 COPY ./INSTALLATION_TYPE ./VERSION /home/gitlab/

spec/features/invites_spec.rb

@@ -72,7 +72,7 @@ RSpec.describe 'Group or Project invitations', :aggregate_failures do
         end
       end
 
-      context 'when invite is sent before account is created - ldap or social sign in for manual acceptance edge case' do
+      context 'when invite is sent before account is created - ldap or service sign in for manual acceptance edge case' do
         let(:user) { create(:user, email: 'user@example.com') }
 
         context 'when invite clicked and not signed in' do

spec/features/profiles/account_spec.rb

@@ -9,7 +9,7 @@ RSpec.describe 'Profile > Account', :js do
     sign_in(user)
   end
 
-  describe 'Social sign-in' do
+  describe 'Service sign-in' do
     context 'when an identity does not exist' do
       before do
         allow(Devise).to receive_messages(omniauth_configs: { google_oauth2: {} })

spec/policies/merge_request_policy_spec.rb

@@ -51,7 +51,8 @@ RSpec.describe MergeRequestPolicy do
   end
 
   context 'when merge request is public' do
-    let(:merge_request) { create(:merge_request, source_project: project, target_project: project, author: author) }
+    let(:merge_request) { create(:merge_request, source_project: project, target_project: project, author: user) }
+    let(:user) { author }
 
     context 'and user is anonymous' do
       subject { permissions(nil, merge_request) }
@@ -61,19 +62,62 @@ RSpec.describe MergeRequestPolicy do
       end
     end
 
-    describe 'the author, who became a guest' do
+    context 'and user is author' do
-      subject { permissions(author, merge_request) }
+      subject { permissions(user, merge_request) }
 
-      it do
+      context 'and the user is a guest' do
-        is_expected.to be_allowed(:update_merge_request)
+        let(:user) { guest }
+
+        it do
+          is_expected.to be_allowed(:update_merge_request)
+        end
+
+        it do
+          is_expected.to be_allowed(:reopen_merge_request)
+        end
+
+        it do
+          is_expected.to be_allowed(:approve_merge_request)
+        end
       end
 
-      it do
+      context 'and the user is a group member' do
-        is_expected.to be_allowed(:reopen_merge_request)
+        let(:project) { create(:project, :public, group: group) }
+        let(:group) { create(:group) }
+        let(:user) { non_team_member }
+
+        before do
+          group.add_guest(non_team_member)
+        end
+
+        it do
+          is_expected.to be_allowed(:approve_merge_request)
+        end
       end
 
-      it do
+      context 'and the user is a member of a shared group' do
-        is_expected.to be_allowed(:approve_merge_request)
+        let(:user) { non_team_member }
+
+        before do
+          group = create(:group)
+          project.project_group_links.create!(
+            group: group,
+            group_access: Gitlab::Access::DEVELOPER)
+
+          group.add_guest(non_team_member)
+        end
+
+        it do
+          is_expected.to be_allowed(:approve_merge_request)
+        end
+      end
+
+      context 'and the user is not a project member' do
+        let(:user) { non_team_member }
+
+        it do
+          is_expected.not_to be_allowed(:approve_merge_request)
+        end
       end
     end
   end