Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
3b67d92c35
commit
b5cdfc98dd
17 changed files with 159 additions and 91 deletions
|
|
@ -1,12 +1,11 @@
|
|||
= form_for @application_setting, url: metrics_and_profiling_admin_application_settings_path(anchor: 'js-performance-bar-settings'), html: { class: 'fieldset-form' } do |f|
|
||||
= gitlab_ui_form_for @application_setting, url: metrics_and_profiling_admin_application_settings_path(anchor: 'js-performance-bar-settings'), html: { class: 'fieldset-form' } do |f|
|
||||
= form_errors(@application_setting)
|
||||
|
||||
%fieldset
|
||||
.form-group
|
||||
.form-check
|
||||
= f.check_box :performance_bar_enabled, class: 'form-check-input', data: { qa_selector: 'enable_performance_bar_checkbox'}
|
||||
= f.label :performance_bar_enabled, class: 'form-check-label' do
|
||||
= _("Allow non-administrators access to the performance bar")
|
||||
= f.gitlab_ui_checkbox_component :performance_bar_enabled,
|
||||
s_("Allow non-administrators access to the performance bar"),
|
||||
checkbox_options: { data: { qa_selector: 'enable_performance_bar_checkbox' } }
|
||||
.form-group
|
||||
= f.label :performance_bar_allowed_group_path, _('Allow access to members of the following group'), class: 'label-bold'
|
||||
= f.text_field :performance_bar_allowed_group_path, class: 'form-control gl-form-input', placeholder: 'my-org/my-group', value: @application_setting.performance_bar_allowed_group&.full_path
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
- name: "NFS for Git repository storage" # The name of the feature to be deprecated
|
||||
announcement_milestone: "14.0" # The milestone when this feature was first announced as deprecated.
|
||||
announcement_date: "2021-06-22" # The date of the milestone release when this feature was first announced as deprecated
|
||||
removal_milestone: "15.0" # The milestone when this feature is planned to be removed
|
||||
removal_date: "2022-05-22" # (optional - may be required in the future) YYYY-MM-DD format - the date of the milestone release when this feature is planned to be removed
|
||||
breaking_change: true
|
||||
removal_milestone: "15.6" # The milestone when this feature is planned to be removed
|
||||
removal_date: "2022-11-22" # (optional - may be required in the future) YYYY-MM-DD format - the date of the milestone release when this feature is planned to be removed
|
||||
breaking_change: false
|
||||
body: | # Do not modify this line, instead modify the lines below.
|
||||
With the general availability of Gitaly Cluster ([introduced in GitLab 13.0](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/)), we have deprecated development (bugfixes, performance improvements, etc) for NFS for Git repository storage in GitLab 14.0. We will continue to provide technical support for NFS for Git repositories throughout 14.x, but we will remove all support for NFS in GitLab 15.0. Please see our official [Statement of Support](https://about.gitlab.com/support/statement-of-support.html#gitaly-and-nfs) for further information.
|
||||
With the general availability of Gitaly Cluster ([introduced in GitLab 13.0](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/)), we have deprecated development (bugfixes, performance improvements, etc) for NFS for Git repository storage in GitLab 14.0. We will continue to provide technical support for NFS for Git repositories throughout 14.x, but we will remove all support for NFS on November 22, 2022. This was originally planned for May 22, 2022, but in an effort to allow continued maturity of Gitaly Cluster, we have chosen to extend our deprecation of support date. Please see our official [Statement of Support](https://about.gitlab.com/support/statement-of-support.html#gitaly-and-nfs) for further information.
|
||||
|
||||
Gitaly Cluster offers tremendous benefits for our customers such as:
|
||||
|
||||
|
|
@ -15,7 +15,8 @@
|
|||
|
||||
We encourage customers currently using NFS for Git repositories to plan their migration by reviewing our documentation on [migrating to Gitaly Cluster](https://docs.gitlab.com/ee/administration/gitaly/index.html#migrate-to-gitaly-cluster).
|
||||
|
||||
stage: # (optional - may be required in the future) String value of the stage that the feature was created in. e.g., Growth
|
||||
reporter: mjwood
|
||||
stage: create # (optional - may be required in the future) String value of the stage that the feature was created in. e.g., Growth
|
||||
tiers: # (optional - may be required in the future) An array of tiers that the feature is available in currently. e.g., [Free, Silver, Gold, Core, Premium, Ultimate]
|
||||
issue_url: # (optional) This is a link to the deprecation issue in GitLab
|
||||
documentation_url: # (optional) This is a link to the current documentation page
|
||||
|
|
|
|||
|
|
@ -1,28 +0,0 @@
|
|||
- name: "Reminder: support for NFS repository storage" # The name of the feature to be deprecated
|
||||
announcement_milestone: "14.8" # The milestone when this feature was first announced as deprecated.
|
||||
announcement_date: "2022-02-22" # The date of the milestone release when this feature was first announced as deprecated. This should almost always be the 22nd of a month (YYYY-MM-22), unless you did an out of band blog post.
|
||||
removal_milestone: "15.0" # The milestone when this feature is planned to be removed
|
||||
removal_date: "2022-05-22" # The date of the milestone release when this feature is planned to be removed. This should almost always be the 22nd of a month (YYYY-MM-22), unless you did an out of band blog post.
|
||||
breaking_change: true # If this deprecation is a breaking change, set this value to true
|
||||
reporter: mjwood # GitLab username of the person reporting the deprecation
|
||||
body: | # Do not modify this line, instead modify the lines below.
|
||||
As [announced](https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-released/#nfs-for-git-repository-storage-deprecated) at the
|
||||
release of GitLab 14.0, technical support for NFS storage for Git repositories is being removed. Please see our official
|
||||
[Statement of Support](https://about.gitlab.com/support/statement-of-support.html#gitaly-and-nfs) for additional information.
|
||||
|
||||
We encourage customers currently using NFS for Git repositories to plan their migration by reviewing our documentation on
|
||||
[migrating to Gitaly Cluster](https://docs.gitlab.com/ee/administration/gitaly/#migrating-to-gitaly-cluster).
|
||||
|
||||
Gitaly Cluster offers tremendous benefits for our customers such as:
|
||||
|
||||
- [Variable replication factors](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#configure-replication-factor)
|
||||
- [Strong consistency](https://docs.gitlab.com/ee/administration/gitaly/#strong-consistency)
|
||||
- [Distributed read capabilities](https://docs.gitlab.com/ee/administration/gitaly/#distributed-reads)
|
||||
|
||||
# The following items are not published on the docs page, but may be used in the future.
|
||||
stage: Gitaly # (optional - may be required in the future) String value of the stage that the feature was created in. e.g., Growth
|
||||
tiers: # (optional - may be required in the future) An array of tiers that the feature is available in currently. e.g., [Free, Silver, Gold, Core, Premium, Ultimate]
|
||||
issue_url: # (optional) This is a link to the deprecation issue in GitLab
|
||||
documentation_url: # (optional) This is a link to the current documentation page
|
||||
image_url: # (optional) This is a link to a thumbnail image depicting the feature
|
||||
video_url: # (optional) Use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
|
||||
|
|
@ -4,6 +4,14 @@ classes:
|
|||
- Postgresql::DetachedPartition
|
||||
feature_categories:
|
||||
- database
|
||||
description: TODO
|
||||
description: >
|
||||
The detached_partitions table stores information about partitions in the gitlab_partitions_dynamic schema that
|
||||
have been scheduled for drop, but not yet dropped.
|
||||
|
||||
These partitions were created by the Gitlab::Database::Partitioning::PartitionManager, and then detached from their
|
||||
parent tables and added to this table when no longer part of the active partition set. Partitions are scheduled for
|
||||
deletion one week after detachment.
|
||||
|
||||
Rows in this table are processed by Database::DropDetachedPartitionsWorker, which runs once a day.
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67056
|
||||
milestone: '14.2'
|
||||
|
|
|
|||
|
|
@ -1,8 +0,0 @@
|
|||
---
|
||||
table_name: partitioned_foreign_keys
|
||||
classes: []
|
||||
feature_categories:
|
||||
- database
|
||||
description: TODO
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/9af97ee69a36de1dc4e73f4030d6316d3f0a82c5
|
||||
milestone: '13.0'
|
||||
|
|
@ -56,7 +56,7 @@ Before deploying Gitaly Cluster, please review:
|
|||
If you have:
|
||||
|
||||
- Not yet migrated to Gitaly Cluster and want to continue using NFS, remain on the service you are using. NFS is
|
||||
supported in 14.x releases but is [deprecated](../../update/deprecations.md#reminder-support-for-nfs-repository-storage).
|
||||
supported in 14.x releases but is [deprecated](../../update/deprecations.md#nfs-for-git-repository-storage).
|
||||
Support for storing Git repository data on NFS will end for all versions of GitLab with the release of 15.0.
|
||||
- Not yet migrated to Gitaly Cluster but want to migrate away from NFS, you have two options:
|
||||
- A sharded Gitaly instance.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
WARNING:
|
||||
This feature is in its end-of-life process. It is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/348909)
|
||||
in GitLab 14.9, and is planned for removal in GitLab 15.0.
|
||||
in GitLab 14.9, and is planned for removal in GitLab 16.0.
|
||||
|
||||
GitLab provides administrators insights into the health of their GitLab instance.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,6 +11,16 @@ links. For manipulating other Release assets, see [Release API](index.md).
|
|||
|
||||
GitLab supports links to `http`, `https`, and `ftp` assets.
|
||||
|
||||
## Authentication
|
||||
|
||||
For authentication, the Release Links API accepts:
|
||||
|
||||
- A [Personal Access Token](../../user/profile/personal_access_tokens.md) using the
|
||||
`PRIVATE-TOKEN` header.
|
||||
- A [Project Access Token](../../user/project/settings/project_access_tokens.md) using the `PRIVATE-TOKEN` header.
|
||||
|
||||
The [GitLab CI/CD job token](../../ci/jobs/ci_job_token.md) `$CI_JOB_TOKEN` is not supported. See [GitLab issue #50819](https://gitlab.com/gitlab-org/gitlab/-/issues/250819) for more details.
|
||||
|
||||
## Get links
|
||||
|
||||
Get assets as links from a Release.
|
||||
|
|
|
|||
|
|
@ -264,9 +264,15 @@ Read more about [Vue Apollo](https://github.com/vuejs/vue-apollo) in the [Vue Ap
|
|||
|
||||
### Local state with Apollo
|
||||
|
||||
It is possible to manage an application state with Apollo by passing
|
||||
in a resolvers object when creating the default client. The default state can be set by writing
|
||||
to the cache after setting up the default client. In the example below, we are using query with `@client` Apollo directive to write the initial data to Apollo cache and then get this state in the Vue component:
|
||||
It is possible to manage an application state with Apollo by using [client-site resolvers](#using-client-side-resolvers)
|
||||
or [type policies with reactive variables](#using-type-policies-with-reactive-variables) when creating your default
|
||||
client.
|
||||
|
||||
#### Using client-side resolvers
|
||||
|
||||
The default state can be set by writing to the cache after setting up the default client. In the
|
||||
example below, we are using query with `@client` Apollo directive to write the initial data to
|
||||
Apollo cache and then get this state in the Vue component:
|
||||
|
||||
```javascript
|
||||
// user.query.graphql
|
||||
|
|
@ -322,7 +328,7 @@ export default {
|
|||
|
||||
Along with creating local data, we can also extend existing GraphQL types with `@client` fields. This is extremely helpful when we need to mock an API response for fields not yet added to our GraphQL API.
|
||||
|
||||
#### Mocking API response with local Apollo cache
|
||||
##### Mocking API response with local Apollo cache
|
||||
|
||||
Using local Apollo Cache is helpful when we have a need to mock some GraphQL API responses, queries, or mutations locally (such as when they're still not added to our actual API).
|
||||
|
||||
|
|
@ -384,6 +390,108 @@ For each attempt to fetch a version, our client fetches `id` and `sha` from the
|
|||
|
||||
Read more about local state management with Apollo in the [Vue Apollo documentation](https://vue-apollo.netlify.app/guide/local-state.html#local-state).
|
||||
|
||||
#### Using type policies with reactive variables
|
||||
|
||||
Apollo Client 3 offers an alternative to [client-side resolvers](#using-client-side-resolvers) by using
|
||||
[reactive variables to store client state](https://www.apollographql.com/docs/react/local-state/reactive-variables/).
|
||||
|
||||
**NOTE:**
|
||||
We are still learning the best practices for both **type policies** and **reactive vars**.
|
||||
Take a moment to improve this guide or [leave a comment](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/100)
|
||||
if you use it!
|
||||
|
||||
In the example below we define a `@client` query and its `typedefs`:
|
||||
|
||||
```javascript
|
||||
// ./graphql/typedefs.graphql
|
||||
extend type Query {
|
||||
localData: String!
|
||||
}
|
||||
```
|
||||
|
||||
```javascript
|
||||
// ./graphql/get_local_data.query.graphql
|
||||
query getLocalData {
|
||||
localData @client
|
||||
}
|
||||
```
|
||||
|
||||
Similar to resolvers, your `typePolicies` will execute when the `@client` query is used. However,
|
||||
using `makeVar` will trigger every relevant active Apollo query to reactively update when the state
|
||||
mutates.
|
||||
|
||||
```javascript
|
||||
// ./graphql/local_state.js
|
||||
|
||||
import { makeVar } from '@apollo/client/core';
|
||||
import typeDefs from './typedefs.graphql';
|
||||
|
||||
export const createLocalState = () => {
|
||||
// set an initial value
|
||||
const localDataVar = makeVar('');
|
||||
|
||||
const cacheConfig = {
|
||||
typePolicies: {
|
||||
Query: {
|
||||
fields: {
|
||||
localData() {
|
||||
// obtain current value
|
||||
// triggers when `localDataVar` is updated
|
||||
return localDataVar();
|
||||
},
|
||||
},
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
// methods that update local state
|
||||
const localMutations = {
|
||||
setLocalData(newData) {
|
||||
localDataVar(newData);
|
||||
},
|
||||
clearData() {
|
||||
localDataVar('');
|
||||
},
|
||||
};
|
||||
|
||||
return {
|
||||
cacheConfig,
|
||||
typeDefs,
|
||||
localMutations,
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
Pass the cache config to your Apollo Client:
|
||||
|
||||
```javascript
|
||||
// index.js
|
||||
|
||||
// ...
|
||||
import createDefaultClient from '~/lib/graphql';
|
||||
import { createLocalState } from './graphql/local_state';
|
||||
|
||||
const { cacheConfig, typeDefs, localMutations } = createLocalState();
|
||||
|
||||
const apolloProvider = new VueApollo({
|
||||
defaultClient: createDefaultClient({}, { cacheConfig, typeDefs }),
|
||||
});
|
||||
|
||||
return new Vue({
|
||||
el,
|
||||
apolloProvider,
|
||||
provide: {
|
||||
// inject local state mutations to your app
|
||||
localMutations,
|
||||
},
|
||||
render(h) {
|
||||
return h(MyApp);
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
Wherever used, the local query will update as the state updates thanks to the **reactive variable**.
|
||||
|
||||
### Using with Vuex
|
||||
|
||||
When the Apollo Client is used in Vuex and fetched data is stored in the Vuex store, the Apollo Client cache does not need to be enabled. Otherwise we would have data from the API stored in two places - Vuex store and Apollo Client cache. With Apollo's default settings, a subsequent fetch from the GraphQL API could result in fetching data from Apollo cache (in the case where we have the same query and variables). To prevent this behavior, we need to disable Apollo Client cache by passing a valid `fetchPolicy` option to its constructor:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
# Embedding metric charts within GitLab Flavored Markdown **(FREE)**
|
||||
|
||||
You can display metrics charts within
|
||||
[GitLab Flavored Markdown](../../user/markdown.md#gitlab-flavored-markdown)
|
||||
[GitLab Flavored Markdown (GLFM)](../../user/markdown.md)
|
||||
fields such as issue or merge request descriptions. The maximum number of embedded
|
||||
charts allowed in a GitLab Flavored Markdown field is 100.
|
||||
Embedding charts is useful when sharing an application incident or performance
|
||||
|
|
|
|||
|
|
@ -590,29 +590,6 @@ existing runners.
|
|||
|
||||
**Planned removal milestone: 16.0 (2023-04-22)**
|
||||
|
||||
### Reminder: support for NFS repository storage
|
||||
|
||||
WARNING:
|
||||
This feature will be changed or removed in 15.0
|
||||
as a [breaking change](https://docs.gitlab.com/ee/development/contributing/#breaking-changes).
|
||||
Before updating GitLab, review the details carefully to determine if you need to make any
|
||||
changes to your code, settings, or workflow.
|
||||
|
||||
As [announced](https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-released/#nfs-for-git-repository-storage-deprecated) at the
|
||||
release of GitLab 14.0, technical support for NFS storage for Git repositories is being removed. Please see our official
|
||||
[Statement of Support](https://about.gitlab.com/support/statement-of-support.html#gitaly-and-nfs) for additional information.
|
||||
|
||||
We encourage customers currently using NFS for Git repositories to plan their migration by reviewing our documentation on
|
||||
[migrating to Gitaly Cluster](https://docs.gitlab.com/ee/administration/gitaly/#migrating-to-gitaly-cluster).
|
||||
|
||||
Gitaly Cluster offers tremendous benefits for our customers such as:
|
||||
|
||||
- [Variable replication factors](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#configure-replication-factor)
|
||||
- [Strong consistency](https://docs.gitlab.com/ee/administration/gitaly/#strong-consistency)
|
||||
- [Distributed read capabilities](https://docs.gitlab.com/ee/administration/gitaly/#distributed-reads)
|
||||
|
||||
**Planned removal milestone: 15.0 (2022-05-22)**
|
||||
|
||||
### Request profiling
|
||||
|
||||
WARNING:
|
||||
|
|
@ -1599,13 +1576,7 @@ This will result in the rename of the sub-chart: `gitlab/task-runner` to `gitlab
|
|||
|
||||
### NFS for Git repository storage
|
||||
|
||||
WARNING:
|
||||
This feature will be changed or removed in 15.0
|
||||
as a [breaking change](https://docs.gitlab.com/ee/development/contributing/#breaking-changes).
|
||||
Before updating GitLab, review the details carefully to determine if you need to make any
|
||||
changes to your code, settings, or workflow.
|
||||
|
||||
With the general availability of Gitaly Cluster ([introduced in GitLab 13.0](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/)), we have deprecated development (bugfixes, performance improvements, etc) for NFS for Git repository storage in GitLab 14.0. We will continue to provide technical support for NFS for Git repositories throughout 14.x, but we will remove all support for NFS in GitLab 15.0. Please see our official [Statement of Support](https://about.gitlab.com/support/statement-of-support.html#gitaly-and-nfs) for further information.
|
||||
With the general availability of Gitaly Cluster ([introduced in GitLab 13.0](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/)), we have deprecated development (bugfixes, performance improvements, etc) for NFS for Git repository storage in GitLab 14.0. We will continue to provide technical support for NFS for Git repositories throughout 14.x, but we will remove all support for NFS on November 22, 2022. This was originally planned for May 22, 2022, but in an effort to allow continued maturity of Gitaly Cluster, we have chosen to extend our deprecation of support date. Please see our official [Statement of Support](https://about.gitlab.com/support/statement-of-support.html#gitaly-and-nfs) for further information.
|
||||
|
||||
Gitaly Cluster offers tremendous benefits for our customers such as:
|
||||
|
||||
|
|
@ -1615,7 +1586,7 @@ Gitaly Cluster offers tremendous benefits for our customers such as:
|
|||
|
||||
We encourage customers currently using NFS for Git repositories to plan their migration by reviewing our documentation on [migrating to Gitaly Cluster](https://docs.gitlab.com/ee/administration/gitaly/index.html#migrate-to-gitaly-cluster).
|
||||
|
||||
**Planned removal milestone: 15.0 (2022-05-22)**
|
||||
**Planned removal milestone: 15.6 (2022-11-22)**
|
||||
|
||||
### OAuth implicit grant
|
||||
|
||||
|
|
|
|||
|
|
@ -586,7 +586,8 @@ profile increases as the number of tests increases.
|
|||
| CI/CD variable | Description |
|
||||
|-------------------------------------------------------------|-------------|
|
||||
| `SECURE_ANALYZERS_PREFIX` | Specify the Docker registry base address from which to download the analyzer. |
|
||||
| `FUZZAPI_VERSION` | Specify API Fuzzing container version. Defaults to `latest`. |
|
||||
| `FUZZAPI_VERSION` | Specify API Fuzzing container version. Defaults to `1`. |
|
||||
| `FUZZAPI_IMAGE_SUFFIX` | Specify a container image suffix. Defaults to none. |
|
||||
| `FUZZAPI_TARGET_URL` | Base URL of API testing target. |
|
||||
| `FUZZAPI_CONFIG` | [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/276395) in GitLab 13.12, replaced with default `.gitlab/gitlab-api-fuzzing-config.yml`. API Fuzzing configuration file. |
|
||||
|[`FUZZAPI_PROFILE`](#api-fuzzing-profiles) | Configuration profile to use during testing. Defaults to `Quick-10`. |
|
||||
|
|
@ -920,7 +921,7 @@ def get_auth_response():
|
|||
# In our example, access token is retrieved from a given endpoint
|
||||
try:
|
||||
|
||||
# Performs a http request, response sample:
|
||||
# Performs a http request, response sample:
|
||||
# { "Token" : "b5638ae7-6e77-4585-b035-7d9de2e3f6b3" }
|
||||
response = get_auth_response()
|
||||
|
||||
|
|
@ -950,7 +951,7 @@ except Exception as e:
|
|||
logging.error(f'Error, unknown error while retrieving access token. Error message: {e}')
|
||||
raise
|
||||
|
||||
# computes object that holds overrides file content.
|
||||
# computes object that holds overrides file content.
|
||||
# It uses data fetched from request
|
||||
overrides_data = {
|
||||
"headers": {
|
||||
|
|
|
|||
|
|
@ -537,7 +537,9 @@ can be added, removed, and modified by creating a custom configuration.
|
|||
|
||||
| CI/CD variable | Description |
|
||||
|------------------------------------------------------|--------------------|
|
||||
| `DAST_API_VERSION` | Specify DAST API container version. Defaults to `latest`. |
|
||||
| `SECURE_ANALYZERS_PREFIX` | Specify the Docker registry base address from which to download the analyzer. |
|
||||
| `DAST_API_VERSION` | Specify DAST API container version. Defaults to `1`. |
|
||||
| `DAST_API_IMAGE_SUFFIX` | Specify a container image suffix. Defaults to none. |
|
||||
| `DAST_API_TARGET_URL` | Base URL of API testing target. |
|
||||
|[`DAST_API_CONFIG`](#configuration-files) | DAST API configuration file. Defaults to `.gitlab-dast-api.yml`. |
|
||||
|[`DAST_API_PROFILE`](#configuration-files) | Configuration profile to use during testing. Defaults to `Quick`. |
|
||||
|
|
|
|||
|
|
@ -857,6 +857,7 @@ The following are Docker image-related CI/CD variables.
|
|||
| `SECURE_ANALYZERS_PREFIX` | Override the name of the Docker registry providing the default images (proxy). Read more about [customizing analyzers](analyzers.md). |
|
||||
| `SAST_EXCLUDED_ANALYZERS` | Names of default images that should never run. Read more about [customizing analyzers](analyzers.md). |
|
||||
| `SAST_ANALYZER_IMAGE_TAG` | Override the default version of analyzer image. Read more about [pinning the analyzer image version](#pinning-to-minor-image-version). |
|
||||
| `SAST_IMAGE_SUFFIX` | Suffix added to the image name. If set to `-fips`, `FIPS-enabled` images are used for scan. See [FIPS-enabled images](#fips-enabled-images) for more details. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/355518) in GitLab 14.10. |
|
||||
|
||||
#### Vulnerability filters
|
||||
|
||||
|
|
|
|||
|
|
@ -200,6 +200,7 @@ Secret Detection can be customized by defining available CI/CD variables:
|
|||
| `SECRET_DETECTION_COMMITS` | - | The list of commits that Gitleaks should scan. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/243564) in GitLab 13.5. |
|
||||
| `SECRET_DETECTION_EXCLUDED_PATHS` | "" | Exclude vulnerabilities from output based on the paths. This is a comma-separated list of patterns. Patterns can be globs, or file or folder paths (for example, `doc,spec` ). Parent directories also match patterns. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/225273) in GitLab 13.3. |
|
||||
| `SECRET_DETECTION_HISTORIC_SCAN` | false | Flag to enable a historic Gitleaks scan. |
|
||||
| `SECRET_DETECTION_IMAGE_SUFFIX` | Suffix added to the image name. If set to `-fips`, `FIPS-enabled` images are used for scan. See [FIPS-enabled images](#fips-enabled-images) for more details. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/355519) in GitLab 14.10. |
|
||||
|
||||
### Custom rulesets **(ULTIMATE)**
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,9 @@ group: Source Code
|
|||
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
|
||||
---
|
||||
|
||||
# GitLab Flavored Markdown **(FREE)**
|
||||
# GitLab Flavored Markdown (GLFM) **(FREE)**
|
||||
|
||||
> The abbreviation [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/24592) from `GFM` to `GLFM` in GitLab 14.10.
|
||||
|
||||
GitLab automatically renders Markdown content. For example, when you add a comment to an issue,
|
||||
you type the text in the Markdown language. When you save the issue, the text is rendered
|
||||
|
|
|
|||
|
|
@ -222,7 +222,7 @@ To edit Markdown files in the Web IDE:
|
|||
|
||||
1. Go to your repository, and navigate to the Markdown page you want to edit.
|
||||
1. Select **Open in Web IDE**, and GitLab loads the page in a tab in the editor.
|
||||
1. Make your changes to the file. GitLab supports [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown).
|
||||
1. Make your changes to the file. GitLab supports [GitLab Flavored Markdown (GLFM)](../../markdown.md).
|
||||
1. When your changes are complete, select **Commit** in the left sidebar.
|
||||
1. Add a commit message, select the branch you want to commit to, and select **Commit**.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue