Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorGitLab Bot <gitlab-bot@gitlab.com>2023-08-07 06:09:30 +0300
committerGitLab Bot <gitlab-bot@gitlab.com>2023-08-07 06:09:30 +0300
commit923a8c950c009e65fd17ae2ab6c5e245a66175b5 (patch)
treea7a2a3167d392cbcb75ee0f1d9613139904e2723 /doc
parent6ac97de78e3aee0c27bd08c15999db1b6be5c75a (diff)
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
-rw-r--r--doc/development/api_graphql_styleguide.md4
-rw-r--r--doc/user/application_security/policies/index.md1
2 files changed, 3 insertions, 2 deletions
diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index 9bc62ed7095..372a8980ba1 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -2045,8 +2045,8 @@ full stack:
- An [argument's `default_value`](https://graphql-ruby.org/fields/arguments.html) applies correctly.
- Objects resolve successfully, and there are no N+1 issues.
-When adding a query, you can use the `a working graphql query` shared example to test if the query
-renders valid results.
+When adding a query, you can use the `a working graphql query that returns data` and
+`a working graphql query that returns no data` shared examples to test if the query renders valid results.
You can construct a query including all available fields using the `GraphqlHelpers#all_graphql_fields_for`
helper. This makes it more straightforward to add a test rendering all possible fields for a query.
diff --git a/doc/user/application_security/policies/index.md b/doc/user/application_security/policies/index.md
index 4e610d64ec9..7c4434fb481 100644
--- a/doc/user/application_security/policies/index.md
+++ b/doc/user/application_security/policies/index.md
@@ -150,5 +150,6 @@ The workaround is to amend your group or instance push rules to allow branches f
- When enforcing scan execution policies, the target project's pipeline is triggered by the user who last updated the security policy project's `policy.yml` file. The user must have permission to trigger the pipeline in the project for the policy to be enforced, and the pipeline to run. Work to address this is being tracked in [issue 394958](https://gitlab.com/gitlab-org/gitlab/-/issues/394958).
- You should not link a security policy project to a development project and to the group or sub-group the development project belongs to at the same time. Linking this way will result in approval rules from the Scan Result Policy not being applied to merge requests in the development project.
- When creating a Scan Result Policy, neither the array `severity_levels` nor the array `vulnerability_states` in the [scan_finding rule](../policies/scan-result-policies.md#scan_finding-rule-type) can be left empty; for a working rule, at least one entry must exist.
+- When configuring pipeline and scan result policies, it's important to remember that security scans performed in manual jobs aren't verified to determine whether MR approval is required. When you run a manual job with security scans, it won't ensure approval even if vulnerabilities are introduced.
If you are still experiencing issues, you can [view recent reported bugs](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=popularity&state=opened&label_name%5B%5D=group%3A%3Asecurity%20policies&label_name%5B%5D=type%3A%3Abug&first_page_size=20) and raise new unreported issues.