Merge branch '255603-add-http-multiple-mvc-4' into 'master'

Edit new alert HTTP endpoint

See merge request gitlab-org/gitlab!46697

app/assets/javascripts/design_management/components/upload/button.vue

 <script>
-import { GlButton, GlLoadingIcon, GlTooltipDirective } from '@gitlab/ui';
+import { GlButton, GlTooltipDirective } from '@gitlab/ui';
 import { VALID_DESIGN_FILE_MIMETYPE } from '../../constants';
 
 export default {
   components: {
     GlButton,
-    GlLoadingIcon,
   },
   directives: {
     GlTooltip: GlTooltipDirective,
@@ -38,12 +37,12 @@ export default {
         )
       "
       :disabled="isSaving"
+      :loading="isSaving"
       variant="default"
       size="small"
       @click="openFileUpload"
     >
       {{ s__('DesignManagement|Upload designs') }}
-      <gl-loading-icon v-if="isSaving" inline class="ml-1" />
     </gl-button>
 
     <input

app/models/project.rb

@@ -1823,6 +1823,10 @@ class Project < ApplicationRecord
     ensure_pages_metadatum.update!(deployed: false, artifacts_archive: nil, pages_deployment: nil)
   end
 
+  def update_pages_deployment!(deployment)
+    ensure_pages_metadatum.update!(pages_deployment: deployment)
+  end
+
   def write_repository_config(gl_full_path: full_path)
     # We'd need to keep track of project full path otherwise directory tree
     # created with hashed storage enabled cannot be usefully imported using

app/services/projects/update_pages_service.rb

@@ -138,7 +138,7 @@ module Projects
         deployment = project.pages_deployments.create!(file: file,
                                                        file_count: entries_count,
                                                        file_sha256: sha256)
-        project.pages_metadatum.update!(pages_deployment: deployment)
+        project.update_pages_deployment!(deployment)
       end
 
       DestroyPagesDeploymentsWorker.perform_in(

changelogs/unreleased/design-upload-button-loading-prop.yml

+---
+title: Use standard loading state for Design Upload button
+merge_request: 46292
+author:
+type: changed

doc/ci/merge_request_pipelines/index.md

@@ -128,12 +128,6 @@ This helps you avoid having to add the `only:` rule to all of your jobs to make
 them always run. You can use this format to set up a Review App, helping to
 save resources.
 
-### Using SAST, DAST, and other Secure Templates with Pipelines for Merge Requests 
-
-To use [Secure templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Security)
-with pipelines for merge requests, you may need to apply a `rules: if: merge_request_event` for the
-Secure scans to run in the same pipeline as the commit.
-
 #### Excluding certain branches
 
 Pipelines for merge requests require special treatment when

doc/development/contributing/merge_request_workflow.md

@@ -138,13 +138,14 @@ Commit messages should follow the guidelines below, for reasons explained by Chr
 - The merge request should not contain more than 10 commit messages.
 - The commit subject should contain at least 3 words.
 
-CAUTION: **Caution:**
-If the guidelines are not met, the MR may not pass the
-[Danger checks](https://gitlab.com/gitlab-org/gitlab/blob/master/danger/commit_messages/Dangerfile).
-
-TIP: **Tip:**
-Consider enabling [Squash and merge](../../user/project/merge_requests/squash_and_merge.md#squash-and-merge) if your merge
-request includes "Applied suggestion to X files" commits, so that Danger can ignore those.
+**Important notes:**
+
+- If the guidelines are not met, the MR may not pass the [Danger checks](https://gitlab.com/gitlab-org/gitlab/blob/master/danger/commit_messages/Dangerfile).
+- Consider enabling [Squash and merge](../../user/project/merge_requests/squash_and_merge.md#squash-and-merge)
+  if your merge request includes "Applied suggestion to X files" commits, so that Danger can ignore those.
+- The prefixes in the form of `[prefix]` and `prefix:` are allowed (they can be all lowercase, as long
+  as the message itself is capitalized). For instance, `danger: Improve Danger behavior` and
+  `[API] Improve the labels endpoint` are valid commit messages.
 
 #### Why these standards matter
 

doc/development/testing_guide/end_to_end/rspec_metadata_tests.md

@@ -16,7 +16,7 @@ This is a partial list of the [RSpec metadata](https://relishapp.com/rspec/rspec
 | `:elasticsearch`  | The test requires an Elasticsearch service. It is used by the [instance-level scenario](https://gitlab.com/gitlab-org/gitlab-qa#definitions) [`Test::Integration::Elasticsearch`](https://gitlab.com/gitlab-org/gitlab/-/blob/72b62b51bdf513e2936301cb6c7c91ec27c35b4d/qa/qa/ee/scenario/test/integration/elasticsearch.rb) to include only tests that require Elasticsearch. |
 | `:gitaly_cluster` | The test will run against a GitLab instance where repositories are stored on redundant Gitaly nodes behind a Praefect node. All nodes are [separate containers](../../../administration/gitaly/praefect.md#requirements-for-configuring-a-gitaly-cluster). Tests that use this tag have a longer setup time since there are three additional containers that need to be started. |
 | `:jira`           | The test requires a Jira Server. [GitLab-QA](https://gitlab.com/gitlab-org/gitlab-qa) will provision the Jira Server in a Docker container when the `Test::Integration::Jira` test scenario is run.
-| `:kubernetes`     | The test includes a GitLab instance that is configured to be run behind an SSH tunnel, allowing a TLS-accessible GitLab. This test will also include provisioning of at least one Kubernetes cluster to test against. *This tag is often be paired with `:orchestrated`.* |
+| `:kubernetes`     | The test includes a GitLab instance that is configured to be run behind an SSH tunnel, allowing a TLS-accessible GitLab. This test will also include provisioning of at least one Kubernetes cluster to test against. _This tag is often be paired with `:orchestrated`._ |
 | `:only`           | The test is only to be run against specific environments or pipelines. See [Environment selection](environment_selection.md) for more information. |
 | `:orchestrated`   | The GitLab instance under test may be [configured by `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md#orchestrated-tests) to be different to the default GitLab configuration, or `gitlab-qa` may launch additional services in separate Docker containers, or both. Tests tagged with `:orchestrated` are excluded when testing environments where we can't dynamically modify GitLab's configuration (for example, Staging). |
 | `:quarantine`     | The test has been [quarantined](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#quarantining-tests), will run in a separate job that only includes quarantined tests, and is allowed to fail. The test will be skipped in its regular job so that if it fails it will not hold up the pipeline. Note that you can also [quarantine a test only when it runs against specific environment](environment_selection.md#quarantining-a-test-for-a-specific-environment). |
@@ -25,3 +25,20 @@ This is a partial list of the [RSpec metadata](https://relishapp.com/rspec/rspec
 | `:runner`         | The test depends on and will set up a GitLab Runner instance, typically to run a pipeline. |
 | `:skip_live_env`  | The test will be excluded when run against live deployed environments such as Staging, Canary, and Production. |
 | `:testcase`       | The link to the test case issue in the [Quality Testcases project](https://gitlab.com/gitlab-org/quality/testcases/). |
+| `:mattermost`     | The test requires a GitLab Mattermost service on the GitLab instance. |
+| `:ldap_no_server` | The test requires a GitLab instance to be configured to use LDAP. To be used with the `:orchestrated` tag. It does not spin up an LDAP server at orchestration time. Instead, it creates the LDAP server at runtime. |
+| `:ldap_no_tls`    | The test requires a GitLab instance to be configured to use an external LDAP server with TLS not enabled. |
+| `:ldap_tls`       | The test requires a GitLab instance to be configured to use an external LDAP server with TLS enabled. |
+| `:object_storage` | The test requires a GitLab instance to be configured to use multiple [object storage types](../../../administration/object_storage.md). Uses MinIO as the object storage server. |
+| `:smtp`           | The test requires a GitLab instance to be configured to use an SMTP server. Tests SMTP notification email delivery from GitLab by using MailHog. |
+| `:group_saml`     | The test requires a GitLab instance that has SAML SSO enabled at the group level. Interacts with an external SAML identity provider. Paired with the `:orchestrated` tag. |
+| `:instance_saml`  | The test requires a GitLab instance that has SAML SSO enabled at the instance level. Interacts with an external SAML identity provider. Paired with the `:orchestrated` tag. |
+| `:skip_signup_disabled` | The test uses UI to sign up a new user and will be skipped in any environment that does not allow new user registration via the UI. |
+| `:smoke`          | The test belongs to the test suite which verifies basic functionality of a GitLab instance.|
+| `:github`         | The test requires a GitHub personal access token. |
+| `:repository_storage` |  The test requires a GitLab instance to be configured to use multiple [repository storage paths](../../../administration/repository_storage_paths.md). Paired with the `:orchestrated` tag. |
+| `:geo`            | The test requires two GitLab Geo instances - a primary and a secondary - to be spun up. |
+| `:relative_url`   | The test requires a GitLab instance to be installed under a [relative URL](../../../install/relative_url.md). |
+| `:requires_git_protocol_v2`   | The test requires that Git protocol version 2 is enabled on the server. It's assumed to be enabled by default but if not the test can be skipped by setting `QA_CAN_TEST_GIT_PROTOCOL_V2` to `false`. |
+| `:requires_praefect`   | The test requires that the GitLab instance uses [Gitaly Cluster](../../../administration/gitaly/praefect.md) (a.k.a. Praefect) as the repository storage . It's assumed to be used by default but if not the test can be skipped by setting `QA_CAN_TEST_PRAEFECT` to `false`. |
+| `:packages`       | The test requires a GitLab instance that has the [Package Registry](../../../administration/packages/#gitlab-package-registry-administration) enabled. |

doc/user/application_security/index.md

@@ -21,7 +21,7 @@ For an overview of application security with GitLab, see
 ## Quick start
 
 Get started quickly with Dependency Scanning, License Scanning, Static Application Security
-Testing (SAST), and Secret Detection by adding the following to your `.gitlab-ci.yml`:
+Testing (SAST), and Secret Detection by adding the following to your [`.gitlab-ci.yml`](../../ci/yaml/README.md):
 
 ```yaml
 include:
@@ -70,12 +70,26 @@ GitLab uses the following tools to scan and report known vulnerabilities found i
 | [Dependency List](dependency_list/index.md) **(ULTIMATE)**                   | View your project's dependencies and their known vulnerabilities.      |
 | [Dependency Scanning](dependency_scanning/index.md) **(ULTIMATE)**           | Analyze your dependencies for known vulnerabilities.                   |
 | [Dynamic Application Security Testing (DAST)](dast/index.md) **(ULTIMATE)**  | Analyze running web applications for known vulnerabilities.            |
-| [API fuzzing](api_fuzzing/index.md) **(ULTIMATE)**                 | Find unknown bugs and vulnerabilities in web APIs with fuzzing.    |
+| [API fuzzing](api_fuzzing/index.md) **(ULTIMATE)**                           | Find unknown bugs and vulnerabilities in web APIs with fuzzing.        |
 | [Secret Detection](secret_detection/index.md) **(ULTIMATE)**                 | Analyze Git history for leaked secrets.                                |
 | [Security Dashboard](security_dashboard/index.md) **(ULTIMATE)**             | View vulnerabilities in all your projects and groups.                  |
 | [Static Application Security Testing (SAST)](sast/index.md)                  | Analyze source code for known vulnerabilities.                         |
 | [Coverage fuzzing](coverage_fuzzing/index.md) **(ULTIMATE)**                 | Find unknown bugs and vulnerabilities with coverage-guided fuzzing.    |
 
+### Use security scanning tools with Pipelines for Merge Requests
+
+The security scanning tools can all be added to pipelines with [templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Security).
+See each tool for details on how to use include each template in your CI/CD configuration.
+
+By default, the application security jobs are configured to run for branch pipelines only.
+To use them with [pipelines for merge requests](../../ci/merge_request_pipelines/index.md),
+you may need to override the default `rules:` configuration to add:
+
+```yaml
+rules:
+  - if: $CI_PIPELINE_SOURCE == "merge_request_event"
+```
+
 ## Security Scanning with Auto DevOps
 
 When [Auto DevOps](../../topics/autodevops/) is enabled, all GitLab Security scanning tools will be configured using default settings.
@@ -144,21 +158,21 @@ To view details of DAST vulnerabilities:
 
 1. Click on the vulnerability's description. The following details are provided:
 
-   | Field            | Description                                                                                                                                                                   |
-|:-----------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Description      | Description of the vulnerability.                                                                                                                                             |
-| Project          | Namespace and project in which the vulnerability was detected.                                                                                                                |
-| Method           | HTTP method used to detect the vulnerability.                                                                                                                                 |
-| URL              | URL at which the vulnerability was detected.                                                                                                                                  |
-| Request Headers  | Headers of the request.                                                                                                                                                       |
-| Response Status  | Response status received from the application.                                                                                                                                |
-| Response Headers | Headers of the response received from the application.                                                                                                                        |
+| Field            | Description                                                        |
+|:-----------------|:------------------------------------------------------------------ |
+| Description      | Description of the vulnerability.                                  |
+| Project          | Namespace and project in which the vulnerability was detected.     |
+| Method           | HTTP method used to detect the vulnerability.                      |
+| URL              | URL at which the vulnerability was detected.                       |
+| Request Headers  | Headers of the request.                                            |
+| Response Status  | Response status received from the application.                     |
+| Response Headers | Headers of the response received from the application.             |
 | Evidence         | Evidence of the data found that verified the vulnerability. Often a snippet of the request or response, this can be used to help verify that the finding is a vulnerability. |
-| Identifiers      | Identifiers of the vulnerability.                                                                                                                                             |
-| Severity         | Severity of the vulnerability.                                                                                                                                                |
-| Scanner Type     | Type of vulnerability report.                                                                                                                                                 |
-| Links            | Links to further details of the detected vulnerability.                                                                                                                       |
-| Solution         | Details of a recommended solution to the vulnerability (optional).                                                                                                            |
+| Identifiers      | Identifiers of the vulnerability.                                  |
+| Severity         | Severity of the vulnerability.                                     |
+| Scanner Type     | Type of vulnerability report.                                      |
+| Links            | Links to further details of the detected vulnerability.            |
+| Solution         | Details of a recommended solution to the vulnerability (optional). |
 
 #### Hide sensitive information in headers
 
@@ -238,14 +252,11 @@ Selecting the button creates a merge request with the solution.
 
 #### Manually applying the suggested patch
 
-1. To manually apply the patch that was generated by GitLab for a vulnerability, select the dropdown arrow on the **Resolve
-with merge request** button, then select **Download patch to resolve**:
-
-![Resolve with Merge Request button dropdown](img/vulnerability_page_merge_request_button_dropdown_v13_1.png)
+To manually apply the patch that GitLab generated for a vulnerability:
 
-1. The button's text changes to **Download patch to resolve**. Click on it to download the patch:
+1. Select the **Resolve with merge request** dropdown, then select **Download patch to resolve**:
 
-![Download patch button](img/vulnerability_page_download_patch_button_v13_1.png)
+   ![Resolve with Merge Request button dropdown](img/vulnerability_page_merge_request_button_dropdown_v13_1.png)
 
 1. Ensure your local project has the same commit checked out that was used to generate the patch.
 1. Run `git apply remediation.patch`.

doc/user/search/index.md

@@ -117,6 +117,28 @@ the dropdown) **Approved-By** and select the user.
 
 ![Filter MRs by approved by](img/filter_approved_by_merge_requests_v13_0.png)
 
+### Filtering merge requests by environment or deployment date **(CORE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/44041) in GitLab 13.6.
+
+To filter merge requests by deployment data, such as the environment or a date,
+you can type (or select from the dropdown) the following:
+
+- Environment
+- Deployed-before
+- Deployed-after
+
+When filtering by an environment, a dropdown presents all environments that
+you can choose from:
+
+![Filter MRs by their environment](img/filtering_merge_requests_by_environment_v13_6.png)
+
+When filtering by a deploy date, you must enter the date manually. Deploy dates
+use the format `YYYY-MM-DD`, and must be quoted if you wish to specify
+both a date and time (`"YYYY-MM-DD HH:MM"`):
+
+![Filter MRs by a deploy date](img/filtering_merge_requests_by_date_v13_6.png)
+
 ## Filters autocomplete
 
 GitLab provides many filters across many pages (issues, merge requests, epics,

spec/frontend/design_management/components/upload/__snapshots__/button_spec.js.snap

@@ -14,41 +14,7 @@ exports[`Design management upload button component renders inverted upload desig
   >
     
     Upload designs
-    
-    <!---->
-  </gl-button-stub>
-   
-  <input
-    accept="image/*"
-    class="hide"
-    multiple="multiple"
-    name="design_file"
-    type="file"
-  />
-</div>
-`;
-
-exports[`Design management upload button component renders loading icon 1`] = `
-<div>
-  <gl-button-stub
-    buttontextclasses=""
-    category="primary"
-    disabled="true"
-    icon=""
-    size="small"
-    title="Adding a design with the same filename replaces the file in a new version."
-    variant="default"
-  >
-    
-    Upload designs
-    
-    <gl-loading-icon-stub
-      class="ml-1"
-      color="dark"
-      inline="true"
-      label="Loading"
-      size="sm"
-    />
+  
   </gl-button-stub>
    
   <input
@@ -73,8 +39,7 @@ exports[`Design management upload button component renders upload design button
   >
     
     Upload designs
-    
-    <!---->
+  
   </gl-button-stub>
    
   <input

spec/frontend/design_management/components/upload/button_spec.js

 import { shallowMount } from '@vue/test-utils';
+import { GlButton } from '@gitlab/ui';
 import UploadButton from '~/design_management/components/upload/button.vue';
 
 describe('Design management upload button component', () => {
   let wrapper;
 
-  function createComponent(isSaving = false, isInverted = false) {
+  function createComponent({ isSaving = false, isInverted = false } = {}) {
     wrapper = shallowMount(UploadButton, {
       propsData: {
         isSaving,
@@ -24,15 +25,19 @@ describe('Design management upload button component', () => {
   });
 
   it('renders inverted upload design button', () => {
-    createComponent(false, true);
+    createComponent({ isInverted: true });
 
     expect(wrapper.element).toMatchSnapshot();
   });
 
-  it('renders loading icon', () => {
-    createComponent(true);
+  describe('when `isSaving` prop is `true`', () => {
+    it('Button `loading` prop is `true`', () => {
+      createComponent({ isSaving: true });
 
-    expect(wrapper.element).toMatchSnapshot();
+      const button = wrapper.find(GlButton);
+      expect(button.exists()).toBe(true);
+      expect(button.props('loading')).toBe(true);
+    });
   });
 
   describe('onFileUploadChange', () => {

spec/models/project_spec.rb

@@ -5927,6 +5927,26 @@ RSpec.describe Project, factory_default: :keep do
     end
   end
 
+  describe '#update_pages_deployment!' do
+    let(:project) { create(:project) }
+    let(:deployment) { create(:pages_deployment, project: project) }
+
+    it "creates new metadata record if none exists yet and sets deployment" do
+      project.pages_metadatum.destroy!
+      project.reload
+
+      project.update_pages_deployment!(deployment)
+
+      expect(project.pages_metadatum.pages_deployment).to eq(deployment)
+    end
+
+    it "updates the existing metadara record with deployment" do
+      expect do
+        project.update_pages_deployment!(deployment)
+      end.to change { project.pages_metadatum.reload.pages_deployment }.from(nil).to(deployment)
+    end
+  end
+
   describe '#has_pool_repsitory?' do
     it 'returns false when it does not have a pool repository' do
       subject = create(:project, :repository)

spec/services/projects/update_pages_service_spec.rb

@@ -71,6 +71,17 @@ RSpec.describe Projects::UpdatePagesService do
         expect(project.pages_metadatum.reload.pages_deployment_id).to eq(deployment.id)
       end
 
+      it 'does not fail if pages_metadata is absent' do
+        project.pages_metadatum.destroy!
+        project.reload
+
+        expect do
+          expect(execute).to eq(:success)
+        end.to change { project.pages_deployments.count }.by(1)
+
+        expect(project.pages_metadatum.reload.pages_deployment).to eq(project.pages_deployments.last)
+      end
+
       context 'when there is an old pages deployment' do
         let!(:old_deployment_from_another_project) { create(:pages_deployment) }
         let!(:old_deployment) { create(:pages_deployment, project: project) }