diff options
Diffstat (limited to 'doc')
23 files changed, 178 insertions, 72 deletions
diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md index 6ffde46a212..f30dba331b8 100644 --- a/doc/administration/instance_limits.md +++ b/doc/administration/instance_limits.md @@ -160,7 +160,7 @@ There is a limit when embedding metrics in GFM for performance reasons. ## Number of webhooks -On GitLab.com, the [maximum number of webhooks](../user/gitlab_com/index.md#maximum-number-of-webhooks) per project, and per group, is limited. +On GitLab.com, the [maximum number of webhooks and their size](../user/gitlab_com/index.md#webhooks) per project, and per group, is limited. To set this limit on a self-managed installation, run the following in the [GitLab Rails console](troubleshooting/debug.md#starting-a-rails-console-session): diff --git a/doc/api/groups.md b/doc/api/groups.md index 82ee2fb1db5..79ac10d4ac6 100644 --- a/doc/api/groups.md +++ b/doc/api/groups.md @@ -847,7 +847,7 @@ Only available to group owners and administrators. This endpoint either: - Removes group, and queues a background job to delete all projects in the group as well. -- Since [GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/33257), on [Premium or Silver](https://about.gitlab.com/pricing/) or higher tiers, marks a group for deletion. The deletion will happen 7 days later by default, but this can be changed in the [instance settings](../user/admin_area/settings/visibility_and_access_controls.md#default-deletion-adjourned-period-premium-only). +- Since [GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/33257), on [Premium or Silver](https://about.gitlab.com/pricing/) or higher tiers, marks a group for deletion. The deletion will happen 7 days later by default, but this can be changed in the [instance settings](../user/admin_area/settings/visibility_and_access_controls.md#default-deletion-delay-premium-only). ```plaintext DELETE /groups/:id diff --git a/doc/api/projects.md b/doc/api/projects.md index 0b59e0193f9..06ddce7a871 100644 --- a/doc/api/projects.md +++ b/doc/api/projects.md @@ -1841,7 +1841,7 @@ This endpoint: group admins can [configure](../user/group/index.md#enabling-delayed-project-removal-premium) projects within a group to be deleted after a delayed period. When enabled, actual deletion happens after the number of days -specified in the [default deletion period](../user/admin_area/settings/visibility_and_access_controls.md#default-deletion-adjourned-period-premium-only). +specified in the [default deletion delay](../user/admin_area/settings/visibility_and_access_controls.md#default-deletion-delay-premium-only). CAUTION: **Warning:** The default behavior of [Delayed Project deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6 diff --git a/doc/ci/img/ci_lint.png b/doc/ci/img/ci_lint.png Binary files differnew file mode 100644 index 00000000000..e62de011293 --- /dev/null +++ b/doc/ci/img/ci_lint.png diff --git a/doc/ci/img/ci_lint_dry_run.png b/doc/ci/img/ci_lint_dry_run.png Binary files differnew file mode 100644 index 00000000000..4092b66d534 --- /dev/null +++ b/doc/ci/img/ci_lint_dry_run.png diff --git a/doc/ci/lint.md b/doc/ci/lint.md new file mode 100644 index 00000000000..716a4218d97 --- /dev/null +++ b/doc/ci/lint.md @@ -0,0 +1,41 @@ +# CI Lint + +If you want to test the validity of your GitLab CI/CD configuration before committing +the changes, you can use the CI Lint tool. This tool checks for syntax and logical +errors by default, and can simulate pipeline creation to try to find more complicated +issues as well. + +To access the CI Lint tool, navigate to **CI/CD > Pipelines** or **CI/CD > Jobs** +in your project and click **CI lint**. + +## Validate basic logic and syntax + +By default, the CI lint checks the syntax of your CI YAML configuration and also runs +some basic logical validations. + +To use the CI lint, paste a complete CI configuration (`.gitlab-ci.yml` for example) +into the text box and click **Validate**: + + + +## Pipeline simulation + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/229794) in GitLab 13.3. + +Not all pipeline configuration issues can be found by the [basic CI lint validation](#validate-basic-logic-and-syntax). +You can simulate the creation of a pipeline for deeper validation that can discover +more complicated issues. + +To validate the configuration by running a pipeline simulation: + +1. Paste the GitLab CI configuration to verify into the text box. +1. Click the **Simulate pipeline creation for the default branch** checkbox. +1. Click **Validate**. + + + +### Pipeline simulation limitations + +Simulations run as `git push` events against the default branch. You must have +[permissions](../user/permissions.md#project-members-permissions) to create pipelines +on this branch to validate with a simulation. diff --git a/doc/ci/quick_start/README.md b/doc/ci/quick_start/README.md index 2ced58db663..050df243af4 100644 --- a/doc/ci/quick_start/README.md +++ b/doc/ci/quick_start/README.md @@ -114,9 +114,7 @@ Jobs are used to create jobs, which are then picked by What is important is that each job is run independently from each other. If you want to check whether the `.gitlab-ci.yml` of your project is valid, there is a -Lint tool under the page `/-/ci/lint` of your project namespace. You can also find -a "CI Lint" button to go to this page under **CI/CD ➔ Pipelines** and -**Pipelines ➔ Jobs** in your project. +[CI Lint tool](../lint.md) available in every project. For more information and a complete `.gitlab-ci.yml` syntax, please read [the reference documentation on `.gitlab-ci.yml`](../yaml/README.md). diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md index f13f1f1f36e..f68c502d828 100644 --- a/doc/ci/variables/predefined_variables.md +++ b/doc/ci/variables/predefined_variables.md @@ -73,7 +73,7 @@ Kubernetes-specific environment variables are detailed in the | `CI_KUBERNETES_ACTIVE` | 13.0 | all | Included with the value `true` only if the pipeline has a Kubernetes cluster available for deployments. Not included if no cluster is available. Can be used as an alternative to [`only:kubernetes`/`except:kubernetes`](../yaml/README.md#onlykubernetesexceptkubernetes) with [`rules:if`](../yaml/README.md#rulesif) | | `CI_MERGE_REQUEST_ASSIGNEES` | 11.9 | all | Comma-separated list of username(s) of assignee(s) for the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. | | `CI_MERGE_REQUEST_ID` | 11.6 | all | The instance-level ID of the merge request. Only available if [the pipelines are for merge requests](../merge_request_pipelines/index.md) and the merge request is created. | -| `CI_MERGE_REQUEST_IID` | 11.6 | all | The project-level IID of the merge request. Only available If [the pipelines are for merge requests](../merge_request_pipelines/index.md) and the merge request is created. | +| `CI_MERGE_REQUEST_IID` | 11.6 | all | The project-level IID (internal ID) of the merge request. Only available If [the pipelines are for merge requests](../merge_request_pipelines/index.md) and the merge request is created. | | `CI_MERGE_REQUEST_LABELS` | 11.9 | all | Comma-separated label names of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. | | `CI_MERGE_REQUEST_MILESTONE` | 11.9 | all | The milestone title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. | | `CI_MERGE_REQUEST_PROJECT_ID` | 11.6 | all | The ID of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. | @@ -93,8 +93,8 @@ Kubernetes-specific environment variables are detailed in the | `CI_NODE_TOTAL` | 11.5 | all | Total number of instances of this job running in parallel. If the job is not parallelized, this variable is set to `1`. | | `CI_PAGES_DOMAIN` | 11.8 | all | The configured domain that hosts GitLab Pages. | | `CI_PAGES_URL` | 11.8 | all | URL to GitLab Pages-built pages. Always belongs to a subdomain of `CI_PAGES_DOMAIN`. | -| `CI_PIPELINE_ID` | 8.10 | all | The unique ID of the current pipeline that GitLab CI/CD uses internally | -| `CI_PIPELINE_IID` | 11.0 | all | The unique ID of the current pipeline scoped to project | +| `CI_PIPELINE_ID` | 8.10 | all | The instance-level ID of the current pipeline. | +| `CI_PIPELINE_IID` | 11.0 | all | The project-level IID (internal ID) of the current pipeline. | | `CI_PIPELINE_SOURCE` | 10.0 | all | Indicates how the pipeline was triggered. Possible options are: `push`, `web`, `schedule`, `api`, `external`, `chat`, `webide`, `merge_request_event`, `external_pull_request_event`, `parent_pipeline`, [`trigger`, or `pipeline`](../triggers/README.md#authentication-tokens) (renamed to `cross_project_pipeline` since 13.0). For pipelines created before GitLab 9.5, this is displayed as `unknown`. | | `CI_PIPELINE_TRIGGERED` | all | all | The flag to indicate that job was [triggered](../triggers/README.md) | | `CI_PIPELINE_URL` | 11.1 | 0.5 | Pipeline details URL | diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 660e5782cf2..75f95988cee 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -304,6 +304,18 @@ To define your own `workflow: rules`, the configuration options currently availa If a pipeline attempts to run but matches no rule, it's dropped and doesn't run. +Use the example rules below exactly as written to allow pipelines that match the rule +to run. Add `when: never` to prevent pipelines that match the rule from running. See +the [common `if` clauses for `rules`](#common-if-clauses-for-rules) for more examples. + +| Example rules | Details | +|------------------------------------------------------|-----------------------------------------------------------| +| `if: '$CI_PIPELINE_SOURCE == "merge_request_event"'` | Control when merge request pipelines run. | +| `if: '$CI_PIPELINE_SOURCE == "push"'` | Control when both branch pipelines and tag pipelines run. | +| `if: $CI_COMMIT_TAG` | Control when tag pipelines run. | +| `if: $CI_COMMIT_BRANCH` | Control when branch pipelines run. | +| `if: '$CI_COMMIT_BRANCH && $CI_COMMIT_BEFORE_SHA != "0000000000000000000000000000000000000000"'` | Control when pipelines run for new branches that are created or pushed with no commits. See the [skip job if branch is empty](#skip-job-if-branch-is-empty) example for more details. | + For example, with the following configuration, pipelines run for all `push` events (changes to branches and new tags) as long as they *don't* have `-wip` in the commit message. Scheduled pipelines and merge request pipelines don't run, as there's no rule allowing them. @@ -339,14 +351,6 @@ As with `rules` defined in jobs, be careful not to use a configuration that allo merge request pipelines and branch pipelines to run at the same time, or you could have [duplicate pipelines](#differences-between-rules-and-onlyexcept). -Useful workflow rules clauses: - -| Clause | Details | -|----------------------------------------------------------------------------|---------------------------------------------------------| -| `if: '$CI_PIPELINE_SOURCE == "merge_request_event"'` | Allow or block merge request pipelines. | -| `if: '$CI_PIPELINE_SOURCE == "push"'` | Allow or block both branch pipelines and tag pipelines. | -| `if: '$CI_COMMIT_BEFORE_SHA == '0000000000000000000000000000000000000000'` | Allow or block pipeline creation when new branches are created or pushed with no commits. This will also skip tag and scheduled pipelines. See [common `rules:if` clauses](#common-if-clauses-for-rules) for examples on how to define these rules more strictly. | - #### `workflow:rules` templates > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217732) in GitLab 13.0. @@ -1365,27 +1369,17 @@ Other commonly used variables for `if` clauses: - `if: '$CUSTOM_VARIABLE == "value1"'`: If the custom variable `CUSTOM_VARIABLE` is exactly `value1`. -To avoid running pipelines when a branch is created without any changes, -check the value of `$CI_COMMIT_BEFORE_SHA`. It has a value of -`0000000000000000000000000000000000000000`: - -- In branches with no commits. -- In tag pipelines and scheduled pipelines. You should define rules very - narrowly if you don't want to skip these. - -To skip pipelines on all empty branches, but also tags and schedules: +##### Skip job if branch is empty -```yaml -rules: - - if: $CI_COMMIT_BEFORE_SHA == '0000000000000000000000000000000000000000' - when: never -``` +A branch has no commits if the value of`$CI_COMMIT_BEFORE_SHA` is +`0000000000000000000000000000000000000000`. You can use this value to +avoid running a job on branches with no commits. -To skip branch pipelines when the branch is empty: +To run a job only on branches with commits: ```yaml rules: - - if: $CI_COMMIT_BRANCH && $CI_COMMIT_BEFORE_SHA != '0000000000000000000000000000000000000000' + - if: '$CI_COMMIT_BRANCH && $CI_COMMIT_BEFORE_SHA != "0000000000000000000000000000000000000000"' ``` #### `rules:changes` @@ -2134,6 +2128,26 @@ build_job: artifacts: true ``` +Environment variables support for `project:`, `job:`, and `ref` was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202093) +in GitLab 13.3. This is under development, but it is ready for production use. It is deployed +behind the `ci_expand_names_for_cross_pipeline_artifacts` feature flag, which is **disabled by default**. +[GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md) +can enable it for your instance. + +For example: + +```yaml +build_job: + stage: build + script: + - ls -lhR + needs: + - project: $CI_PROJECT_PATH + job: $DEPENDENCY_JOB_NAME + ref: $CI_COMMIT_BRANCH + artifacts: true +``` + NOTE: **Note:** Downloading artifacts from jobs that are run in [`parallel:`](#parallel) is not supported. diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md index 9aaea677d00..51d0e33f67d 100644 --- a/doc/development/fe_guide/graphql.md +++ b/doc/development/fe_guide/graphql.md @@ -497,6 +497,7 @@ If we need to test how our component renders when results from the GraphQL API a designs: { loading, }, + }, }; wrapper = shallowMount(Index, { diff --git a/doc/development/filtering_by_label.md b/doc/development/filtering_by_label.md index ef92bd35985..9c1993fdf7f 100644 --- a/doc/development/filtering_by_label.md +++ b/doc/development/filtering_by_label.md @@ -1,3 +1,8 @@ +--- +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/#designated-technical-writers +--- # Filtering by label ## Introduction diff --git a/doc/development/i18n/externalization.md b/doc/development/i18n/externalization.md index f8c20bd06c9..980691c6b4f 100644 --- a/doc/development/i18n/externalization.md +++ b/doc/development/i18n/externalization.md @@ -196,7 +196,7 @@ For example use `%{created_at}` in Ruby but `%{createdAt}` in JavaScript. Make s // => 'This is <strong><script>alert('evil')</script></strong>' // OK: - sprintf(__('This is %{value}'), { value: `<strong>${escape(someDynamicValue)}</strong>`, false); + sprintf(__('This is %{value}'), { value: `<strong>${escape(someDynamicValue)}</strong>` }, false); // => 'This is <strong><script>alert('evil')</script></strong>' ``` diff --git a/doc/development/issuable-like-models.md b/doc/development/issuable-like-models.md index d252735dbd8..9029886c334 100644 --- a/doc/development/issuable-like-models.md +++ b/doc/development/issuable-like-models.md @@ -1,3 +1,8 @@ +--- +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/#designated-technical-writers +--- # Issuable-like Rails models utilities GitLab Rails codebase contains several models that hold common functionality and behave similarly to @@ -9,9 +14,9 @@ This guide accumulates guidelines on working with such Rails models. ## Important text fields -There are max length constraints for the most important text fields for `Issuable`s: +There are maximum length constraints for the most important text fields for issuables: -- `title`: 255 chars -- `title_html`: 800 chars +- `title`: 255 characters +- `title_html`: 800 characters - `description`: 1 megabyte - `description_html`: 5 megabytes diff --git a/doc/development/issue_types.md b/doc/development/issue_types.md index 028d42b27fc..416aa65b13f 100644 --- a/doc/development/issue_types.md +++ b/doc/development/issue_types.md @@ -1,3 +1,9 @@ +--- +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/#designated-technical-writers +--- + # Issue Types Sometimes when a new resource type is added it's not clear if it should be only an diff --git a/doc/operations/metrics/index.md b/doc/operations/metrics/index.md index 99b3a485002..6c6986bd6a3 100644 --- a/doc/operations/metrics/index.md +++ b/doc/operations/metrics/index.md @@ -4,7 +4,64 @@ group: APM 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/#designated-technical-writers --- -# Metrics dashboard for your CI/CD environment **(CORE)** +# Monitor your CI/CD environment's metrics **(CORE)** + +GitLab helps your team monitor the health and performance of your applications +and infrastructure by turning statistics and log files into charts and graphs +that are easy to understand, especially when time is short and decisions are +critical. For GitLab to display your information in charts, you must: + +1. **Instrument your application** - Collect accurate and complete measurements. + <I class="fa fa-youtube-play youtube" aria-hidden="true"></I> + For an overview, see [How to instrument Prometheus metrics in GitLab](https://www.youtube.com/watch?v=tuI2oJ3TTB4). +1. **Expose metrics for capture** - Make logs, metrics, and traces available for capture. +1. [**Configure Prometheus to gather metrics**](#configure-prometheus-to-gather-metrics) - + Deploy managed applications like Elasticsearch, Prometheus, and Jaeger to gather + the data you've exposed. +1. **GitLab collects metrics** - GitLab uses Prometheus to scrape the data you've + captured in your managed apps, and prepares the data for display. To learn more, read + [Collect and process metrics](#collect-and-process-metrics). +1. **Display charts in the GitLab user interface** - GitLab converts your metrics + into easy-to-read charts on a default dashboard. You can create as many custom charts + and custom dashboards as needed so your team has full insight into your + application's health. + +## Configure Prometheus to gather metrics + +You must connect a Prometheus instance to GitLab to collect metrics. How you configure +your Prometheus integration depends on where your apps are running: + +- **For manually-configured Prometheus** - + [Specify your Prometheus server](../../user/project/integrations/prometheus.md#manual-configuration-of-prometheus), + and define at least one environment. +- **For GitLab-managed Prometheus** - GitLab can + [deploy and manage Prometheus](../../user/project/integrations/prometheus.md#managed-prometheus-on-kubernetes) for you. + You must also complete a code deployment, as described in + [Deploy code with GitLab-managed Prometheus](#deploy-code-with-gitlab-managed-prometheus), + for the **Operations > Metrics** page to contain data. + +### Deploy code with GitLab-managed Prometheus + +For GitLab-managed Prometheus, you can set up [Auto DevOps](../../topics/autodevops/index.md) +to quickly create a deployment: + +1. Navigate to your project's **Operations > Kubernetes** page. +1. Ensure that, in addition to Prometheus, you also have Runner and Ingress + installed. +1. After installing Ingress, copy its endpoint. +1. Navigate to your project's **Settings > CI/CD** page. In the + **Auto DevOps** section, select a deployment strategy and save your changes. +1. On the same page, in the **Variables** section, add a variable named + `KUBE_INGRESS_BASE_DOMAIN` with the value of the Ingress endpoint you + copied previously. Leave the type as **Variable**. +1. Navigate to your project's **{rocket}** **CI/CD > Pipelines** page, and run a + pipeline on any branch. +1. When the pipeline has run successfully, graphs are available on the + **Operations > Metrics** page. + + + +## Collect and process metrics After [configuring Prometheus for a cluster](../../user/project/integrations/prometheus.md), GitLab attempts to retrieve performance metrics for any [environment](../../ci/environments/index.md) with @@ -16,7 +73,8 @@ the supported metrics and scan processes, see the [Prometheus Metrics Library documentation](../../user/project/integrations/prometheus_library/index.md). To view the metrics dashboard for an environment that has -[completed at least one deployment](#populate-your-metrics-dashboard): +To view the metrics dashboard for an environment that is +[configured to gather metrics](#configure-prometheus-to-gather-metrics): 1. *If the metrics dashboard is only visible to project members,* sign in to GitLab as a member of a project. Learn more about [metrics dashboard visibility](#metrics-dashboard-visibility). @@ -53,29 +111,6 @@ navigation bar contains: - **Metrics settings** - Configure the [settings for this dashboard](dashboards/index.md#manage-the-metrics-dashboard-settings). -## Populate your metrics dashboard - -After [configuring Prometheus for a cluster](../../user/project/integrations/prometheus.md), -you must also deploy code for the **Operations > Metrics** page -to contain data. Setting up [Auto DevOps](../../topics/autodevops/index.md) -helps quickly create a deployment: - -1. Navigate to your project's **Operations > Kubernetes** page. -1. Ensure that, in addition to Prometheus, you also have Runner and Ingress - installed. -1. After installing Ingress, copy its endpoint. -1. Navigate to your project's **Settings > CI/CD** page. In the - **Auto DevOps** section, select a deployment strategy and save your changes. -1. On the same page, in the **Variables** section, add a variable named - `KUBE_INGRESS_BASE_DOMAIN` with the value of the Ingress endpoint you - copied previously. Leave the type as **Variable**. -1. Navigate to your project's **{rocket}** **CI/CD > Pipelines** page, and run a - pipeline on any branch. -1. When the pipeline has run successfully, graphs are available on the - **Operations > Metrics** page. - - - ## Customize your metrics dashboard After creating your dashboard, you can customize it to meet your needs: diff --git a/doc/security/webhooks.md b/doc/security/webhooks.md index af9be499e80..3d7aa3026ab 100644 --- a/doc/security/webhooks.md +++ b/doc/security/webhooks.md @@ -5,7 +5,7 @@ type: concepts, reference, howto # Webhooks and insecure internal web services NOTE: **Note:** -On GitLab.com the [maximum number of webhooks](../user/gitlab_com/index.md#maximum-number-of-webhooks) per project is limited. +On GitLab.com, the [maximum number of webhooks and their size](../user/gitlab_com/index.md#webhooks) per project, and per group, is limited. If you have non-GitLab web services running on your GitLab server or within its local network, these may be vulnerable to exploitation via Webhooks. diff --git a/doc/user/admin_area/settings/visibility_and_access_controls.md b/doc/user/admin_area/settings/visibility_and_access_controls.md index 82718f0d2e4..e5c7947399d 100644 --- a/doc/user/admin_area/settings/visibility_and_access_controls.md +++ b/doc/user/admin_area/settings/visibility_and_access_controls.md @@ -67,7 +67,7 @@ To ensure only admin users can delete projects: 1. Check the **Default project deletion protection** checkbox. 1. Click **Save changes**. -## Default deletion adjourned period **(PREMIUM ONLY)** +## Default deletion delay **(PREMIUM ONLY)** > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6. @@ -88,7 +88,7 @@ To change this period: 1. Select the desired option. 1. Click **Save changes**. -### Override default deletion adjourned period +### Override default deletion delayed period Alternatively, projects that are marked for removal can be deleted immediately. To do so: diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md index 063e5f77adc..aa9e6715335 100644 --- a/doc/user/gitlab_com/index.md +++ b/doc/user/gitlab_com/index.md @@ -116,12 +116,13 @@ All our runners are deployed into Google Cloud Platform (GCP) - any IP based firewall can be configured by looking up all [IP address ranges or CIDR blocks for GCP](https://cloud.google.com/compute/docs/faq#where_can_i_find_product_name_short_ip_ranges). -## Maximum number of webhooks +## Webhooks A limit of: - 100 webhooks applies to projects. - 50 webhooks applies to groups. **(BRONZE ONLY)** +- Payload is limited to 25MB ## Shared Runners diff --git a/doc/user/group/index.md b/doc/user/group/index.md index cad74900f16..0d7d9bb2a7b 100644 --- a/doc/user/group/index.md +++ b/doc/user/group/index.md @@ -480,7 +480,7 @@ To remove a group and its contents: This action either: - Removes the group, and also queues a background job to delete all projects in that group. -- Since [GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/33257), on [Premium or Silver](https://about.gitlab.com/pricing/premium/) or higher tiers, marks a group for deletion. The deletion will happen 7 days later by default, but this can be changed in the [instance settings](../admin_area/settings/visibility_and_access_controls.md#default-deletion-adjourned-period-premium-only). +- Since [GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/33257), on [Premium or Silver](https://about.gitlab.com/pricing/premium/) or higher tiers, marks a group for deletion. The deletion will happen 7 days later by default, but this can be changed in the [instance settings](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay-premium-only). ### Restore a group **(PREMIUM)** @@ -660,7 +660,7 @@ Optionally, on [Premium or Silver](https://about.gitlab.com/pricing/) or higher you can configure the projects within a group to be deleted after a delayed interval. During this interval period, the projects will be in a read-only state and can be restored, if required. -The interval period defaults to 7 days, and can be modified by an admin in the [instance settings](../admin_area/settings/visibility_and_access_controls.md#default-deletion-adjourned-period-premium-only). +The interval period defaults to 7 days, and can be modified by an admin in the [instance settings](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay-premium-only). To enable delayed deletion of projects: diff --git a/doc/user/project/clusters/add_eks_clusters.md b/doc/user/project/clusters/add_eks_clusters.md index a1d957ce128..fbbc5050a1f 100644 --- a/doc/user/project/clusters/add_eks_clusters.md +++ b/doc/user/project/clusters/add_eks_clusters.md @@ -142,7 +142,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance: - **Kubernetes cluster name** - The name you wish to give the cluster. - **Environment scope** - The [associated environment](index.md#setting-the-environment-scope-premium) to this cluster. - **Kubernetes version** - The Kubernetes version to use. Currently the only version supported is 1.14. - - **Role name** - Select the **EKS IAM role** you created earlier to allow Amazon EKS + - **Service role** - Select the **EKS IAM role** you created earlier to allow Amazon EKS and the Kubernetes control plane to manage AWS resources on your behalf. NOTE: **Note:** diff --git a/doc/user/project/index.md b/doc/user/project/index.md index 908007239ac..154cc882397 100644 --- a/doc/user/project/index.md +++ b/doc/user/project/index.md @@ -193,7 +193,7 @@ To remove a project, first navigate to the home page for that project. ### Delayed removal **(PREMIUM)** By default, clicking to remove a project is followed by a seven day delay. Admins can restore the project during this period of time. -This delay [may be changed by an admin](../admin_area/settings/visibility_and_access_controls.md#default-deletion-adjourned-period-premium-only). +This delay [may be changed by an admin](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay-premium-only). Admins can view all projects pending deletion. If you're an administrator, go to the top navigation bar, click **Projects > Your projects**, and then select the **Removed projects** tab. From this tab an admin can restore any project. diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md index ac24e074b96..d8e8ab2fab7 100644 --- a/doc/user/project/integrations/webhooks.md +++ b/doc/user/project/integrations/webhooks.md @@ -35,7 +35,7 @@ Navigate to the webhooks page by going to your project's **Settings ➔ Webhooks**. NOTE: **Note:** -On GitLab.com, the [maximum number of webhooks](../../../user/gitlab_com/index.md#maximum-number-of-webhooks) per project, and per group, is limited. +On GitLab.com, the [maximum number of webhooks and their size](../../../user/gitlab_com/index.md#webhooks) per project, and per group, is limited. ## Version history diff --git a/doc/user/project/settings/index.md b/doc/user/project/settings/index.md index 2753add507e..77875c8faa7 100644 --- a/doc/user/project/settings/index.md +++ b/doc/user/project/settings/index.md @@ -237,7 +237,7 @@ This action: group admins can [configure](../../group/index.md#enabling-delayed-project-removal-premium) projects within a group to be deleted after a delayed period. When enabled, actual deletion happens after number of days -specified in [instance settings](../../admin_area/settings/visibility_and_access_controls.md#default-deletion-adjourned-period-premium-only). +specified in [instance settings](../../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay-premium-only). CAUTION: **Warning:** The default behavior of [Delayed Project deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6 was changed to |
