Commit b84c221a authored by Olena Horal-Koretska's avatar Olena Horal-Koretska

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

Edit new alert HTTP endpoint

See merge request gitlab-org/gitlab!46697
parents 9ce4ced5 f354daa8
<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
......
......@@ -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
......
......@@ -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(
......
---
title: Use standard loading state for Design Upload button
merge_request: 46292
author:
type: changed
This diff is collapsed.
......@@ -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
......
......@@ -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
......
......@@ -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. |
......@@ -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`.
......
......@@ -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,
......
......@@ -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
......
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', () => {
......
......@@ -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)
......
......@@ -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) }
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment