Add latest changes from gitlab-org/gitlab@master

.gitlab/issue_templates/UX Issue.md

@@ -0,0 +1,58 @@
+<!-- This issue template can be used as a starting point for a UX Issue. This is not a feature request, rather an issue that is being created for a product designer to solve a problem.
+
+The goal of this template is to ensure we have captured all the information available to the product designer so they can approach the problem creatively and efficiently. Please add links to SSOT if this informatin exists elsewhere. -->
+
+### Who will use this solution? 
+
+<!-- If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
+
+Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
+
+* [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager)
+* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
+* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
+* [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer)
+* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
+* [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
+* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
+* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
+* [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager)
+* [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer)
+* [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test)
+* [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops)
+* [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer)
+* [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst)
+* [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor)
+
+-->
+
+
+### What problem do they have?
+
+
+### When do they have the problem?
+
+
+### Where in the app do they have the problem and at what frequency (if known)?
+
+
+### Why will a design help them?
+
+
+### What is the JTBD and/or Tasks?
+
+
+### Is this problem supported by user research (please link relevant research issue/s)?
+
+
+### Known technical constraints
+
+
+### How does this help the business?
+
+
+
+
+
+/label ~"group::" ~"section::"  ~"Category::"  ~UX 
+

GITALY_SERVER_VERSION

@@ -1 +1 @@
-37118baf7b10c95f533230797d849d2251805236
+b6dda5d1f7a7e05c34ed0f72f161a46aee536d75

doc/ci/environments/index.md

@@ -447,6 +447,63 @@ try to check out the code after the branch is deleted.
 
 Read more in the [`.gitlab-ci.yml` reference](../yaml/index.md#environmenton_stop).
 
+#### Stop an environment when another job is finished
+
+You can set an environment to stop when another job is finished.
+
+In your `.gitlab-ci.yml` file, specify in the [`on_stop:`](../yaml/index.md#environmenton_stop)
+keyword the name of the job that stops the environment.
+
+The following example shows a `review_app` job that calls a `stop_review_app` job after the first
+job is finished. The `stop_review_app` is triggered based on what is defined under `when`. In this
+case, it is set to `manual`, so it needs a
+[manual action](../jobs/job_control.md#create-a-job-that-must-be-run-manually)
+from the GitLab UI to run.
+
+Both jobs must have the same rules or only/except configuration.
+In this example, if the configuration is not identical:
+
+- The `stop_review_app` job might not be included in all pipelines that include the `review_app` job.
+- It is not possible to trigger the `action: stop` to stop the environment automatically.
+
+Also in the example, `GIT_STRATEGY` is set to `none`. If the
+`stop_review_app` job is [automatically triggered](../environments/index.md#stop-an-environment),
+the runner won't try to check out the code after the branch is deleted.
+
+The example also overwrites global variables. If your `stop` `environment` job depends
+on global variables, use [anchor variables](../yaml/yaml_optimization.md#yaml-anchors-for-variables) when you set the `GIT_STRATEGY`
+to change the job without overriding the global variables.
+
+The `stop_review_app` job **must** have the following keywords defined:
+
+- `when`, defined at either:
+  - [The job level](../yaml/index.md#when).
+  - [In a rules clause](../yaml/index.md#rules). If you use `rules:` and `when: manual`, you should
+    also set [`allow_failure: true`](../yaml/index.md#allow_failure) so the pipeline can complete
+    even if the job doesn't run.
+- `environment:name`
+- `environment:action`
+
+```yaml
+review_app:
+  stage: deploy
+  script: make deploy-app
+  environment:
+    name: review/$CI_COMMIT_REF_SLUG
+    url: https://$CI_ENVIRONMENT_SLUG.example.com
+    on_stop: stop_review_app
+
+stop_review_app:
+  stage: deploy
+  variables:
+    GIT_STRATEGY: none
+  script: make delete-app
+  when: manual
+  environment:
+    name: review/$CI_COMMIT_REF_SLUG
+    action: stop
+```
+
 #### Stop an environment after a certain time period
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/20956) in GitLab 12.8.

doc/development/work_items_widgets.md

@@ -0,0 +1,114 @@
+---
+stage: Plan
+group: Project Management
+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/#assignments
+---
+# Work items widgets
+
+## Frontend architecture
+
+Widgets for work items are heavily inspired by [Frontend widgets](fe_guide/widgets.md).
+You can expect some differences, because work items are architecturally different from issuables.
+
+GraphQL (Vue Apollo) constitutes the core of work items widgets' stack.
+
+### Retrieve widget information for work items
+
+To display a work item page, the frontend must know which widgets are available
+on the work item it is attempting to display. To do so, it needs to fetch the
+list of widgets, using a query like this:
+
+```plaintext
+query WorkItem($workItemId: ID!) {
+  workItem(workItemId: $id) @client {
+    id
+    type
+    widgets {
+      nodes {
+        type
+      }
+    }
+  }
+}
+```
+
+### GraphQL queries and mutations
+
+GraphQL queries and mutations are work item agnostic. Work item queries and mutations
+should happen at the widget level, so widgets are standalone reusable components.
+The work item query and mutation should support any work item type and be dynamic.
+They should allow you to query and mutate any work item attribute by specifying a widget identifier.
+
+In this query example, the description widget uses the query and mutation to
+display and update the description of any work item:
+
+```plaintext
+query {
+  workItem(input: {
+    workItemId: "gid://gitlab/AnyWorkItem/2207",
+    widgetIdentifier: "description",
+  }) {
+    id
+    type
+    widgets {
+      nodes {
+        ... on DescriptionWidget {
+          contentText
+        }
+      }
+    }
+  }
+}
+
+```
+
+Mutation example:
+
+```plaintext
+mutation {
+  updateWorkItem(input: {
+    workItemId: "gid://gitlab/AnyWorkItem/2207",
+    widgetIdentifier: "description",
+    value: "the updated description"
+  }) {
+    workItem {
+      id
+      description
+    }
+  }
+}
+
+```
+
+### Widget's responsibility and structure
+
+A widget is responsible for displaying and updating a single attribute, such as
+title, description, or labels. Widgets must support any type of work item.
+To maximize component reusability, widgets should be field wrappers owning the
+work item query and mutation of the attribute it's responsible for.
+
+A field component is a generic and simple component. It has no knowledge of the
+attribute or work item details, such as input field, date selector, or dropdown.
+
+Widgets must be configurable to support various use cases, depending on work items.
+When building widgets, use slots to provide extra context while minimizing
+the use of props and injected attributes.
+
+### Examples
+
+We have a [dropdown field component](https://gitlab.com/gitlab-org/gitlab/-/blob/eea9ad536fa2d28ee6c09ed7d9207f803142eed7/app/assets/javascripts/vue_shared/components/dropdown/dropdown_widget/dropdown_widget.vue)
+for use as reference.
+
+Any work item widget can wrap the dropdown component. The widget has knowledge of
+the attribute it mutates, and owns the mutation for it. Multiple widgets can use
+the same field component. For example:
+
+- Title and description widgets use the input field component.
+- Start and end date use the date selector component.
+- Labels, milestones, and assignees selectors use the dropdown component.
+
+Some frontend widgets already use the dropdown component. Use them as a reference
+for work items widgets development:
+
+- `ee/app/assets/javascripts/boards/components/assignee_select.vue`
+- `ee/app/assets/javascripts/boards/components/milestone_select.vue`

doc/user/group/index.md

@@ -563,6 +563,8 @@ You should consider these security implications before configuring IP address re
   requests a new job or an update to a job's state, it is also not bound by
   the IP restrictions. But when the running CI/CD job sends Git requests from a
   restricted IP address, the IP restriction prevents code from being cloned.
+- **User dashboard activity**: Users may still see some events from the IP restricted groups and projects
+  on their dashboard. Activity may include push, merge, issue, or comment events. 
 
 To restrict group access by IP address:
 

qa/qa/page/admin/settings/component/usage_statistics.rb

@@ -0,0 +1,21 @@
+# frozen_string_literal: true
+
+module QA
+  module Page
+    module Admin
+      module Settings
+        module Component
+          class UsageStatistics < Page::Base
+            view 'app/views/admin/application_settings/_usage.html.haml' do
+              element :enable_usage_data_checkbox
+            end
+
+            def has_disabled_usage_data_checkbox?
+              has_element?(:enable_usage_data_checkbox, disabled: true)
+            end
+          end
+        end
+      end
+    end
+  end
+end

qa/qa/page/admin/settings/metrics_and_profiling.rb

@@ -9,6 +9,7 @@ module QA
 
           view 'app/views/admin/application_settings/metrics_and_profiling.html.haml' do
             element :performance_bar_settings_content
+            element :usage_statistics_settings_content
           end
 
           def expand_performance_bar(&block)
@@ -16,6 +17,12 @@ module QA
               Component::PerformanceBar.perform(&block)
             end
           end
+
+          def expand_usage_statistics(&block)
+            expand_content(:usage_statistics_settings_content) do
+              Component::UsageStatistics.perform(&block)
+            end
+          end
         end
       end
     end

qa/qa/specs/features/browser_ui/non_devops/service_ping_default_enabled_spec.rb

@@ -0,0 +1,22 @@
+# frozen_string_literal: true
+
+module QA
+  RSpec.describe 'Service ping default enabled' do
+    context 'When using default enabled from gitlab.yml config', :requires_admin do
+      before do
+        Flow::Login.sign_in_as_admin
+
+        Page::Main::Menu.perform(&:go_to_admin_area)
+        Page::Admin::Menu.perform(&:go_to_metrics_and_profiling_settings)
+      end
+
+      it 'has service ping toggle enabled' do
+        Page::Admin::Settings::MetricsAndProfiling.perform do |setting|
+          setting.expand_usage_statistics do |page|
+            expect(page).not_to have_disabled_usage_data_checkbox
+          end
+        end
+      end
+    end
+  end
+end