From a5f4bba440d7f9ea47046a0a561d49adf0a1e6d4 Mon Sep 17 00:00:00 2001 From: GitLab Bot Date: Wed, 16 Jun 2021 18:25:58 +0000 Subject: Add latest changes from gitlab-org/gitlab@14-0-stable-ee --- doc/user/project/badges.md | 31 +- doc/user/project/bulk_editing.md | 1 + doc/user/project/canary_deployments.md | 4 +- doc/user/project/clusters/add_eks_clusters.md | 13 +- doc/user/project/clusters/add_gke_clusters.md | 12 +- doc/user/project/clusters/add_remove_clusters.md | 62 +-- doc/user/project/clusters/index.md | 47 +-- doc/user/project/clusters/kubernetes_pod_logs.md | 24 +- .../protect/container_host_security/index.md | 6 +- .../container_host_security/quick_start_guide.md | 24 +- .../protect/container_network_security/index.md | 6 +- .../quick_start_guide.md | 34 +- doc/user/project/clusters/protect/index.md | 5 +- .../guide_waf_ingress_disabled_settings_v12_10.png | Bin 51416 -> 0 bytes .../img/guide_waf_ingress_installation_v12_10.png | Bin 44243 -> 0 bytes .../img/guide_waf_ingress_save_changes_v12_10.png | Bin 54688 -> 0 bytes .../protect/web_application_firewall/index.md | 103 ----- .../web_application_firewall/quick_start_guide.md | 265 ------------- doc/user/project/clusters/runbooks/index.md | 99 ++++- doc/user/project/clusters/serverless/index.md | 74 ++-- doc/user/project/deploy_boards.md | 2 +- doc/user/project/deploy_keys/index.md | 2 +- doc/user/project/deploy_tokens/index.md | 2 +- doc/user/project/description_templates.md | 39 +- doc/user/project/file_lock.md | 8 +- doc/user/project/highlighting.md | 2 +- ...owners_approval_new_protected_branch_v13_10.png | Bin 30238 -> 0 bytes ...ode_owners_approval_protected_branch_v13_10.png | Bin 17263 -> 0 bytes doc/user/project/import/bitbucket.md | 2 +- doc/user/project/import/bitbucket_server.md | 2 +- doc/user/project/import/clearcase.md | 2 +- doc/user/project/import/cvs.md | 2 +- doc/user/project/import/fogbugz.md | 2 +- doc/user/project/import/gemnasium.md | 1 + doc/user/project/import/gitea.md | 2 +- doc/user/project/import/github.md | 2 +- doc/user/project/import/gitlab_com.md | 2 +- doc/user/project/import/index.md | 2 +- doc/user/project/import/manifest.md | 2 +- doc/user/project/import/perforce.md | 2 +- doc/user/project/import/phabricator.md | 2 +- doc/user/project/import/repo_by_url.md | 2 +- doc/user/project/import/svn.md | 6 +- doc/user/project/import/tfvc.md | 6 +- doc/user/project/index.md | 4 +- .../integrations/gitlab_slack_application.md | 2 +- doc/user/project/integrations/hipchat.md | 7 - doc/user/project/integrations/index.md | 2 +- doc/user/project/integrations/jira.md | 1 + .../integrations/jira_cloud_configuration.md | 1 + doc/user/project/integrations/jira_integrations.md | 1 + .../integrations/jira_server_configuration.md | 1 + .../integrations/mattermost_slash_commands.md | 6 +- doc/user/project/integrations/overview.md | 15 +- doc/user/project/integrations/prometheus.md | 144 +------ .../integrations/prometheus_library/kubernetes.md | 2 +- .../prometheus_library/nginx_ingress.md | 22 -- .../prometheus_library/nginx_ingress_vts.md | 22 -- .../project/integrations/services_templates.md | 68 +--- doc/user/project/integrations/webex_teams.md | 3 +- doc/user/project/integrations/webhooks.md | 14 +- doc/user/project/issue_board.md | 199 ++++++---- doc/user/project/issues/confidential_issues.md | 8 +- doc/user/project/issues/csv_export.md | 105 +++--- doc/user/project/issues/csv_import.md | 2 +- doc/user/project/issues/design_management.md | 7 +- doc/user/project/issues/due_dates.md | 24 +- .../issues/img/issue_type_change_v13_12.png | Bin 0 -> 52414 bytes doc/user/project/issues/issue_data_and_actions.md | 2 +- doc/user/project/issues/managing_issues.md | 24 +- doc/user/project/labels.md | 2 +- .../img/access_requests_management_v13_9.png | Bin 24246 -> 0 bytes .../members/img/add_user_email_accept_v13_9.png | Bin 21877 -> 0 bytes .../members/img/add_user_email_ready_v13_8.png | Bin 28850 -> 0 bytes .../members/img/add_user_email_search_v13_8.png | Bin 29293 -> 0 bytes .../members/img/withdraw_access_request_button.png | Bin 28154 -> 0 bytes doc/user/project/members/index.md | 203 +++++----- .../project/members/share_project_with_groups.md | 2 +- .../merge_requests/accessibility_testing.md | 12 +- .../project/merge_requests/allow_collaboration.md | 50 ++- doc/user/project/merge_requests/approvals/index.md | 32 +- doc/user/project/merge_requests/approvals/rules.md | 6 +- .../project/merge_requests/approvals/settings.md | 2 +- .../authorization_for_merge_requests.md | 16 +- .../merge_requests/browser_performance_testing.md | 31 +- doc/user/project/merge_requests/changes.md | 60 ++- .../project/merge_requests/cherry_pick_changes.md | 25 +- doc/user/project/merge_requests/code_quality.md | 19 +- doc/user/project/merge_requests/commits.md | 28 ++ .../merge_requests/creating_merge_requests.md | 3 +- doc/user/project/merge_requests/getting_started.md | 58 +-- .../merge_requests/img/allow_collaboration.png | Bin 10806 -> 0 bytes .../img/allow_collaboration_after_save.png | Bin 5410 -> 0 bytes .../img/code_quality_mr_diff_report_v14.png | Bin 0 -> 54803 bytes .../merge_requests/img/commit-button_v13_12.png | Bin 0 -> 8834 bytes .../merge_requests/img/conflict_ui_v14_0.png | Bin 0 -> 8371 bytes .../merge_requests/img/merge_request_pipeline.png | Bin 0 -> 31026 bytes .../img/project_merge_requests_list_view_v13_5.png | Bin 0 -> 87738 bytes .../img/reviewer_approval_rules_form_v13_8.png | Bin 42245 -> 0 bytes .../img/reviewer_approval_rules_sidebar_v13_8.png | Bin 38840 -> 0 bytes .../img/status_checks_branches_selector_v14_0.png | Bin 0 -> 5460 bytes .../img/status_checks_create_form_v14_0.png | Bin 0 -> 11913 bytes .../img/status_checks_delete_modal_v14_0.png | Bin 0 -> 5662 bytes .../img/status_checks_list_view_v14_0.png | Bin 0 -> 15958 bytes .../img/status_checks_update_form_v14_0.png | Bin 0 -> 13348 bytes doc/user/project/merge_requests/index.md | 85 ++++- .../merge_requests/load_performance_testing.md | 10 +- .../merge_requests/merge_request_approvals.md | 1 + .../merge_requests/merge_request_dependencies.md | 2 +- .../merge_requests/merge_when_pipeline_succeeds.md | 2 +- .../project/merge_requests/resolve_conflicts.md | 4 +- .../reviewing_and_managing_merge_requests.md | 1 + .../reviews/img/merge_request_pipeline.png | Bin 31026 -> 0 bytes .../img/project_merge_requests_list_view_v13_5.png | Bin 87738 -> 0 bytes .../img/reviewer_approval_rules_form_v13_8.png | Bin 0 -> 42245 bytes .../img/reviewer_approval_rules_sidebar_v13_8.png | Bin 0 -> 38840 bytes doc/user/project/merge_requests/reviews/index.md | 143 +++---- .../project/merge_requests/reviews/suggestions.md | 4 + .../project/merge_requests/squash_and_merge.md | 2 +- doc/user/project/merge_requests/status_checks.md | 179 +++++++++ .../merge_requests/test_coverage_visualization.md | 84 +++-- .../testing_and_reports_in_merge_requests.md | 2 +- doc/user/project/merge_requests/versions.md | 2 +- doc/user/project/merge_requests/widgets.md | 64 ++++ .../work_in_progress_merge_requests.md | 1 + doc/user/project/milestones/index.md | 4 +- doc/user/project/new_ci_build_permissions_model.md | 1 + .../dns_concepts.md | 2 +- .../custom_domains_ssl_tls_certification/index.md | 4 +- .../lets_encrypt_integration.md | 4 +- .../ssl_tls_concepts.md | 2 +- .../pages/getting_started/pages_ci_cd_template.md | 4 +- .../getting_started/pages_forked_sample_project.md | 2 +- .../pages/getting_started/pages_from_scratch.md | 2 +- .../getting_started/pages_new_project_template.md | 3 +- doc/user/project/pages/getting_started_part_one.md | 2 +- doc/user/project/pages/index.md | 2 +- doc/user/project/pages/introduction.md | 4 +- .../project/pages/lets_encrypt_for_gitlab_pages.md | 2 +- doc/user/project/pages/pages_access_control.md | 2 +- doc/user/project/pages/redirects.md | 2 +- doc/user/project/protected_branches.md | 40 +- doc/user/project/protected_tags.md | 2 +- doc/user/project/quick_actions.md | 1 - doc/user/project/releases/index.md | 17 +- doc/user/project/repository/branches/default.md | 3 +- .../repository/img/download_source_code.png | Bin 19681 -> 0 bytes .../repository/img/file_ext_icons_repo_v12_10.png | Bin 73624 -> 0 bytes doc/user/project/repository/index.md | 418 +++++++++------------ .../project/repository/jupyter_notebooks/index.md | 9 +- .../project/repository/repository_mirroring.md | 46 +-- doc/user/project/repository/web_editor.md | 8 +- doc/user/project/settings/import_export.md | 12 +- doc/user/project/settings/index.md | 94 ++++- doc/user/project/settings/project_access_tokens.md | 2 + doc/user/project/time_tracking.md | 6 +- doc/user/project/web_ide/index.md | 26 +- doc/user/project/wiki/img/content_editor_v14.0.png | Bin 0 -> 13771 bytes .../wiki/img/use_new_editor_button_v14.0.png | Bin 0 -> 16719 bytes doc/user/project/wiki/index.md | 82 ++-- doc/user/project/working_with_projects.md | 25 +- 161 files changed, 1656 insertions(+), 1902 deletions(-) delete mode 100644 doc/user/project/clusters/protect/web_application_firewall/img/guide_waf_ingress_disabled_settings_v12_10.png delete mode 100644 doc/user/project/clusters/protect/web_application_firewall/img/guide_waf_ingress_installation_v12_10.png delete mode 100644 doc/user/project/clusters/protect/web_application_firewall/img/guide_waf_ingress_save_changes_v12_10.png delete mode 100644 doc/user/project/clusters/protect/web_application_firewall/index.md delete mode 100644 doc/user/project/clusters/protect/web_application_firewall/quick_start_guide.md delete mode 100644 doc/user/project/img/code_owners_approval_new_protected_branch_v13_10.png delete mode 100644 doc/user/project/img/code_owners_approval_protected_branch_v13_10.png delete mode 100644 doc/user/project/integrations/hipchat.md create mode 100644 doc/user/project/issues/img/issue_type_change_v13_12.png delete mode 100644 doc/user/project/members/img/access_requests_management_v13_9.png delete mode 100644 doc/user/project/members/img/add_user_email_accept_v13_9.png delete mode 100644 doc/user/project/members/img/add_user_email_ready_v13_8.png delete mode 100644 doc/user/project/members/img/add_user_email_search_v13_8.png delete mode 100644 doc/user/project/members/img/withdraw_access_request_button.png create mode 100644 doc/user/project/merge_requests/commits.md delete mode 100644 doc/user/project/merge_requests/img/allow_collaboration.png delete mode 100644 doc/user/project/merge_requests/img/allow_collaboration_after_save.png create mode 100644 doc/user/project/merge_requests/img/code_quality_mr_diff_report_v14.png create mode 100644 doc/user/project/merge_requests/img/commit-button_v13_12.png create mode 100644 doc/user/project/merge_requests/img/conflict_ui_v14_0.png create mode 100644 doc/user/project/merge_requests/img/merge_request_pipeline.png create mode 100644 doc/user/project/merge_requests/img/project_merge_requests_list_view_v13_5.png delete mode 100644 doc/user/project/merge_requests/img/reviewer_approval_rules_form_v13_8.png delete mode 100644 doc/user/project/merge_requests/img/reviewer_approval_rules_sidebar_v13_8.png create mode 100644 doc/user/project/merge_requests/img/status_checks_branches_selector_v14_0.png create mode 100644 doc/user/project/merge_requests/img/status_checks_create_form_v14_0.png create mode 100644 doc/user/project/merge_requests/img/status_checks_delete_modal_v14_0.png create mode 100644 doc/user/project/merge_requests/img/status_checks_list_view_v14_0.png create mode 100644 doc/user/project/merge_requests/img/status_checks_update_form_v14_0.png delete mode 100644 doc/user/project/merge_requests/reviews/img/merge_request_pipeline.png delete mode 100644 doc/user/project/merge_requests/reviews/img/project_merge_requests_list_view_v13_5.png create mode 100644 doc/user/project/merge_requests/reviews/img/reviewer_approval_rules_form_v13_8.png create mode 100644 doc/user/project/merge_requests/reviews/img/reviewer_approval_rules_sidebar_v13_8.png create mode 100644 doc/user/project/merge_requests/status_checks.md create mode 100644 doc/user/project/merge_requests/widgets.md delete mode 100644 doc/user/project/repository/img/download_source_code.png delete mode 100644 doc/user/project/repository/img/file_ext_icons_repo_v12_10.png create mode 100644 doc/user/project/wiki/img/content_editor_v14.0.png create mode 100644 doc/user/project/wiki/img/use_new_editor_button_v14.0.png (limited to 'doc/user/project') diff --git a/doc/user/project/badges.md b/doc/user/project/badges.md index 1834bc20aee..64a375c6a1d 100644 --- a/doc/user/project/badges.md +++ b/doc/user/project/badges.md @@ -15,7 +15,7 @@ points to. Examples for badges can be the [pipeline status](../../ci/pipelines/s [test coverage](../../ci/pipelines/settings.md#test-coverage-report-badge), or ways to contact the project maintainers. -![Badges on Project overview page](img/project_overview_badges_v13_10.png) +![Badges on Project information page](img/project_overview_badges_v13_10.png) ## Project badges @@ -90,6 +90,35 @@ default branch or commit SHA when the project is configured to have a private repository. This is by design, as badges are intended to be used publicly. Avoid using these placeholders if the information is sensitive. +## Use custom badge images + +Use custom badge images in a project or a group if you want to use badges other than the default +ones. + +Prerequisites: + +- A valid URL that points directly to the desired image for the badge. + If the image is located in a GitLab repository, use the raw link to the image. + +Using placeholders, here is an example badge image URL referring to a raw image at the root of a repository: + +```plaintext +https://gitlab.example.com//-/raw//my-image.svg +``` + +To add a new badge to a group or project with a custom image: + +1. Go to your group or project and select **Settings > General**. +1. Expand **Badges**. +1. Under **Name**, enter the name for the badge. +1. Under **Link**, enter the URL that the badge should point to. +1. Under **Badge image URL**, enter the URL that points directly to the custom image that should be + displayed. +1. Select **Add badge**. + +To learn how to use custom images generated via a pipeline, see our documentation on +[accessing the latest job artifacts by URL](../../ci/pipelines/job_artifacts.md#access-the-latest-job-artifacts-by-url). + ## API You can also configure badges via the GitLab API. As in the settings, there is diff --git a/doc/user/project/bulk_editing.md b/doc/user/project/bulk_editing.md index d9e268251b7..1ecfb3b7292 100644 --- a/doc/user/project/bulk_editing.md +++ b/doc/user/project/bulk_editing.md @@ -1,5 +1,6 @@ --- redirect_to: 'issues/managing_issues.md' +remove_date: '2021-08-12' --- This document was moved to [another location](issues/managing_issues.md). diff --git a/doc/user/project/canary_deployments.md b/doc/user/project/canary_deployments.md index f7394093a3a..c3900d33cb8 100644 --- a/doc/user/project/canary_deployments.md +++ b/doc/user/project/canary_deployments.md @@ -91,7 +91,7 @@ Here's an example setup flow from scratch: 1. Prepare an [Auto DevOps-enabled](../../topics/autodevops/index.md) project. 1. Set up a [Kubernetes Cluster](../../user/project/clusters/index.md) in your project. -1. Install [Ingress](../../user/clusters/applications.md#ingress) as a GitLab Managed App. +1. Install [NGINX Ingress](https://github.com/kubernetes/ingress-nginx/tree/master/charts/ingress-nginx) in your cluster. 1. Set up [the base domain](../../user/project/clusters/index.md#base-domain) based on the Ingress Endpoint assigned above. 1. Check if [`v2.0.0+` of `auto-deploy-image` is used in your Auto DevOps pipelines](../../topics/autodevops/upgrading_auto_deploy_dependencies.md#verify-dependency-versions). @@ -116,7 +116,7 @@ or by sending requests to the [GraphQL API](../../api/graphql/getting_started.md To use your [Deploy Board](../../user/project/deploy_boards.md): -1. Navigate to **Operations > Environments** for your project. +1. Navigate to **Deployments > Environments** for your project. 1. Set the new weight with the dropdown on the right side. 1. Confirm your selection. diff --git a/doc/user/project/clusters/add_eks_clusters.md b/doc/user/project/clusters/add_eks_clusters.md index c0fb8f5848f..58bdb3d698f 100644 --- a/doc/user/project/clusters/add_eks_clusters.md +++ b/doc/user/project/clusters/add_eks_clusters.md @@ -74,10 +74,10 @@ Instance profiles dynamically retrieve temporary credentials from AWS when neede To create and add a new Kubernetes cluster to your project, group, or instance: 1. Navigate to your: - - Project's **Operations > Kubernetes** page, for a project-level cluster. + - Project's **Infrastructure > Kubernetes clusters** page, for a project-level cluster. - Group's **Kubernetes** page, for a group-level cluster. - **Admin Area > Kubernetes**, for an instance-level cluster. -1. Click **Add Kubernetes cluster**. +1. Click **Integrate with a cluster certificate**. 1. Under the **Create new cluster** tab, click **Amazon EKS** to display an `Account ID` and `External ID` needed for later steps. 1. In the [IAM Management Console](https://console.aws.amazon.com/iam/home), create an IAM policy: @@ -184,13 +184,10 @@ To create and add a new Kubernetes cluster to your project, group, or instance: See the [Managed clusters section](index.md#gitlab-managed-clusters) for more information. 1. Finally, click the **Create Kubernetes cluster** button. -After about 10 minutes, your cluster is ready to go. You can now proceed -to install some [pre-defined applications](index.md#installing-applications). +After about 10 minutes, your cluster is ready to go. NOTE: -You must add your AWS external ID to the -[IAM Role in the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-xaccount) -to manage your cluster using `kubectl`. +If you have [installed and configured](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html#get-started-kubectl) `kubectl` and you would like to manage your cluster with it, you must add your AWS external ID in the AWS configuration. For more information on how to configure AWS CLI, see [using an IAM role in the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-xaccount). ### Cluster creation flow @@ -292,7 +289,7 @@ you've assigned the role the correct permissions. ### Key Pairs are not loaded -GitLab loads the key pairs from the **Cluster Region** specified. Ensure that key pair exists in that region. +GitLab loads the key pairs from the **Cluster Region** specified. Ensure that key pair exists in that region. #### `ROLLBACK_FAILED` during cluster creation diff --git a/doc/user/project/clusters/add_gke_clusters.md b/doc/user/project/clusters/add_gke_clusters.md index af3a17dc60c..9f0e5603785 100644 --- a/doc/user/project/clusters/add_gke_clusters.md +++ b/doc/user/project/clusters/add_gke_clusters.md @@ -46,10 +46,11 @@ Note the following: To create and add a new Kubernetes cluster to your project, group, or instance: 1. Navigate to your: - - Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster. + - Project's **{cloud-gear}** **Infrastructure > Kubernetes clusters** page, for a project-level + cluster. - Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster. - **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster. -1. Click **Add Kubernetes cluster**. +1. Click **Integrate with a cluster certificate**. 1. Under the **Create new cluster** tab, click **Google GKE**. 1. Connect your Google account if you haven't done already by clicking the **Sign in with Google** button. @@ -70,8 +71,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance: See the [Managed clusters section](index.md#gitlab-managed-clusters) for more information. 1. Finally, click the **Create Kubernetes cluster** button. -After a couple of minutes, your cluster is ready. You can now proceed -to install some [pre-defined applications](index.md#installing-applications). +After a couple of minutes, your cluster is ready. ### Cloud Run for Anthos @@ -79,8 +79,8 @@ to install some [pre-defined applications](index.md#installing-applications). You can choose to use Cloud Run for Anthos in place of installing Knative and Istio separately after the cluster has been created. This means that Cloud Run -(Knative), Istio, and HTTP Load Balancing are enabled on the cluster at -create time and cannot be [installed or uninstalled](../../clusters/applications.md) separately. +(Knative), Istio, and HTTP Load Balancing are enabled on the cluster +from the start, and cannot be installed or uninstalled. ## Existing GKE cluster diff --git a/doc/user/project/clusters/add_remove_clusters.md b/doc/user/project/clusters/add_remove_clusters.md index 1b4b4f38f4b..2ecbc4a2ff5 100644 --- a/doc/user/project/clusters/add_remove_clusters.md +++ b/doc/user/project/clusters/add_remove_clusters.md @@ -4,7 +4,16 @@ group: Configure 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 --- -# Adding and removing Kubernetes clusters **(FREE)** +# Add a cluster using cluster certificates **(FREE)** + +> [Deprecated](https://gitlab.com/groups/gitlab-org/-/epics/6049) in GitLab 14.0. + +WARNING: +Creating a new cluster or adding an existing cluster to GitLab through the certificate-based method +is deprecated and no longer recommended. Kubernetes cluster, similar to any other +infrastructure, should be created, updated, and maintained using [Infrastructure as Code](../../infrastructure/index.md). +GitLab is developing a built-in capability to create clusters with Terraform. +You can follow along in this [epic](https://gitlab.com/groups/gitlab-org/-/epics/6049). GitLab offers integrated cluster creation for the following Kubernetes providers: @@ -35,9 +44,9 @@ Before [adding a Kubernetes cluster](#create-new-cluster) using GitLab, you need - A [self-managed installation](https://about.gitlab.com/pricing/#self-managed) with GitLab version 12.5 or later. This ensures the GitLab UI can be used for cluster creation. - The following GitLab access: - - [Maintainer access to a project](../../permissions.md#project-members-permissions) for a + - [Maintainer role for a project](../../permissions.md#project-members-permissions) for a project-level cluster. - - [Maintainer access to a group](../../permissions.md#group-members-permissions) for a + - [Maintainer role for a group](../../permissions.md#group-members-permissions) for a group-level cluster. - [Admin Area access](../../admin_area/index.md) for a self-managed instance-level cluster. **(FREE SELF)** @@ -52,16 +61,10 @@ When creating a cluster in GitLab, you are asked if you would like to create eit cluster, which is the GitLab default and recommended option. - An [Attribute-based access control (ABAC)](https://kubernetes.io/docs/reference/access-authn-authz/abac/) cluster. -GitLab creates the necessary service accounts and privileges to install and run -[GitLab managed applications](index.md#installing-applications). When GitLab creates the cluster, +When GitLab creates the cluster, a `gitlab` service account with `cluster-admin` privileges is created in the `default` namespace to manage the newly created cluster. -The first time you install an application into your cluster, the `tiller` service -account is created with `cluster-admin` privileges in the -`gitlab-managed-apps` namespace. This service account is used by Helm to -install and run [GitLab managed applications](index.md#installing-applications). - Helm also creates additional service accounts and other resources for each installed application. Consult the documentation of the Helm charts for each application for details. @@ -132,11 +135,8 @@ If you don't want to use a runner in privileged mode, either: - Use shared runners on GitLab.com. They don't have this security issue. - Set up your own runners using the configuration described at - [shared runners](../../gitlab_com/index.md#shared-runners). This involves: - 1. Making sure that you don't have it installed via - [the applications](index.md#installing-applications). - 1. Installing a runner - [using `docker+machine`](https://docs.gitlab.com/runner/executors/docker_machine.html). + [shared runners](../../gitlab_com/index.md#shared-runners) using + [`docker+machine`](https://docs.gitlab.com/runner/executors/docker_machine.html). ## Create new cluster @@ -144,36 +144,38 @@ New clusters can be created using GitLab on Google Kubernetes Engine (GKE) or Amazon Elastic Kubernetes Service (EKS) at the project, group, or instance level: 1. Navigate to your: - - Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster. + - Project's **{cloud-gear}** **Infrastructure > Kubernetes clusters** page, for a project-level + cluster. - Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster. - **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster. -1. Click **Add Kubernetes cluster**. +1. Click **Integrate with a cluster certificate**. 1. Click the **Create new cluster** tab. 1. Click either **Amazon EKS** or **Google GKE**, and follow the instructions for your desired service: - [Amazon EKS](add_eks_clusters.md#new-eks-cluster). - [Google GKE](add_gke_clusters.md#creating-the-cluster-on-gke). -After creating a cluster, you can install runners for it as described in -[GitLab Managed Apps](../../clusters/applications.md). +After creating a cluster, you can [install runners](https://docs.gitlab.com/runner/install/kubernetes.html), +add a [cluster management project](../../clusters/management_project.md), +configure [Auto DevOps](../../../topics/autodevops/index.md), +or start [deploying right away](index.md#deploying-to-a-kubernetes-cluster). ## Add existing cluster If you have an existing Kubernetes cluster, you can add it to a project, group, -or instance. - -Kubernetes integration isn't supported for arm64 clusters. See the issue -[Helm Tiller fails to install on arm64 cluster](https://gitlab.com/gitlab-org/gitlab/-/issues/29838) -for details. +or instance, and [install runners](https://docs.gitlab.com/runner/install/kubernetes.html) +on it (the cluster does not need to be added to GitLab first). -After adding an existing cluster, you can install runners for it as described in -[GitLab Managed Apps](../../clusters/applications.md). +After adding a cluster, you can add a [cluster management project](../../clusters/management_project.md), +configure [Auto DevOps](../../../topics/autodevops/index.md), +or start [deploying right away](index.md#deploying-to-a-kubernetes-cluster). ### Existing Kubernetes cluster To add a Kubernetes cluster to your project, group, or instance: 1. Navigate to your: - 1. Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster. + 1. Project's **{cloud-gear}** **Infrastructure > Kubernetes clusters** page, for a project-level + cluster. 1. Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster. 1. **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster. 1. Click **Add Kubernetes cluster**. @@ -316,8 +318,7 @@ To add a Kubernetes cluster to your project, group, or instance: 1. Finally, click the **Create Kubernetes cluster** button. -After a couple of minutes, your cluster is ready. You can now proceed -to install some [pre-defined applications](index.md#installing-applications). +After a couple of minutes, your cluster is ready. #### Disable Role-Based Access Control (RBAC) (optional) @@ -351,7 +352,8 @@ The Kubernetes cluster integration enables after you have successfully either cr a new cluster or added an existing one. To disable Kubernetes cluster integration: 1. Navigate to your: - - Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster. + - Project's **{cloud-gear}** **Infrastructure > Kubernetes clusters** page, for a project-level + cluster. - Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster. - **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster. 1. Click on the name of the cluster. diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md index c2d06e0a22c..97296d22dd9 100644 --- a/doc/user/project/clusters/index.md +++ b/doc/user/project/clusters/index.md @@ -31,7 +31,7 @@ Besides integration at the project level, Kubernetes clusters can also be integrated at the [group level](../../group/clusters/index.md) or [GitLab instance level](../../instance/clusters/index.md). -To view your project level Kubernetes clusters, navigate to **Operations > Kubernetes** +To view your project level Kubernetes clusters, navigate to **Infrastructure > Kubernetes** from your project. On this page, you can [add a new cluster](#adding-and-removing-clusters) and view information about your existing clusters, such as: @@ -61,6 +61,9 @@ Kubernetes version to any supported version at any time: Some GitLab features may support versions outside the range provided here. +NOTE: +[GKE Cluster creation](add_remove_clusters.md#create-new-cluster) by GitLab is currently not supported for Kubernetes 1.19+. For these versions you can create the cluster through GCP, then [Add existing cluster](add_remove_clusters.md#add-existing-cluster). See [the related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/331922) for more information. + ### Adding and removing clusters See [Adding and removing Kubernetes clusters](add_remove_clusters.md) for details on how @@ -169,14 +172,9 @@ for your deployment jobs to use. Otherwise, a namespace is created for you. #### Important notes -Note the following with GitLab and clusters: - -- If you [install applications](#installing-applications) on your cluster, GitLab will - create the resources required to run these even if you have chosen to manage your own - cluster. -- Be aware that manually managing resources that have been created by GitLab, like - namespaces and service accounts, can cause unexpected errors. If this occurs, try - [clearing the cluster cache](#clearing-the-cluster-cache). +Be aware that manually managing resources that have been created by GitLab, like +namespaces and service accounts, can cause unexpected errors. If this occurs, try +[clearing the cluster cache](#clearing-the-cluster-cache). #### Clearing the cluster cache @@ -189,7 +187,7 @@ your cluster. This can cause deployment jobs to fail. To clear the cache: -1. Navigate to your project's **Operations > Kubernetes** page, and select your cluster. +1. Navigate to your project's **Infrastructure > Kubernetes** page, and select your cluster. 1. Expand the **Advanced settings** section. 1. Click **Clear cluster cache**. @@ -197,19 +195,15 @@ To clear the cache: > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24580) in GitLab 11.8. -You do not need to specify a base domain on cluster settings when using GitLab Serverless. The domain in that case -is specified as part of the Knative installation. See [Installing Applications](#installing-applications). - Specifying a base domain automatically sets `KUBE_INGRESS_BASE_DOMAIN` as an deployment variable. If you are using [Auto DevOps](../../../topics/autodevops/index.md), this domain is used for the different stages. For example, Auto Review Apps and Auto Deploy. The domain should have a wildcard DNS configured to the Ingress IP address. -After Ingress has been installed (see [Installing Applications](#installing-applications)), -you can either: +You can either: - Create an `A` record that points to the Ingress IP address with your domain provider. -- Enter a wildcard DNS address using a service such as nip.io or xip.io. For example, `192.168.1.1.xip.io`. +- Enter a wildcard DNS address using a service such as `nip.io` or `xip.io`. For example, `192.168.1.1.xip.io`. To determine the external Ingress IP address, or external Ingress hostname: @@ -259,13 +253,11 @@ This list provides a generic solution, and some GitLab-specific approaches: If you see a trailing `%` on some Kubernetes versions, do not include it. -## Installing applications +## Cluster management project -GitLab can install and manage some applications like Helm, GitLab Runner, Ingress, -Prometheus, and so on, in your project-level cluster. For more information on -installing, upgrading, uninstalling, and troubleshooting applications for -your project cluster, see -[GitLab Managed Apps](../../clusters/applications.md). +Attach a [Cluster management project](../../clusters/management_project.md) +to your cluster to manage shared resources requiring `cluster-admin` privileges for +installation, such as an Ingress controller. ## Auto DevOps @@ -351,16 +343,17 @@ You can customize the deployment namespace in a few ways: When you customize the namespace, existing environments remain linked to their current namespaces until you [clear the cluster cache](#clearing-the-cluster-cache). -WARNING: +#### Protecting credentials + By default, anyone who can create a deployment job can access any CI/CD variable in an environment's deployment job. This includes `KUBECONFIG`, which gives access to any secret available to the associated service account in your cluster. To keep your production credentials safe, consider using [protected environments](../../../ci/environments/protected_environments.md), -combined with either +combined with *one* of the following: -- a GitLab-managed cluster and namespace per environment, -- *or*, an environment-scoped cluster per protected environment. The same cluster +- A GitLab-managed cluster and namespace per environment. +- An environment-scoped cluster per protected environment. The same cluster can be added multiple times with multiple restricted service accounts. ### Integrations @@ -453,6 +446,6 @@ Automatically detect and monitor Kubernetes metrics. Automatic monitoring of > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4701) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.6. > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/208224) to GitLab Free in 13.2. -When [Prometheus is deployed](#installing-applications), GitLab monitors the cluster's health. At the top of the cluster settings page, CPU and Memory utilization is displayed, along with the total amount available. Keeping an eye on cluster resources can be important, if the cluster runs out of memory pods may be shutdown or fail to start. +When [the Prometheus cluster integration is enabled](../../clusters/integrations.md#prometheus-cluster-integration), GitLab monitors the cluster's health. At the top of the cluster settings page, CPU and Memory utilization is displayed, along with the total amount available. Keeping an eye on cluster resources can be important, if the cluster runs out of memory pods may be shutdown or fail to start. ![Cluster Monitoring](img/k8s_cluster_monitoring.png) diff --git a/doc/user/project/clusters/kubernetes_pod_logs.md b/doc/user/project/clusters/kubernetes_pod_logs.md index bafb7d472c6..7a9c7eb423d 100644 --- a/doc/user/project/clusters/kubernetes_pod_logs.md +++ b/doc/user/project/clusters/kubernetes_pod_logs.md @@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/4752) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.0. > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26383) to [GitLab Free](https://about.gitlab.com/pricing/) 12.9. -GitLab makes it easy to view the logs of running pods or managed applications in +GitLab makes it easy to view the logs of running pods in [connected Kubernetes clusters](index.md). By displaying the logs directly in GitLab in the **Log Explorer**, developers can avoid managing console tools or jumping to a different interface. The **Log Explorer** interface provides a set of filters @@ -18,10 +18,11 @@ above the log file data, depending on your configuration: ![Pod logs](img/kubernetes_pod_logs_v12_10.png) - **Namespace** - Select the environment to display. Users with Maintainer or - greater [permissions](../../permissions.md) can also select Managed Apps. -- **Search** - Only available if the Elastic Stack managed application is installed. -- **Select time range** - Select the range of time to display. Only available if the - Elastic Stack managed application is installed. + greater [permissions](../../permissions.md) can also see pods in the + `gitlab-managed-apps` namespace. +- **Search** - Only available if the [Elastic Stack integration](../../clusters/integrations.md#elastic-stack-cluster-integration) is enabled. +- **Select time range** - Select the range of time to display. + Only available if the [Elastic Stack integration](../../clusters/integrations.md#elastic-stack-cluster-integration) is enabled. - **Scroll to bottom** **{scroll_down}** - Scroll to the end of the displayed logs. - **Refresh** **{retry}** - Reload the displayed logs. @@ -43,12 +44,11 @@ a [metrics dashboard](../../../operations/metrics/index.md) and select **View lo 1. Sign in as a user with the _View pod logs_ [permissions](../../permissions.md#project-members-permissions) in the project. -1. *To navigate to the **Log Explorer** from the sidebar menu,* go to - **{cloud-gear}** **Operations > Pod logs**. - ([Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22011) in GitLab 12.5.) -1. *To navigate to the **Log Explorer** from a specific pod on a [Deploy Board](../deploy_boards.md):* +1. To navigate to the **Log Explorer** from the sidebar menu, go to **Monitor > Logs** + ([Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22011) in GitLab 12.5.). +1. To navigate to the **Log Explorer** from a specific pod on a [Deploy Board](../deploy_boards.md): - 1. Go to **{cloud-gear}** **Operations > Environments** and find the environment + 1. Go to **Deployments > Environments** and find the environment which contains the desired pod, like `production`. 1. On the **Environments** page, you should see the status of the environment's pods with [Deploy Boards](../deploy_boards.md). @@ -81,7 +81,7 @@ Support for historical data is coming > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/197879) in GitLab 12.8. -When you enable [Elastic Stack](../../clusters/applications.md#elastic-stack) +When you enable [Elastic Stack](../../clusters/integrations.md#elastic-stack-cluster-integration) on your cluster, you can filter logs displayed in the **Log Explorer** by date. Click **Show last** in the **Log Explorer** to see the available options. @@ -90,7 +90,7 @@ Click **Show last** in the **Log Explorer** to see the available options. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21656) in GitLab 12.7. -When you enable [Elastic Stack](../../clusters/applications.md#elastic-stack) on your cluster, +When you enable [Elastic Stack](../../clusters/integrations.md#elastic-stack-cluster-integration) on your cluster, you can search the content of your logs through a search bar. The search is passed to Elasticsearch using the [simple_query_string](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-simple-query-string-query.html) diff --git a/doc/user/project/clusters/protect/container_host_security/index.md b/doc/user/project/clusters/protect/container_host_security/index.md index 102001d4f87..5e4df6009f0 100644 --- a/doc/user/project/clusters/protect/container_host_security/index.md +++ b/doc/user/project/clusters/protect/container_host_security/index.md @@ -4,7 +4,7 @@ group: Container Security 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 --- -# Container Host Security +# Container Host Security **(FREE)** Container Host Security in GitLab provides Intrusion Detection and Prevention capabilities that can monitor and (optionally) block activity inside the containers themselves. This is done by leveraging @@ -28,8 +28,8 @@ users define profiles for these technologies. See the [installation guide](quick_start_guide.md) for the recommended steps to install the Container Host Security capabilities. This guide shows the recommended way of installing Container -Host Security through GMAv2. However, it's also possible to do a manual installation through our -Helm chart. +Host Security through the Cluster Management Project. However, it's also possible to do a manual +installation through our Helm chart. ## Features diff --git a/doc/user/project/clusters/protect/container_host_security/quick_start_guide.md b/doc/user/project/clusters/protect/container_host_security/quick_start_guide.md index fa4a5fb61d0..ebcd56078ae 100644 --- a/doc/user/project/clusters/protect/container_host_security/quick_start_guide.md +++ b/doc/user/project/clusters/protect/container_host_security/quick_start_guide.md @@ -4,11 +4,9 @@ group: Container Security 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 --- -# Getting started with Container Host Security +# Getting started with Container Host Security **(FREE)** -The following steps are recommended for installing Container Host Security. Although you can install -some capabilities through GMAv1, we [recommend](#using-gmav1-with-gmav2) that you install -applications through GMAv2 exclusively when using Container Network Security. +The following steps are recommended for installing Container Host Security. ## Installation steps @@ -21,8 +19,7 @@ The following steps are recommended to install and use Container Host Security t 1. Install and configure an Ingress node: - - [Install the Ingress node via CI/CD (GMAv2)](../../../../clusters/applications.md#install-ingress-using-gitlab-cicd). - - [Determine the external endpoint via the manual method](../../../../clusters/applications.md#determining-the-external-endpoint-manually). + - [Install the Ingress node via CI/CD (Cluster Management Project)](../../../../clusters/applications.md#install-ingress-using-gitlab-cicd). - Navigate to the Kubernetes page and enter the [DNS address for the external endpoint](../../index.md#base-domain) into the **Base domain** field on the **Details** tab. Save the changes to the Kubernetes cluster. @@ -63,19 +60,6 @@ initial troubleshooting steps that resolve the most common problems: `kubectl delete namespaces ` in your Kubernetes cluster. - Rerun the application project pipeline to redeploy the application. -### Using GMAv1 with GMAv2 - -When GMAv1 and GMAv2 are used together on the same cluster, users may experience problems with -applications being uninstalled or removed from the cluster. This is because GMAv2 actively -uninstalls applications that are installed with GMAv1 and not configured to be installed with GMAv2. -It's possible to use a mixture of applications installed with GMAv1 and GMAv2 by ensuring that the -GMAv1 applications are installed **after** the GMAv2 cluster management project pipeline runs. GMAv1 -applications must be reinstalled after each run of that pipeline. This approach isn't recommended as -it's error-prone and can lead to downtime as applications are uninstalled and later reinstalled. -When using Container Network Security, the preferred and recommended path is to install all -necessary components with GMAv2 and the cluster management project. - **Related documentation links:** -- [GitLab Managed Apps v1 (GMAv1)](../../../../clusters/applications.md#install-with-one-click-deprecated) -- [GitLab Managed Apps v2 (GMAv2)](../../../../clusters/management_project.md) +- [Cluster Management Project](../../../../clusters/management_project.md) diff --git a/doc/user/project/clusters/protect/container_network_security/index.md b/doc/user/project/clusters/protect/container_network_security/index.md index a7cdd73acd7..3daa48e1811 100644 --- a/doc/user/project/clusters/protect/container_network_security/index.md +++ b/doc/user/project/clusters/protect/container_network_security/index.md @@ -4,7 +4,7 @@ group: Container Security 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 --- -# Container Network Security +# Container Network Security **(FREE)** Container Network Security in GitLab provides basic firewall functionality by leveraging Cilium NetworkPolicies to filter traffic going in and out of the cluster as well as traffic between pods @@ -20,8 +20,8 @@ disabled by default, as they must usually be customized to match application-spe See the [installation guide](quick_start_guide.md) for the recommended steps to install GitLab Container Network Security. This guide shows the recommended way of installing Container Network -Security through GMAv2. However, it's also possible to install Cilium manually through our Helm -chart. +Security through the Cluster Management Project. However, it's also possible to install Cilium +manually through our Helm chart. ## Features diff --git a/doc/user/project/clusters/protect/container_network_security/quick_start_guide.md b/doc/user/project/clusters/protect/container_network_security/quick_start_guide.md index bf419c69885..33aefec224a 100644 --- a/doc/user/project/clusters/protect/container_network_security/quick_start_guide.md +++ b/doc/user/project/clusters/protect/container_network_security/quick_start_guide.md @@ -4,11 +4,9 @@ group: Container Security 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 --- -# Getting started with Container Network Security +# Getting started with Container Network Security **(FREE)** -The following steps are recommended for installing Container Network Security. Although you can -install some capabilities through GMAv1, we [recommend](#using-gmav1-with-gmav2) that you install -applications through GMAv2 exclusively when using Container Network Security. +The following steps are recommended for installing Container Network Security. ## Installation steps @@ -21,8 +19,7 @@ The following steps are recommended to install and use Container Network Securit 1. Install and configure an Ingress node: - - [Install the Ingress node via CI/CD (GMAv2)](../../../../clusters/applications.md#install-ingress-using-gitlab-cicd). - - [Determine the external endpoint via the manual method](../../../../clusters/applications.md#determining-the-external-endpoint-manually). + - [Install the Ingress node via CI/CD (Cluster Management Project)](../../../../clusters/applications.md#install-ingress-using-gitlab-cicd). - Navigate to the Kubernetes page and enter the [DNS address for the external endpoint](../../index.md#base-domain) into the **Base domain** field on the **Details** tab. Save the changes to the Kubernetes cluster. @@ -60,7 +57,7 @@ use both methods simultaneously, when the application project pipeline runs the NetworkPolicy in the `auto-deploy-values.yaml` file may override policies configured in the UI editor. -## Monitoring throughput `**(ULTIMATE)**` +## Monitoring throughput **(ULTIMATE)** To view statistics for Container Network Security, you must follow the installation steps above and configure GitLab integration with Prometheus. Also, if you use custom Helm values for Cilium, you @@ -83,12 +80,8 @@ Additional information about the statistics page is available in the ## Forwarding logs to a SIEM Cilium logs can be forwarded to a SIEM or an external logging system through syslog protocol by -installing and configuring Fluentd. Fluentd can be installed through GitLab in two ways: - -- The [GMAv1 method](../../../../clusters/applications.md#fluentd) -- The [GMAv2 method](../../../../clusters/applications.md#install-fluentd-using-gitlab-cicd) - -GitLab strongly encourages using only the GMAv2 method to install Fluentd. +installing and configuring Fluentd. Fluentd can be installed through the GitLab +[Cluster Management Project](../../../../clusters/applications.md#install-fluentd-using-gitlab-cicd). ## Viewing the logs @@ -135,19 +128,6 @@ initial troubleshooting steps that resolve the most common problems: - Delete the relevant namespace in Kubernetes by running `kubectl delete namespaces ` in your Kubernetes cluster. - Rerun the application project pipeline to redeploy the application. -### Using GMAv1 with GMAv2 - -When GMAv1 and GMAv2 are used together on the same cluster, users may experience problems with -applications being uninstalled or removed from the cluster. This is because GMAv2 actively -uninstalls applications that are installed with GMAv1 and not configured to be installed with GMAv2. -It's possible to use a mixture of applications installed with GMAv1 and GMAv2 by ensuring that the -GMAv1 applications are installed **after** the GMAv2 cluster management project pipeline runs. GMAv1 -applications must be reinstalled after each run of that pipeline. This approach isn't recommended as -it's error-prone and can lead to downtime as applications are uninstalled and later reinstalled. -When using Container Network Security, the preferred and recommended path is to install all -necessary components with GMAv2 and the cluster management project. - **Related documentation links:** -- [GitLab Managed Apps v1 (GMAv1)](../../../../clusters/applications.md#install-with-one-click-deprecated) -- [GitLab Managed Apps v2 (GMAv2)](../../../../clusters/management_project.md) +- [Cluster Management Project](../../../../clusters/management_project.md) diff --git a/doc/user/project/clusters/protect/index.md b/doc/user/project/clusters/protect/index.md index c489a0ddd30..1314a1948d5 100644 --- a/doc/user/project/clusters/protect/index.md +++ b/doc/user/project/clusters/protect/index.md @@ -4,7 +4,7 @@ group: Container Security 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 --- -# Protecting your deployed applications +# Protecting your deployed applications **(FREE)** GitLab makes it straightforward to protect applications deployed in [connected Kubernetes clusters](index.md). These protections are available in the Kubernetes network layer and in the container itself. At @@ -18,9 +18,6 @@ containers themselves. The following capabilities are available to protect deployed applications in Kubernetes: -- Web Application Firewall - - [Overview](web_application_firewall/index.md) - - [Installation guide](web_application_firewall/quick_start_guide.md) - Container Network Security - [Overview](container_network_security/index.md) - [Installation guide](container_network_security/quick_start_guide.md) diff --git a/doc/user/project/clusters/protect/web_application_firewall/img/guide_waf_ingress_disabled_settings_v12_10.png b/doc/user/project/clusters/protect/web_application_firewall/img/guide_waf_ingress_disabled_settings_v12_10.png deleted file mode 100644 index 2dd6df3d37b..00000000000 Binary files a/doc/user/project/clusters/protect/web_application_firewall/img/guide_waf_ingress_disabled_settings_v12_10.png and /dev/null differ diff --git a/doc/user/project/clusters/protect/web_application_firewall/img/guide_waf_ingress_installation_v12_10.png b/doc/user/project/clusters/protect/web_application_firewall/img/guide_waf_ingress_installation_v12_10.png deleted file mode 100644 index e88f62a2eba..00000000000 Binary files a/doc/user/project/clusters/protect/web_application_firewall/img/guide_waf_ingress_installation_v12_10.png and /dev/null differ diff --git a/doc/user/project/clusters/protect/web_application_firewall/img/guide_waf_ingress_save_changes_v12_10.png b/doc/user/project/clusters/protect/web_application_firewall/img/guide_waf_ingress_save_changes_v12_10.png deleted file mode 100644 index 1c99d4f7f96..00000000000 Binary files a/doc/user/project/clusters/protect/web_application_firewall/img/guide_waf_ingress_save_changes_v12_10.png and /dev/null differ diff --git a/doc/user/project/clusters/protect/web_application_firewall/index.md b/doc/user/project/clusters/protect/web_application_firewall/index.md deleted file mode 100644 index 6e2e71c6ced..00000000000 --- a/doc/user/project/clusters/protect/web_application_firewall/index.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -stage: Protect -group: Container Security -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 ---- - -# Web Application Firewall - -WARNING: -The Web Application Firewall is in its end-of-life process. It is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/271276) -in GitLab 13.6, and planned for [removal](https://gitlab.com/gitlab-org/gitlab/-/issues/271349) -in GitLab 14.0. - -A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to -and from a web application. By inspecting HTTP traffic, it can prevent attacks -stemming from web application security flaws. It can be used to detect SQL injection, -Cross-Site Scripting (XSS), Remote File Inclusion, Security Misconfigurations, and -much more. - -## Overview - -GitLab provides a WAF out of the box after Ingress is deployed. All you need to do is deploy your -application along with a service and Ingress resource. In the GitLab [Ingress](../../../../clusters/applications.md#ingress) -deployment, the [ModSecurity](https://modsecurity.org/) -module is loaded into Ingress-NGINX by default and monitors the traffic to the applications -which have an Ingress. The ModSecurity module runs with the [OWASP Core Rule Set (CRS)](https://coreruleset.org/) -by default. The OWASP CRS detects and logs a wide range of common attacks. - -By default, the WAF is deployed in Detection-only mode and only logs attack attempts. - -## Requirements - -The Web Application Firewall requires: - -- **Kubernetes** - - To enable the WAF, you need: - - - Kubernetes 1.12+. - - A load balancer. You can use NGINX-Ingress by deploying it to your - Kubernetes cluster by either: - - Using the [`nginx-ingress` Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). - - Installing the [Ingress GitLab Managed App](../../../../clusters/applications.md#ingress) with WAF enabled. - -- **Configured Kubernetes objects** - - To use the WAF on an application, you need to deploy the following Kubernetes resources: - - - [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) - - [Service](https://kubernetes.io/docs/concepts/services-networking/service/) - - [Ingress Resource](https://kubernetes.io/docs/concepts/services-networking/ingress/) - -## Quick start - -If you are using GitLab.com, see the [quick start guide](quick_start_guide.md) for -how to use the WAF with GitLab.com and a Kubernetes cluster on Google Kubernetes Engine (GKE). - -If you are using a self-managed instance of GitLab, you must configure the -[Google OAuth2 OmniAuth Provider](../../../../../integration/google.md) before -you can configure a cluster on GKE. Once this is set up, you can follow the steps on the -[quick start guide](quick_start_guide.md) -to get started. - -NOTE: -This guide shows how the WAF can be deployed using Auto DevOps. The WAF -is available by default to all applications no matter how they are deployed, -as long as they are using Ingress. - -## Network firewall vs. Web Application Firewall - -A network firewall or packet filter looks at traffic at the Network (L3) and Transport (L4) layers -of the [OSI Model](https://en.wikipedia.org/wiki/OSI_model), and denies packets from entry based on -a set of rules regarding the network in general. - -A Web Application Firewall operates at the Application (L7) layer of the OSI Model and can -examine all the packets traveling to and from a specific application. A WAF can set -more advanced rules around threat detection. - -## Features - -ModSecurity is enabled with the [OWASP Core Rule Set (CRS)](https://github.com/coreruleset/coreruleset/) by -default. The OWASP CRS logs attempts to the following attacks: - -- [SQL Injection](https://wiki.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_SQL_Injection) -- [Cross-Site Scripting](https://wiki.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Cross-Site_Scripting_(XSS)) -- [Local File Inclusion](https://wiki.owasp.org/index.php/Testing_for_Local_File_Inclusion) -- [Remote File Inclusion](https://wiki.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Remote_File_Inclusion) -- [Code Injection](https://wiki.owasp.org/index.php/Code_Injection) -- [Session Fixation](https://wiki.owasp.org/index.php/Session_fixation) -- [Scanner Detection](https://wiki.owasp.org/index.php/Category:Vulnerability_Scanning_Tools) -- [Metadata/Error Leakages](https://wiki.owasp.org/index.php/Improper_Error_Handling) - -It is good to have a basic knowledge of the following: - -- [Kubernetes](https://kubernetes.io/docs/home/) -- [Ingress](https://kubernetes.github.io/ingress-nginx/) -- [ModSecurity](https://www.modsecurity.org/) -- [OWASP Core Rule Set](https://github.com/coreruleset/coreruleset/) - -## Roadmap - -You can find more information on the product direction of the WAF in -[Category Direction - Web Application Firewall](https://about.gitlab.com/direction/protect/web_application_firewall/). diff --git a/doc/user/project/clusters/protect/web_application_firewall/quick_start_guide.md b/doc/user/project/clusters/protect/web_application_firewall/quick_start_guide.md deleted file mode 100644 index e7d8d591510..00000000000 --- a/doc/user/project/clusters/protect/web_application_firewall/quick_start_guide.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -stage: Protect -group: Container Security -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 ---- - -# Getting started with the Web Application Firewall - -WARNING: -The Web Application Firewall is in its end-of-life process. It is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/271276) -in GitLab 13.6, and planned for [removal](https://gitlab.com/gitlab-org/gitlab/-/issues/271349) -in GitLab 14.0. - -This is a step-by-step guide to help you use the GitLab [Web Application Firewall](index.md) after -deploying a project hosted on GitLab.com to Google Kubernetes Engine using [Auto DevOps](../../../../../topics/autodevops/index.md). - -The GitLab native Kubernetes integration is used, so you do not need -to create a Kubernetes cluster manually using the Google Cloud Platform console. -A simple application is created and deployed based on a GitLab template. - -These instructions also work for a self-managed GitLab instance. However, you -need to ensure your own [runners are configured](../../../../../ci/runners/README.md) and -[Google OAuth is enabled](../../../../../integration/google.md). - -The GitLab Web Application Firewall is deployed with [Ingress](../../../../clusters/applications.md#ingress), -so it is available to your applications no matter how you deploy them to Kubernetes. - -## Configuring your Google account - -Before creating and connecting your Kubernetes cluster to your GitLab project, -you need a Google Cloud Platform account. If you do not already have one, -sign up at . You need to either sign in with an existing -Google account (for example, one that you use to access Gmail, Drive, etc.) or create a new one. - -1. To enable the required APIs and related services, follow the steps in the ["Before you begin" section of the Kubernetes Engine docs](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin). -1. Make sure you have created a [billing account](https://cloud.google.com/billing/docs/how-to/manage-billing-account). - -NOTE: -Every new Google Cloud Platform (GCP) account receives [$300 in credit](https://console.cloud.google.com/freetrial), -and in partnership with Google, GitLab is able to offer an additional $200 for new GCP accounts to get started with the GitLab -Google Kubernetes Engine integration. All you have to do is [follow this link](https://cloud.google.com/partners/partnercredit/?PCN=a0n60000006Vpz4AAC) and apply for credit. - -## Creating a new project from a template - -We use a GitLab project templates to get started. As the name suggests, -those projects provide a bare-bones application built on some well-known frameworks. - -1. In GitLab, click the plus icon (**+**) at the top of the navigation bar and select - **New project**. -1. Go to the **Create from template** tab where you can choose for example a Ruby on - Rails, Spring, or NodeJS Express project. - Use the Ruby on Rails template. - - ![Select project template](../../../../../topics/autodevops/img/guide_project_template_v12_3.png) - -1. Give your project a name, optionally a description, and make it public so that - you can take advantage of the features available in the - [GitLab Ultimate plan](https://about.gitlab.com/pricing/). - - ![Create project](../../../../../topics/autodevops/img/guide_create_project_v12_3.png) - -1. Click **Create project**. - -Now that the project is created, the next step is to create the Kubernetes cluster -to deploy this application under. - -## Creating a Kubernetes cluster from within GitLab - -1. On the project's landing page, click **Add Kubernetes cluster** - (note that this option is also available when you navigate to **Operations > Kubernetes**). - - ![Project landing page](../../../../../topics/autodevops/img/guide_project_landing_page_v12_10.png) - -1. On the **Create new cluster on GKE** tab, click **Sign in with Google**. - - ![Google sign in](../../../../../topics/autodevops/img/guide_google_signin_v12_3.png) - -1. Connect with your Google account and click **Allow** when asked (this - appears only the first time you connect GitLab with your Google account). - - ![Google auth](../../../../../topics/autodevops/img/guide_google_auth_v12_3.png) - -1. The last step is to provide the cluster details. - 1. Give it a name, leave the environment scope as is, and choose the GCP project under which to create the cluster. - (Per the instructions to [configure your Google account](#configuring-your-google-account), a project should have already been created for you.) - 1. Choose the [region/zone](https://cloud.google.com/compute/docs/regions-zones/) to create the cluster in. - 1. Enter the number of nodes you want it to have. - 1. Choose the [machine type](https://cloud.google.com/compute/docs/machine-types). - - ![GitLab GKE cluster details](../../../../../topics/autodevops/img/guide_gitlab_gke_details_v12_3.png) - -1. Click **Create Kubernetes cluster**. - -After a couple of minutes, the cluster is created. You can also see its -status on your [GCP dashboard](https://console.cloud.google.com/kubernetes). - -The next step is to install some applications on your cluster that are needed -to take full advantage of Auto DevOps. - -## Install Ingress - -The GitLab Kubernetes integration comes with some -[pre-defined applications](../../index.md#installing-applications) -for you to install. - -![Cluster applications](../../../../../topics/autodevops/img/guide_cluster_apps_v12_3.png) - -For this guide, we need to install Ingress. Ingress provides load balancing, -SSL termination, and name-based virtual hosting, using NGINX behind -the scenes. Make sure to switch the toggle to the enabled position before installing. - -Both logging and blocking modes are available for WAF. While logging mode is useful for -auditing anomalous traffic, blocking mode ensures the traffic doesn't reach past Ingress. - -![Cluster applications](img/guide_waf_ingress_installation_v12_10.png) - -After Ingress is installed, wait a few seconds and copy the IP address that -is displayed in order to add in your base **Domain** at the top of the page. For -the purpose of this guide, we use the one suggested by GitLab. Once you have -filled in the domain, click **Save changes**. - -![Cluster Base Domain](../../../../../topics/autodevops/img/guide_base_domain_v12_3.png) - -Prometheus should also be installed. It is an open-source monitoring and -alerting system that is used to supervise the deployed application. -Installing GitLab Runner is not required as we use the shared runners that -GitLab.com provides. - -## Enabling Auto DevOps (optional) - -Starting with GitLab 11.3, Auto DevOps is enabled by default. However, it is possible to disable -Auto DevOps at both the instance-level (for self-managed instances) and the group-level. -Follow these steps if Auto DevOps has been manually disabled: - -1. Navigate to **Settings > CI/CD > Auto DevOps**. -1. Select **Default to Auto DevOps pipeline**. -1. Select the [continuous deployment strategy](../../../../../topics/autodevops/index.md#deployment-strategy) - which automatically deploys the application to production once the pipeline - successfully runs on the `master` branch. -1. Click **Save changes**. - - ![Auto DevOps settings](../../../../../topics/autodevops/img/guide_enable_autodevops_v12_3.png) - -Once you complete all the above and save your changes, a new pipeline is -automatically created. To view the pipeline, go to **CI/CD > Pipelines**. - -![First pipeline](../../../../../topics/autodevops/img/guide_first_pipeline_v12_3.png) - -The next section explains what each pipeline job does. - -## Deploying the application - -By now you should see the pipeline running, but what is it running exactly? - -To navigate inside the pipeline, click its status badge (its status should be "Running"). -The pipeline is split into a few stages, each running a couple of jobs. - -![Pipeline stages](../../../../../topics/autodevops/img/guide_pipeline_stages_v13_0.png) - -In the **build** stage, the application is built into a Docker image and then -uploaded to your project's [Container Registry](../../../../packages/container_registry/index.md) -([Auto Build](../../../../../topics/autodevops/stages.md#auto-build)). - -In the **test** stage, GitLab runs various checks on the application. - -The **production** stage is run after the tests and checks finish, and it automatically -deploys the application in Kubernetes ([Auto Deploy](../../../../../topics/autodevops/stages.md#auto-deploy)). - -The **production** stage creates Kubernetes objects -like a Deployment, Service, and Ingress resource. The -application is monitored by the WAF automatically. - -## Validating Ingress is running ModSecurity - -Now we can make sure that Ingress is running properly with ModSecurity and send -a request to ensure our application is responding correctly. You must connect to -your cluster either using [Cloud Shell](https://cloud.google.com/shell/) or the [Google Cloud SDK](https://cloud.google.com/sdk/docs/install). - -1. After connecting to your cluster, check if the Ingress-NGINX controller is running and ModSecurity is enabled. - - This is done by running the following commands: - - ```shell - $ kubectl get pods -n gitlab-managed-apps | grep 'ingress-controller' - ingress-nginx-ingress-controller-55f9cf6584-dxljn 2/2 Running - - $ kubectl -n gitlab-managed-apps exec -it $(kubectl get pods -n gitlab-managed-apps | grep 'ingress-controller' | awk '{print $1}') -- cat /etc/nginx/nginx.conf | grep 'modsecurity on;' - modsecurity on; - ``` - -1. Verify the Rails application has been installed properly. - - ```shell - $ kubectl get ns - auto-devv-2-16730183-production Active - - $ kubectl get pods -n auto-devv-2-16730183-production - NAME READY STATUS RESTARTS - production-5778cfcfcd-nqjcm 1/1 Running 0 - production-postgres-6449f8cc98-r7xgg 1/1 Running 0 - ``` - -1. To make sure the Rails application is responding, send a request to it by running: - - ```shell - $ kubectl get ing -n auto-devv-2-16730183-production - NAME HOSTS PORTS - production-auto-deploy fjdiaz-auto-devv-2.34.68.60.207.nip.io,le-16730183.34.68.60.207.nip.io 80, 443 - - $ curl --location --insecure "fjdiaz-auto-devv-2.34.68.60.207.nip.io" | grep 'Rails!' --after 2 --before 2 - -

You're on Rails!

- - ``` - -Now that we have confirmed our system is properly setup, we can go ahead and test -the WAF with OWASP CRS! - -## Testing out the OWASP Core Rule Set - -Now let's send a potentially malicious request, as if we were a scanner, -checking for vulnerabilities within our application and examine the ModSecurity logs: - -```shell -$ curl --location --insecure "fjdiaz-auto-devv-2.34.68.60.207.nip.io" --header "User-Agent: absinthe" | grep 'Rails!' --after 2 --before 2 - -

You're on Rails!

- - -$ kubectl -n gitlab-managed-apps exec -it $(kubectl get pods -n gitlab-managed-apps | grep 'ingress-controller' | awk '{print $1}') -- cat /var/log/modsec/audit.log | grep 'absinthe' -{ - "message": "Found User-Agent associated with security scanner", - "details": { - "match": "Matched \"Operator `PmFromFile' with parameter `scanners-user-agents.data' against variable `REQUEST_HEADERS:user-agent' (Value: `absinthe' )", - "reference": "o0,8v84,8t:lowercase", - "ruleId": "913100", - "file": "/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf", - "lineNumber": "33", - "data": "Matched Data: absinthe found within REQUEST_HEADERS:user-agent: absinthe", - "severity": "2", - "ver": "OWASP_CRS/3.2.0", - "rev": "", - "tags": ["application-multi", "language-multi", "platform-multi", "attack-reputation-scanner", "OWASP_CRS", "OWASP_CRS/AUTOMATION/SECURITY_SCANNER", "WASCTC/WASC-21", "OWASP_TOP_10/A7", "PCI/6.5.10"], - "maturity": "0", - "accuracy": "0" - } -} -``` - -You can see that ModSecurity logs the suspicious behavior. By sending a request -with the `User Agent: absinthe` header, which [absinthe](https://github.com/cameronhotchkies/Absinthe), -a tool for testing for SQL injections uses, we can detect that someone was -searching for vulnerabilities on our system. Detecting scanners is useful, because we -can learn if someone is trying to exploit our system. - -## Conclusion - -You can now see the benefits of a using a Web Application Firewall. -ModSecurity and the OWASP Core Rule Set, offer many more benefits. -You can explore them in more detail: - -- [Category Direction - Web Application Firewall](https://about.gitlab.com/direction/protect/web_application_firewall/) -- [ModSecurity](https://www.modsecurity.org/) -- [OWASP Core Rule Set](https://github.com/coreruleset/coreruleset/) -- [AutoDevOps](../../../../../topics/autodevops/index.md) diff --git a/doc/user/project/clusters/runbooks/index.md b/doc/user/project/clusters/runbooks/index.md index e0b8c074fcf..b2054c4befb 100644 --- a/doc/user/project/clusters/runbooks/index.md +++ b/doc/user/project/clusters/runbooks/index.md @@ -63,18 +63,93 @@ information. Follow this step-by-step guide to configure an executable runbook in GitLab using the components outlined above and the pre-loaded demo runbook. -1. Add a Kubernetes cluster to your project by following the steps outlined in - [Create new cluster](../add_remove_clusters.md#create-new-cluster). - -1. Click the **Install** button next to the **Ingress** application to install Ingress. - - ![install ingress](img/ingress-install.png) - -1. After Ingress has been installed successfully, click the **Install** button next - to the **JupyterHub** application. You need the **Jupyter Hostname** provided - here in the next step. - - ![install JupyterHub](img/jupyterhub-install.png) +1. Create an [OAuth Application for JupyterHub](../../../../integration/oauth_provider.md#gitlab-as-oauth2-authentication-service-provider). +1. When [installing JupyterHub with Helm](https://zero-to-jupyterhub.readthedocs.io/en/latest/jupyterhub/installation.html), use the following values + + ```yaml + #----------------------------------------------------------------------------- + # The gitlab and ingress sections must be customized! + #----------------------------------------------------------------------------- + + gitlab: + clientId: + clientSecret: + callbackUrl: http:///hub/oauth_callback, + # Limit access to members of specific projects or groups: + # allowedGitlabGroups: [ "my-group-1", "my-group-2" ] + # allowedProjectIds: [ 12345, 6789 ] + + # ingress is required for OAuth to work + ingress: + enabled: true + host: + # tls: + # - hosts: + # - + # secretName: jupyter-cert + # annotations: + # kubernetes.io/ingress.class: "nginx" + # kubernetes.io/tls-acme: "true" + + #----------------------------------------------------------------------------- + # NO MODIFICATIONS REQUIRED BEYOND THIS POINT + #----------------------------------------------------------------------------- + + hub: + extraEnv: + JUPYTER_ENABLE_LAB: 1 + extraConfig: | + c.KubeSpawner.cmd = ['jupyter-labhub'] + c.GitLabOAuthenticator.scope = ['api read_repository write_repository'] + + async def add_auth_env(spawner): + ''' + We set user's id, login and access token on single user image to + enable repository integration for JupyterHub. + See: https://gitlab.com/gitlab-org/gitlab-foss/issues/47138#note_154294790 + ''' + auth_state = await spawner.user.get_auth_state() + + if not auth_state: + spawner.log.warning("No auth state for %s", spawner.user) + return + + spawner.environment['GITLAB_ACCESS_TOKEN'] = auth_state['access_token'] + spawner.environment['GITLAB_USER_LOGIN'] = auth_state['gitlab_user']['username'] + spawner.environment['GITLAB_USER_ID'] = str(auth_state['gitlab_user']['id']) + spawner.environment['GITLAB_USER_EMAIL'] = auth_state['gitlab_user']['email'] + spawner.environment['GITLAB_USER_NAME'] = auth_state['gitlab_user']['name'] + + c.KubeSpawner.pre_spawn_hook = add_auth_env + + auth: + type: gitlab + state: + enabled: true + + singleuser: + defaultUrl: "/lab" + image: + name: registry.gitlab.com/gitlab-org/jupyterhub-user-image + tag: latest + lifecycleHooks: + postStart: + exec: + command: + - "sh" + - "-c" + - > + git clone https://gitlab.com/gitlab-org/nurtch-demo.git DevOps-Runbook-Demo || true; + echo "https://oauth2:${GITLAB_ACCESS_TOKEN}@${GITLAB_HOST}" > ~/.git-credentials; + git config --global credential.helper store; + git config --global user.email "${GITLAB_USER_EMAIL}"; + git config --global user.name "${GITLAB_USER_NAME}"; + jupyter serverextension enable --py jupyterlab_git + + proxy: + service: + type: ClusterIP + ``` 1. After JupyterHub has been installed successfully, open the **Jupyter Hostname** in your browser. Click the **Sign in with GitLab** button to log in to diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md index e355b562c36..e4ac1eabffe 100644 --- a/doc/user/project/clusters/serverless/index.md +++ b/doc/user/project/clusters/serverless/index.md @@ -15,7 +15,7 @@ Serverless is currently in [alpha](https://about.gitlab.com/handbook/product/git Serverless architectures offer Operators and Developers the ability write highly scalable applications without provisioning a single server. -GitLab supports several ways deploy Serverless applications in both Kubernetes Environments and also major cloud FAAS environments. +GitLab supports several ways deploy Serverless applications in both Kubernetes Environments and also major cloud Function as a Service (FaaS) environments. Currently we support: @@ -35,7 +35,7 @@ of the box through its main components: For more information on Knative, visit the [Knative docs repository](https://github.com/knative/docs). -With GitLab Serverless, you can deploy both functions-as-a-service (FaaS) and serverless applications. +With GitLab Serverless, you can deploy both FaaS and serverless applications. ## Prerequisites @@ -53,7 +53,7 @@ To run Knative on GitLab, you need: The set of minimum recommended cluster specifications to run Knative is 3 nodes, 6 vCPUs, and 22.50 GB memory. 1. **GitLab Runner:** A runner is required to run the CI jobs that deploy serverless applications or functions onto your cluster. You can install GitLab Runner - onto the existing Kubernetes cluster. See [Installing Applications](../index.md#installing-applications) for more information. + onto the [existing Kubernetes cluster](https://docs.gitlab.com/runner/install/kubernetes.html). 1. **Domain Name:** Knative provides its own load balancer using Istio, and an external IP address or hostname for all the applications served by Knative. Enter a wildcard domain to serve your applications. Configure your DNS server to use the @@ -68,54 +68,18 @@ To run Knative on GitLab, you need: `Dockerfile` in order to build your applications. It should be included at the root of your project's repository and expose port `8080`. `Dockerfile` is not require if you plan to build serverless functions using our [runtimes](https://gitlab.com/gitlab-org/serverless/runtimes). -1. **Prometheus** (optional): Installing Prometheus allows you to monitor the scale and traffic of your serverless function/application. - See [Installing Applications](../index.md#installing-applications) for more information. +1. **Prometheus** (optional): The [Prometheus cluster integration](../../../clusters/integrations.md#prometheus-cluster-integration) + allows you to monitor the scale and traffic of your serverless function/application. 1. **Logging** (optional): Configuring logging allows you to view and search request logs for your serverless function/application. See [Configuring logging](#configuring-logging) for more information. -## Installing Knative via the GitLab Kubernetes integration - -The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.50 GB -memory. **RBAC must be enabled.** - -1. [Add a Kubernetes cluster](../add_remove_clusters.md). -1. Select the **Applications** tab and scroll down to the Knative app section. Enter the domain to be used with - your application/functions (e.g. `example.com`) and click **Install**. - - ![install-knative](img/install-knative.png) - -1. After the Knative installation has finished, you can wait for the IP address or hostname to be displayed in the - **Knative Endpoint** field or [retrieve the Istio Ingress Endpoint manually](../../../clusters/applications.md#determining-the-external-endpoint-manually). - - NOTE: - Running `kubectl` commands on your cluster requires setting up access to the cluster first. - For clusters created on GKE, see [GKE Cluster Access](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl), - for other platforms [Install kubectl](https://kubernetes.io/docs/tasks/tools/). - -1. The Ingress is now available at this address and routes incoming requests to the proper service based on the DNS - name in the request. To support this, a wildcard DNS record should be created for the desired domain name. For example, - if your Knative base domain is `knative.info` then you need to create an A record or CNAME record with domain `*.knative.info` - pointing the IP address or hostname of the Ingress. - - ![DNS entry](img/dns-entry.png) - -You can deploy either [functions](#deploying-functions) or [serverless applications](#deploying-serverless-applications) -on a given project, but not both. The current implementation makes use of a -`serverless.yml` file to signal a FaaS project. - -## Using an existing installation of Knative +## Configuring Knative > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58941) in GitLab 12.0. -The _invocations_ monitoring feature of GitLab serverless is unavailable when -adding an existing installation of Knative. - -It's also possible to use GitLab Serverless with an existing Kubernetes cluster -which already has Knative installed. You must do the following: - 1. Follow the steps to - [add an existing Kubernetes - cluster](../add_remove_clusters.md#add-existing-cluster). + [add a Kubernetes + cluster](../add_remove_clusters.md). 1. Ensure GitLab can manage Knative: - For a non-GitLab managed cluster, ensure that the service account for the token @@ -164,13 +128,17 @@ which already has Knative installed. You must do the following: kubectl apply -f knative-serving-only-role.yaml ``` - If you would rather grant permissions on a per service account basis, you can do this - using a `Role` and `RoleBinding` specific to the service account and namespace. + Alternatively, permissions can be granted on a per-service account basis + using `Role`s and `RoleBinding`s (see the [Kubernetes RBAC + documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) + for more information). 1. Follow the steps to deploy [functions](#deploying-functions) or [serverless applications](#deploying-serverless-applications) onto your cluster. +1. **Optional:** For invocation metrics to show in GitLab, additional Istio metrics need to be configured in your cluster. For example, with Knative v0.9.0, you can use [this manifest](https://gitlab.com/gitlab-org/charts/knative/-/raw/v0.10.0/vendor/istio-metrics.yml). + ## Supported runtimes Serverless functions for GitLab can be run using: @@ -183,7 +151,7 @@ If a runtime is not available for the required programming language, consider de ### GitLab-managed runtimes -Currently the following GitLab-managed [runtimes](https://gitlab.com/gitlab-org/serverless/runtimes) +The following GitLab-managed [runtimes](https://gitlab.com/gitlab-org/serverless/runtimes) are available: - `go` (proof of concept) @@ -352,7 +320,7 @@ After the `gitlab-ci.yml` template has been added and the `serverless.yml` file has been created, pushing a commit to your project results in a CI pipeline being executed which deploys each function as a Knative service. After the deploy stage has finished, additional details for the function display -under **Operations > Serverless**. +under **Infrastructure > Serverless platform**. ![serverless page](img/serverless-page.png) @@ -486,7 +454,7 @@ With all the pieces in place, the next time a CI pipeline runs the Knative appli ### Function details -Go to the **Operations > Serverless** page to see the final URL of your functions. +Go to the **Infrastructure > Serverless platform** page to see the final URL of your functions. ![function_details](img/function-list_v12_7.png) @@ -499,10 +467,10 @@ rows to bring up the function details page. The pod count gives you the number of pods running the serverless function instances on a given cluster. -For the Knative function invocations to appear, -[Prometheus must be installed](../index.md#installing-applications). +For the Knative function invocations to appear, the +[Prometheus cluster integration must be enabled](../../../clusters/integrations.md#prometheus-cluster-integration). -Once Prometheus is installed, a message may appear indicating that the metrics data _is +Once Prometheus is enabled, a message may appear indicating that the metrics data _is loading or is not available at this time._ It appears upon the first access of the page, but should go away after a few seconds. If the message does not disappear, then it is possible that GitLab is unable to connect to the Prometheus instance running on the @@ -611,7 +579,7 @@ or with other versions of Python. Where `` is the namespace created by GitLab for your serverless project (composed of `--`) and `example.com` is the domain being used for your project. If you are unsure what the namespace of your project is, navigate - to the **Operations > Serverless** page of your project and inspect + to the **Infrastructure > Serverless platform** page of your project and inspect the endpoint provided for your function/app. ![function_endpoint](img/function-endpoint.png) diff --git a/doc/user/project/deploy_boards.md b/doc/user/project/deploy_boards.md index 804c013d317..89c82d4dc6f 100644 --- a/doc/user/project/deploy_boards.md +++ b/doc/user/project/deploy_boards.md @@ -117,7 +117,7 @@ To display the Deploy Boards for a specific [environment](../../ci/environments/ ![Deploy Boards Kubernetes Label](img/deploy_boards_kubernetes_label.png) Once all of the above are set up and the pipeline has run at least once, -navigate to the environments page under **Operations > Environments**. +navigate to the environments page under **Deployments > Environments**. Deploy Boards are visible by default. You can explicitly click the triangle next to their respective environment name in order to hide them. diff --git a/doc/user/project/deploy_keys/index.md b/doc/user/project/deploy_keys/index.md index a6b54474a9e..c0bc97781b6 100644 --- a/doc/user/project/deploy_keys/index.md +++ b/doc/user/project/deploy_keys/index.md @@ -28,7 +28,7 @@ repository in automation, it's a simple solution. A drawback is that your repository could become vulnerable if a remote machine is compromised by a hacker. You should limit access to the remote machine before a deploy key is enabled on your repository. A good rule to follow is to provide access only to trusted users, -and make sure that the allowed users have [maintainer permissions or higher](../../permissions.md) +and make sure that the allowed users have the [Maintainer role or higher](../../permissions.md) in the GitLab project. If this security implication is a concern for your organization, diff --git a/doc/user/project/deploy_tokens/index.md b/doc/user/project/deploy_tokens/index.md index e2fa63ce519..800aa27f612 100644 --- a/doc/user/project/deploy_tokens/index.md +++ b/doc/user/project/deploy_tokens/index.md @@ -190,4 +190,4 @@ docker login -u $CI_DEPLOY_USER -p $CI_DEPLOY_PASSWORD $CI_REGISTRY NOTE: The special handling for the `gitlab-deploy-token` deploy token is not implemented for group deploy tokens. To make the group-level deploy token available for -CI/CD jobs, use the workaround in [issue 214014](https://gitlab.com/gitlab-org/gitlab/-/issues/214014). +CI/CD jobs, the `CI_DEPLOY_USER` and `CI_DEPLOY_PASSWORD` variables should be set under **Settings** to the name and token of the group deploy token respectively. diff --git a/doc/user/project/description_templates.md b/doc/user/project/description_templates.md index 4a2bd56b7ba..d2897c7310e 100644 --- a/doc/user/project/description_templates.md +++ b/doc/user/project/description_templates.md @@ -106,11 +106,7 @@ instance or the project's parent groups. ### Set instance-level description templates **(PREMIUM SELF)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52360) in GitLab 13.9. -> - [Deployed behind a feature flag](../feature_flags.md), disabled by default. -> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56737) in GitLab 13.11. -> - Enabled by default on GitLab.com. -> - Recommended for production use. -> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-issue-and-merge-request-description-templates-at-group-and-instance-level). **(PREMIUM SELF)** +> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/321247) in GitLab 14.0. You can set a description template at the **instance level** for issues and merge requests. @@ -132,11 +128,7 @@ Learn more about [instance template repository](../admin_area/settings/instance_ ### Set group-level description templates **(PREMIUM)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52360) in GitLab 13.9. -> - [Deployed behind a feature flag](../feature_flags.md), disabled by default. -> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56737) in GitLab 13.11. -> - Enabled by default on GitLab.com. -> - Recommended for production use. -> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-issue-and-merge-request-description-templates-at-group-and-instance-level). **(PREMIUM SELF)** +> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/321247) in GitLab 14.0. With **group-level** description templates, you can store your templates in a single repository and configure the group file templates setting to point to that repository. @@ -184,7 +176,7 @@ provide `issues_template` and `merge_requests_template` attributes in the ## Description template example We use description templates for issues and merge requests in the -[`.gitlab` folder](https://gitlab.com/gitlab-org/gitlab/tree/master/.gitlab) of the +[`.gitlab` folder](https://gitlab.com/gitlab-org/gitlab/-/tree/master/.gitlab) of the GitLab project, which you can refer to for some examples. NOTE: @@ -231,28 +223,3 @@ it's very hard to read otherwise.) /cc @project-manager /assign @qa-tester ``` - -## Enable or disable issue and merge request description templates at group and instance level **(PREMIUM SELF)** - -Setting issue and merge request description templates at group and instance levels -is under development but ready for production use. It is deployed behind a -feature flag that is **enabled by default**. -[GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md) -can disable it. - -To disable it: - -```ruby -Feature.disable(:inherited_issuable_templates) -``` - -To enable it: - -```ruby -Feature.enable(:inherited_issuable_templates) -``` - -The feature flag affects these features: - -- Setting a templates project as issue and merge request description templates source at group level. -- Setting a templates project as issue and merge request description templates source at instance level. diff --git a/doc/user/project/file_lock.md b/doc/user/project/file_lock.md index 576de63d00d..eb963cb74c5 100644 --- a/doc/user/project/file_lock.md +++ b/doc/user/project/file_lock.md @@ -80,7 +80,7 @@ Check this document to learn more about [using Git LFS](../../topics/git/lfs/ind ### Configure Exclusive File Locks -You need [Maintainer permissions](../permissions.md) to configure +You need the [Maintainer role](../permissions.md) to configure Exclusive File Locks for your project through the command line. The first thing to do before using File Locking is to tell Git LFS which @@ -201,8 +201,8 @@ This process allows you to lock one file at a time through the GitLab UI and requires access to [GitLab Premium](https://about.gitlab.com/pricing/) or higher tiers. -Default branch file and directory locks only apply to the default branch set in -the project's settings (usually `master`). +Default branch file and directory locks only apply to the +[default branch](repository/branches/default.md) set in the project's settings. Changes to locked files on the default branch are blocked, including merge requests that modify locked files. Unlock the file to allow changes. @@ -226,6 +226,6 @@ who locked the file. The **Locked Files**, accessed from **Project > Repository** left menu, lists all file and directory locks. Locks can be removed by their author, or any user -with Maintainer permissions and above. +with the [Maintainer role](../permissions.md) and above. This list shows all the files locked either through LFS or GitLab UI. diff --git a/doc/user/project/highlighting.md b/doc/user/project/highlighting.md index 2e5713e10be..aa8cf4549e2 100644 --- a/doc/user/project/highlighting.md +++ b/doc/user/project/highlighting.md @@ -45,7 +45,7 @@ To disable highlighting entirely, use `gitlab-language=text`. Lots more fun shen ``` Please note that these configurations only take effect when the `.gitattributes` -file is in your default branch (usually `master`). +file is in your [default branch](repository/branches/default.md). NOTE: The Web IDE does not support `.gitattribute` files, but it's [planned for a future release](https://gitlab.com/gitlab-org/gitlab/-/issues/22014). diff --git a/doc/user/project/img/code_owners_approval_new_protected_branch_v13_10.png b/doc/user/project/img/code_owners_approval_new_protected_branch_v13_10.png deleted file mode 100644 index ee4ee2c6d71..00000000000 Binary files a/doc/user/project/img/code_owners_approval_new_protected_branch_v13_10.png and /dev/null differ diff --git a/doc/user/project/img/code_owners_approval_protected_branch_v13_10.png b/doc/user/project/img/code_owners_approval_protected_branch_v13_10.png deleted file mode 100644 index 220eb207132..00000000000 Binary files a/doc/user/project/img/code_owners_approval_protected_branch_v13_10.png and /dev/null differ diff --git a/doc/user/project/import/bitbucket.md b/doc/user/project/import/bitbucket.md index e77932c6427..802eb3efc51 100644 --- a/doc/user/project/import/bitbucket.md +++ b/doc/user/project/import/bitbucket.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Import your project from Bitbucket Cloud to GitLab +# Import your project from Bitbucket Cloud to GitLab **(FREE)** NOTE: The Bitbucket Cloud importer works only with Bitbucket.org, not with Bitbucket diff --git a/doc/user/project/import/bitbucket_server.md b/doc/user/project/import/bitbucket_server.md index 1e79107d76f..963b9f524ff 100644 --- a/doc/user/project/import/bitbucket_server.md +++ b/doc/user/project/import/bitbucket_server.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Import your project from Bitbucket Server to GitLab +# Import your project from Bitbucket Server to GitLab **(FREE)** > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20164) in GitLab 11.2. diff --git a/doc/user/project/import/clearcase.md b/doc/user/project/import/clearcase.md index 7e07ca6f865..27a84476590 100644 --- a/doc/user/project/import/clearcase.md +++ b/doc/user/project/import/clearcase.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Migrating from ClearCase +# Migrating from ClearCase **(FREE)** [ClearCase](https://www.ibm.com/products/rational-clearcase) is a set of tools developed by IBM which also include a centralized version control system diff --git a/doc/user/project/import/cvs.md b/doc/user/project/import/cvs.md index 61d4d29aa4d..55c5feff1f0 100644 --- a/doc/user/project/import/cvs.md +++ b/doc/user/project/import/cvs.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Migrating from CVS +# Migrating from CVS **(FREE)** [CVS](https://savannah.nongnu.org/projects/cvs) is an old centralized version control system similar to [SVN](svn.md). diff --git a/doc/user/project/import/fogbugz.md b/doc/user/project/import/fogbugz.md index 09505d94a8c..d3d77f16200 100644 --- a/doc/user/project/import/fogbugz.md +++ b/doc/user/project/import/fogbugz.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Import your project from FogBugz to GitLab +# Import your project from FogBugz to GitLab **(FREE)** It only takes a few simple steps to import your project from FogBugz. The importer imports all your cases and comments with original case diff --git a/doc/user/project/import/gemnasium.md b/doc/user/project/import/gemnasium.md index 5a4b16d57f5..37460da1289 100644 --- a/doc/user/project/import/gemnasium.md +++ b/doc/user/project/import/gemnasium.md @@ -1,5 +1,6 @@ --- redirect_to: 'index.md' +remove_date: '2021-08-15' --- This document was deleted. diff --git a/doc/user/project/import/gitea.md b/doc/user/project/import/gitea.md index 41141902468..9364ac4f954 100644 --- a/doc/user/project/import/gitea.md +++ b/doc/user/project/import/gitea.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Import your project from Gitea to GitLab +# Import your project from Gitea to GitLab **(FREE)** Import your projects from Gitea to GitLab with minimal effort. diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md index c8b973b673e..99b3e1acdcf 100644 --- a/doc/user/project/import/github.md +++ b/doc/user/project/import/github.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Import your project from GitHub to GitLab +# Import your project from GitHub to GitLab **(FREE)** Using the importer, you can import your GitHub repositories to GitLab.com or to your self-managed GitLab instance. diff --git a/doc/user/project/import/gitlab_com.md b/doc/user/project/import/gitlab_com.md index 9e63b1cb617..f7eb5e43a79 100644 --- a/doc/user/project/import/gitlab_com.md +++ b/doc/user/project/import/gitlab_com.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Project importing from GitLab.com to your private GitLab instance +# Project importing from GitLab.com to your private GitLab instance **(FREE)** You can import your existing GitLab.com projects to your GitLab instance, but keep in mind that it is possible only if GitLab.com integration is enabled on your GitLab instance. diff --git a/doc/user/project/import/index.md b/doc/user/project/import/index.md index 3728a486070..05fd04f6e48 100644 --- a/doc/user/project/import/index.md +++ b/doc/user/project/import/index.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Migrate projects to a GitLab instance +# Migrate projects to a GitLab instance **(FREE)** See these documents to migrate to GitLab: diff --git a/doc/user/project/import/manifest.md b/doc/user/project/import/manifest.md index 94eba319a17..131732d2bae 100644 --- a/doc/user/project/import/manifest.md +++ b/doc/user/project/import/manifest.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Import multiple repositories by uploading a manifest file +# Import multiple repositories by uploading a manifest file **(FREE)** > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/28811) in GitLab 11.2. diff --git a/doc/user/project/import/perforce.md b/doc/user/project/import/perforce.md index 8040eb07c93..f3843396b79 100644 --- a/doc/user/project/import/perforce.md +++ b/doc/user/project/import/perforce.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Migrating from Perforce Helix +# Migrating from Perforce Helix **(FREE)** [Perforce Helix](https://www.perforce.com/) provides a set of tools which also include a centralized, proprietary version control system similar to Git. diff --git a/doc/user/project/import/phabricator.md b/doc/user/project/import/phabricator.md index 30a63a72cf9..6a1370f3301 100644 --- a/doc/user/project/import/phabricator.md +++ b/doc/user/project/import/phabricator.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Import Phabricator tasks into a GitLab project +# Import Phabricator tasks into a GitLab project **(FREE SELF)** > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/60562) in GitLab 12.0. diff --git a/doc/user/project/import/repo_by_url.md b/doc/user/project/import/repo_by_url.md index 3ff612c51a7..e504f3678a7 100644 --- a/doc/user/project/import/repo_by_url.md +++ b/doc/user/project/import/repo_by_url.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Import project from repository by URL +# Import project from repository by URL **(FREE)** You can import your existing repositories by providing the Git URL: diff --git a/doc/user/project/import/svn.md b/doc/user/project/import/svn.md index e39976e00f6..b88abf91ae1 100644 --- a/doc/user/project/import/svn.md +++ b/doc/user/project/import/svn.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Migrating from SVN to GitLab +# Migrating from SVN to GitLab **(FREE)** Subversion (SVN) is a central version control system (VCS) while Git is a distributed version control system. There are some major differences @@ -112,6 +112,10 @@ contact the SubGit team directly at [support@subgit.com](mailto:support@subgit.c ## Cut over migration with svn2git +NOTE: +Any issues with svn2git should be directed to the [relevant project and maintainer](https://github.com/nirvdrum/svn2git). +Check for existing issues and history for update frequency. + If you are currently using an SVN repository, you can migrate the repository to Git and GitLab. We recommend a hard cut over - run the migration command once and then have all developers start using the new GitLab repository immediately. diff --git a/doc/user/project/import/tfvc.md b/doc/user/project/import/tfvc.md index 705df686fe0..910be690d0b 100644 --- a/doc/user/project/import/tfvc.md +++ b/doc/user/project/import/tfvc.md @@ -1,11 +1,11 @@ --- -stage: none -group: unassigned +stage: Manage +group: Import 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 type: concepts --- -# Migrate from TFVC to Git +# Migrate from TFVC to Git **(FREE)** Team Foundation Server (TFS), renamed [Azure DevOps Server](https://azure.microsoft.com/en-us/services/devops/server/) in 2019, is a set of tools developed by Microsoft which also includes diff --git a/doc/user/project/index.md b/doc/user/project/index.md index d9283f623d4..0dcbf997452 100644 --- a/doc/user/project/index.md +++ b/doc/user/project/index.md @@ -5,7 +5,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated type: reference --- -# Projects **(FREE)** +# Organize work with projects **(FREE)** In GitLab, you can create projects to host your codebase. You can also use projects to track issues, plan work, @@ -97,7 +97,7 @@ Projects include the following [features](https://about.gitlab.com/features/): - [Security Dashboard](../application_security/security_dashboard/index.md) **(ULTIMATE)** - [Syntax highlighting](highlighting.md): Customize your code blocks, overriding the default language choice. -- [Badges](badges.md): Add an image to the project overview. +- [Badges](badges.md): Add an image to the **Project information** page. - [Releases](releases/index.md): Take a snapshot of the source, build output, metadata, and artifacts associated with a released version of your code. diff --git a/doc/user/project/integrations/gitlab_slack_application.md b/doc/user/project/integrations/gitlab_slack_application.md index ef8c9d59132..ac70c7e4b4e 100644 --- a/doc/user/project/integrations/gitlab_slack_application.md +++ b/doc/user/project/integrations/gitlab_slack_application.md @@ -25,7 +25,7 @@ The simplest way to enable the GitLab Slack application for your workspace is to install the [GitLab application](https://slack-platform.slack.com/apps/A676ADMV5-gitlab) from the [Slack App Directory](https://slack.com/apps). -Clicking install takes you to the [GitLab Slack application landing page](https://gitlab.com/profile/slack/edit) +Clicking install takes you to the [GitLab Slack application landing page](https://gitlab.com/-/profile/slack/edit) where you can select a project to enable the GitLab Slack application for. ![GitLab Slack application landing page](img/gitlab_slack_app_landing_page.png) diff --git a/doc/user/project/integrations/hipchat.md b/doc/user/project/integrations/hipchat.md deleted file mode 100644 index 63772936fd4..00000000000 --- a/doc/user/project/integrations/hipchat.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -redirect_to: 'index.md' ---- - -This document was moved to [another location](index.md). - - diff --git a/doc/user/project/integrations/index.md b/doc/user/project/integrations/index.md index c7772ac2238..f9e15ced858 100644 --- a/doc/user/project/integrations/index.md +++ b/doc/user/project/integrations/index.md @@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w You can find the available integrations under your project's **Settings > Integrations** page. You need to have at least -[maintainer permission](../../permissions.md) on the project. +the [Maintainer role](../../permissions.md) on the project. ## Integrations diff --git a/doc/user/project/integrations/jira.md b/doc/user/project/integrations/jira.md index b91a8a1fb3b..521f15f330e 100644 --- a/doc/user/project/integrations/jira.md +++ b/doc/user/project/integrations/jira.md @@ -1,5 +1,6 @@ --- redirect_to: '../../../integration/jira/index.md' +remove_date: '2021-07-07' --- This document was moved to [another location](../../../integration/jira/index.md). diff --git a/doc/user/project/integrations/jira_cloud_configuration.md b/doc/user/project/integrations/jira_cloud_configuration.md index b3091275835..c9ab4532760 100644 --- a/doc/user/project/integrations/jira_cloud_configuration.md +++ b/doc/user/project/integrations/jira_cloud_configuration.md @@ -1,5 +1,6 @@ --- redirect_to: '../../../integration/jira/jira_cloud_configuration.md' +remove_date: '2021-06-18' --- This document was moved to [another location](../../../integration/jira/jira_cloud_configuration.md). diff --git a/doc/user/project/integrations/jira_integrations.md b/doc/user/project/integrations/jira_integrations.md index 485b48df01b..3aacf051c22 100644 --- a/doc/user/project/integrations/jira_integrations.md +++ b/doc/user/project/integrations/jira_integrations.md @@ -1,5 +1,6 @@ --- redirect_to: '../../../integration/jira/index.md' +remove_date: '2021-07-13' --- This document was moved to [another location](../../../integration/jira/index.md). diff --git a/doc/user/project/integrations/jira_server_configuration.md b/doc/user/project/integrations/jira_server_configuration.md index 191b8f207a1..de6eec62b96 100644 --- a/doc/user/project/integrations/jira_server_configuration.md +++ b/doc/user/project/integrations/jira_server_configuration.md @@ -1,5 +1,6 @@ --- redirect_to: '../../../integration/jira/jira_server_configuration.md' +remove_date: '2021-06-18' --- This document was moved to [another location](../../../integration/jira/jira_server_configuration.md). diff --git a/doc/user/project/integrations/mattermost_slash_commands.md b/doc/user/project/integrations/mattermost_slash_commands.md index 20f5b73b37c..834bf15c287 100644 --- a/doc/user/project/integrations/mattermost_slash_commands.md +++ b/doc/user/project/integrations/mattermost_slash_commands.md @@ -67,9 +67,9 @@ After you enable custom slash commands in Mattermost, you need configuration information from GitLab. To get this information: 1. In a different browser tab than your current Mattermost session, sign in to - GitLab as a user with [administrator permissions](../../permissions.md). -1. In the top navigation bar, go to **{admin}** **Admin Area**. -1. In the left menu, go to **Settings > Integrations** and select + GitLab as a user with [Administrator role](../../permissions.md). +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left menu, select **Settings > Integrations**, then select **Mattermost slash commands**. 1. GitLab displays potential values for Mattermost settings. Copy the **Request URL** as you need it for the next step. All other values are suggestions. diff --git a/doc/user/project/integrations/overview.md b/doc/user/project/integrations/overview.md index 5bd4062b125..b0ae290e7cd 100644 --- a/doc/user/project/integrations/overview.md +++ b/doc/user/project/integrations/overview.md @@ -80,19 +80,6 @@ instance configuration or provide custom settings. Read more about [Project integration management](../../admin_area/settings/project_integration_management.md). -### Service templates - -[Service templates](services_templates.md) were a way to set predefined values for -a project integration across all new projects on the instance. They are deprecated and -[scheduled to be removed](https://gitlab.com/gitlab-org/gitlab/-/issues/268032) -in GitLab 14.0. - -GitLab recommends you use [project integration management](../../admin_area/settings/project_integration_management.md) -instead of service templates. GitLab versions 13.3 and later provide -[instance-level integrations](../../admin_area/settings/project_integration_management.md#project-integration-management) -you can use. -instead. - ## Troubleshooting integrations Some integrations use service hooks for integration with external applications. To confirm which ones use service hooks, see the [integrations listing](#integrations-listing) above. GitLab stores details of service hook requests made within the last 2 days. To view details of the requests, go to that integration's configuration page. @@ -128,6 +115,6 @@ plugins. This allows the community to keep the plugins up to date so that they always work in newer GitLab versions. For an overview of what integrations are available, please see the -[project_services source directory](https://gitlab.com/gitlab-org/gitlab/tree/master/app/models/project_services). +[project_services source directory](https://gitlab.com/gitlab-org/gitlab/-/tree/master/app/models/project_services). Contributions are welcome! diff --git a/doc/user/project/integrations/prometheus.md b/doc/user/project/integrations/prometheus.md index 4922c8d9b62..adc98151ce4 100644 --- a/doc/user/project/integrations/prometheus.md +++ b/doc/user/project/integrations/prometheus.md @@ -17,7 +17,7 @@ in the GitLab interface. There are two ways to set up Prometheus integration, depending on where your apps are running: -- For deployments on Kubernetes, GitLab can automatically [deploy and manage Prometheus](#managed-prometheus-on-kubernetes). +- For deployments on Kubernetes, GitLab can be [integrated with an in-cluster Prometheus](#prometheus-cluster-integration) - For other deployment targets, [specify the Prometheus server](#manual-configuration-of-prometheus). Once enabled, GitLab detects metrics from known services in the @@ -27,141 +27,13 @@ Once enabled, GitLab detects metrics from known services in the ## Enabling Prometheus Integration -### Managed Prometheus on Kubernetes +### Prometheus cluster integration -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/28916) in GitLab 10.5. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55244) in GitLab 13.11. +> - [Replaced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62725) the Prometheus cluster applications in GitLab 14.0. -**Deprecated:** Managed Prometheus on Kubernetes is deprecated, and -scheduled for removal in [GitLab -14.0](https://gitlab.com/groups/gitlab-org/-/epics/4280). - -GitLab can seamlessly deploy and manage Prometheus on a -[connected Kubernetes cluster](../clusters/index.md), to help you monitor your apps. - -#### Requirements - -- A [connected Kubernetes cluster](../clusters/index.md) - -#### Getting started - -After you have a connected Kubernetes cluster, you can deploy a managed Prometheus with a single click. - -1. Go to the **Operations > Kubernetes** page to view your connected clusters -1. Select the cluster you would like to deploy Prometheus to -1. Click the **Install** button to deploy Prometheus to the cluster - -![Managed Prometheus Deploy](img/prometheus_deploy.png) - -#### About managed Prometheus deployments - -Prometheus is deployed into the `gitlab-managed-apps` namespace, using the -[official Helm chart](https://github.com/helm/charts/tree/master/stable/prometheus). -Prometheus is only accessible in the cluster, with GitLab communicating through the -[Kubernetes API](https://kubernetes.io/docs/concepts/overview/kubernetes-api/). - -The Prometheus server -[automatically detects and monitors](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config) -nodes, pods, and endpoints. To configure a resource to be monitored by Prometheus, -set the following [Kubernetes annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/): - -- `prometheus.io/scrape` to `true` to enable monitoring of the resource. -- `prometheus.io/port` to define the port of the metrics endpoint. -- `prometheus.io/path` to define the path of the metrics endpoint. Defaults to `/metrics`. - -CPU and Memory consumption is monitored, but requires -[naming conventions](prometheus_library/kubernetes.md#specifying-the-environment) -to determine the environment. If you are using -[Auto DevOps](../../../topics/autodevops/index.md), this is handled automatically. - -The [NGINX Ingress](../clusters/index.md#installing-applications) that is deployed -by GitLab to clusters, is automatically annotated for monitoring providing key -response metrics: latency, throughput, and error rates. - -##### Example of Kubernetes service annotations and labels - -As an example, to activate Prometheus monitoring of a service: - -1. Add at least this annotation: `prometheus.io/scrape: 'true'`. -1. Add two labels so GitLab can retrieve metrics dynamically for any environment: - - `application: ${CI_ENVIRONMENT_SLUG}` - - `release: ${CI_ENVIRONMENT_SLUG}` -1. Create a dynamic PromQL query. For example, a query like - `temperature{application="{{ci_environment_slug}}",release="{{ci_environment_slug}}"}` to either: - - Add [custom metrics](../../../operations/metrics/index.md#adding-custom-metrics). - - Add [custom dashboards](../../../operations/metrics/dashboards/index.md). - -The following is a service definition to accomplish this: - -```yaml ---- -# Service -apiVersion: v1 -kind: Service -metadata: - name: service-${CI_PROJECT_NAME}-${CI_COMMIT_REF_SLUG} - # === Prometheus annotations === - annotations: - prometheus.io/scrape: 'true' - labels: - application: ${CI_ENVIRONMENT_SLUG} - release: ${CI_ENVIRONMENT_SLUG} - # === End of Prometheus === -spec: - selector: - app: ${CI_PROJECT_NAME} - ports: - - port: ${EXPOSED_PORT} - targetPort: ${CONTAINER_PORT} -``` - -#### Access the UI of a Prometheus managed application in Kubernetes - -You can connect directly to Prometheus, and view the Prometheus user interface, when -using a Prometheus managed application in Kubernetes: - -1. Find the name of the Prometheus pod in the user interface of your Kubernetes - provider, such as GKE, or by running the following `kubectl` command in your - terminal: - - ```shell - kubectl get pods -n gitlab-managed-apps | grep 'prometheus-prometheus-server' - ``` - - The command should return a result like the following example, where - `prometheus-prometheus-server-55b4bd64c9-dpc6b` is the name of the Prometheus pod: - - ```plaintext - gitlab-managed-apps prometheus-prometheus-server-55b4bd64c9-dpc6b 2/2 Running 0 71d - ``` - -1. Run a `kubectl port-forward` command. In the following example, `9090` is the - Prometheus server's listening port: - - ```shell - kubectl port-forward prometheus-prometheus-server-55b4bd64c9-dpc6b 9090:9090 -n gitlab-managed-apps - ``` - - The `port-forward` command forwards all requests sent to your system's `9090` port - to the `9090` port of the Prometheus pod. If the `9090` port on your system is used - by another application, you can change the port number before the colon to your - desired port. For example, to forward port `8080` of your local system, change the - command to: - - ```shell - kubectl port-forward prometheus-prometheus-server-55b4bd64c9-dpc6b 8080:9090 -n gitlab-managed-apps - ``` - -1. Open `localhost:9090` in your browser to display the Prometheus user interface. - -#### Script access to Prometheus - -You can script the access to Prometheus, extracting the name of the pod automatically like this: - -```shell -POD_INFORMATION=$(kubectl get pods -n gitlab-managed-apps | grep 'prometheus-prometheus-server') -POD_NAME=$(echo $POD_INFORMATION | awk '{print $1;}') -kubectl port-forward $POD_NAME 9090:9090 -n gitlab-managed-apps -``` +GitLab can query an in-cluster Prometheus for your metrics. +See [Prometheus cluster integration](../../clusters/integrations.md#prometheus-cluster-integration) for details. ### Manual configuration of Prometheus @@ -223,12 +95,12 @@ to integrate with. ### Precedence with multiple Prometheus configurations Although you can enable both a [manual configuration](#manual-configuration-of-prometheus) -and [auto configuration](#managed-prometheus-on-kubernetes) of Prometheus, you +and [cluster integration](#prometheus-cluster-integration) of Prometheus, you can use only one: - If you have enabled a [Prometheus manual configuration](#manual-configuration-of-prometheus) - and a [managed Prometheus on Kubernetes](#managed-prometheus-on-kubernetes), + and a [Prometheus cluster integration](#prometheus-cluster-integration), the manual configuration takes precedence and is used to run queries from [custom dashboards](../../../operations/metrics/dashboards/index.md) and [custom metrics](../../../operations/metrics/index.md#adding-custom-metrics). diff --git a/doc/user/project/integrations/prometheus_library/kubernetes.md b/doc/user/project/integrations/prometheus_library/kubernetes.md index e14c1c0f6fd..1bafa4938af 100644 --- a/doc/user/project/integrations/prometheus_library/kubernetes.md +++ b/doc/user/project/integrations/prometheus_library/kubernetes.md @@ -33,7 +33,7 @@ integration services must be enabled. Prometheus needs to be deployed into the cluster and configured properly in order to gather Kubernetes metrics. GitLab supports two methods for doing so: -- GitLab [integrates with Kubernetes](../../clusters/index.md), and can [deploy Prometheus into a connected cluster](../prometheus.md#managed-prometheus-on-kubernetes). It is automatically configured to collect Kubernetes metrics. +- GitLab [integrates with Kubernetes](../../clusters/index.md), and can [query a Prometheus in a connected cluster](../../../clusters/integrations.md#prometheus-cluster-integration). The in-cluster Prometheus can be configured to automatically collect application metrics from your cluster. - To configure your own Prometheus server, you can follow the [Prometheus documentation](https://prometheus.io/docs/introduction/overview/). ## Specifying the Environment diff --git a/doc/user/project/integrations/prometheus_library/nginx_ingress.md b/doc/user/project/integrations/prometheus_library/nginx_ingress.md index 8846aadd420..d1fe58390fe 100644 --- a/doc/user/project/integrations/prometheus_library/nginx_ingress.md +++ b/doc/user/project/integrations/prometheus_library/nginx_ingress.md @@ -27,28 +27,6 @@ NGINX Ingress versions prior to 0.16.0 offer an included [VTS Prometheus metrics ## Configuring NGINX Ingress monitoring -If you have deployed NGINX Ingress using the GitLab [Kubernetes cluster integration](../../clusters/index.md#installing-applications), Prometheus [automatically monitors it](#about-managed-nginx-ingress-deployments). - -For other deployments, there is [some configuration](#manually-setting-up-nginx-ingress-for-prometheus-monitoring) required depending on your installation: - -- NGINX Ingress should be version 0.16.0 or above, with metrics enabled. -- NGINX Ingress should be annotated for Prometheus monitoring. -- Prometheus should be configured to monitor annotated pods. - -### About managed NGINX Ingress deployments - -NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). NGINX Ingress is [externally reachable via the Load Balancer's Endpoint](../../../clusters/applications.md#ingress). - -NGINX is configured for Prometheus monitoring, by setting: - -- `enable-vts-status: "true"`, to export Prometheus metrics. -- `prometheus.io/scrape: "true"`, to enable automatic discovery. -- `prometheus.io/port: "10254"`, to specify the metrics port. - -When used in conjunction with the GitLab deployed Prometheus service, response metrics are automatically collected. - -### Manually setting up NGINX Ingress for Prometheus monitoring - Version 0.9.0 and above of [NGINX Ingress](https://github.com/kubernetes/ingress-nginx) have built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint starts running on port 10254. Next, the Ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added: diff --git a/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md b/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md index 4752fec976c..6bdd2c64dcf 100644 --- a/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md +++ b/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md @@ -27,28 +27,6 @@ GitLab has support for automatically detecting and monitoring the Kubernetes NGI ## Configuring NGINX Ingress monitoring -If you have deployed NGINX Ingress using the GitLab [Kubernetes cluster integration](../../clusters/index.md#installing-applications), Prometheus [automatically monitors](#about-managed-nginx-ingress-deployments) it. - -For other deployments, there is [some configuration](#manually-setting-up-nginx-ingress-for-prometheus-monitoring) required depending on your installation: - -- NGINX Ingress should be version 0.9.0 or above, with metrics enabled. -- NGINX Ingress should be annotated for Prometheus monitoring. -- Prometheus should be configured to monitor annotated pods. - -### About managed NGINX Ingress deployments - -NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). NGINX Ingress is [externally reachable via the Load Balancer's Endpoint](../../../clusters/applications.md#ingress). - -NGINX is configured for Prometheus monitoring, by setting: - -- `enable-vts-status: "true"`, to export Prometheus metrics. -- `prometheus.io/scrape: "true"`, to enable automatic discovery. -- `prometheus.io/port: "10254"`, to specify the metrics port. - -When used in conjunction with the GitLab deployed Prometheus service, response metrics are automatically collected. - -### Manually setting up NGINX Ingress for Prometheus monitoring - Version 0.9.0 and above of [NGINX Ingress](https://github.com/kubernetes/ingress-nginx) has built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint begins running on port 10254. Next, the Ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added: diff --git a/doc/user/project/integrations/services_templates.md b/doc/user/project/integrations/services_templates.md index 93ce74eb735..37df48c75f8 100644 --- a/doc/user/project/integrations/services_templates.md +++ b/doc/user/project/integrations/services_templates.md @@ -1,67 +1,9 @@ --- -stage: Create -group: Ecosystem -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 +redirect_to: '../../admin_area/settings/project_integration_management.md' +remove_date: '2021-09-09' --- -# Service templates **(FREE)** +This document was moved to [another location](../../admin_area/settings/project_integration_management.md). -WARNING: -Service templates are [deprecated and scheduled to be removed](https://gitlab.com/gitlab-org/gitlab/-/issues/268032) -in GitLab 14.0. Use [project integration management](#central-administration-of-project-integrations) instead. - -Using a service template, GitLab administrators can: - -- Provide default values for configuring integrations when creating new projects. -- Bulk configure all existing projects in one step. - -When you enable a service template: - -- The defaults are applied to **all** existing projects that either: - - Don't already have the integration enabled. - - Don't have custom values stored for already enabled integrations. -- Values are populated on each project's configuration page for the applicable - integration. -- Settings are stored at the project level. - -If you disable the template: - -- GitLab default values again become the default values for integrations on - new projects. -- Projects previously configured using the template continue to use those settings. - -If you change the template, the revised values are applied to new projects. This feature -does not provide central administration of integration settings. - -## Central administration of project integrations - -A new set of features is being introduced in GitLab to provide more control over -how integrations are configured at the instance, group, and project level. For -more information, read more about: - -- [Setting up project integration management](../../admin_area/settings/project_integration_management.md) (introduced in GitLab 13.3) -- [Our plans for managing integrations](https://gitlab.com/groups/gitlab-org/-/epics/2137). - -## Enable a service template - -Navigate to the **Admin Area > Service Templates** and choose the service -template you wish to create. - -Recommendation: - -- Test the settings on some projects individually before enabling a template. -- Copy the working settings from a project to the template. - -There is no "Test settings" option when enabling templates. If the settings do not work, -these incorrect settings are applied to all existing projects that do not already have -the integration configured. Fixing the integration then needs to be done project-by-project. - -## Service for external issue trackers - -The following image shows an example service template for Redmine. - -![Redmine service template](img/services_templates_redmine_example.png) - -For each project, you still need to configure the issue tracking -URLs by replacing `:issues_tracker_id` in the above screenshot with the ID used -by your external issue tracker. + + diff --git a/doc/user/project/integrations/webex_teams.md b/doc/user/project/integrations/webex_teams.md index b2bf8e5731a..05515c58161 100644 --- a/doc/user/project/integrations/webex_teams.md +++ b/doc/user/project/integrations/webex_teams.md @@ -27,7 +27,8 @@ notifications: 1. Navigate to: - **Settings > Integrations** in a project to enable the integration at the project level. - **Settings > Integrations** in a group to enable the integration at the group level. - - **Settings > Integrations** in the Admin Area (**{admin}**) to enable an instance-level integration. + - On the top bar, select **Menu >** **{admin}** **Admin**. Then, in the left sidebar, + select **Settings > Integrations** to enable an instance-level integration. 1. Select the **Webex Teams** integration. 1. Ensure that the **Active** toggle is enabled. 1. Select the checkboxes corresponding to the GitLab events you want to receive in Webex Teams. diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md index d74a2bec1f6..406b1e9ba6b 100644 --- a/doc/user/project/integrations/webhooks.md +++ b/doc/user/project/integrations/webhooks.md @@ -34,8 +34,10 @@ Webhooks are available: - Per project, at a project's **Settings > Webhooks** menu. **(FREE)** - Additionally per group, at a group's **Settings > Webhooks** menu. **(PREMIUM)** -NOTE: -On GitLab.com, the [maximum number of webhooks and their size](../../../user/gitlab_com/index.md#webhooks) per project, and per group, is limited. +GitLab.com enforces various [webhook limits](../../../user/gitlab_com/index.md#webhooks), including: + +- The maximum number of webhooks and their size, both per project, and per group. +- The number of webhook calls per minute. ## Possible uses for webhooks @@ -308,8 +310,10 @@ X-Gitlab-Event: Issue Hook "duplicated_to_id": null, "time_estimate": 0, "total_time_spent": 0, + "time_change": 0, "human_total_time_spent": null, "human_time_estimate": null, + "human_time_change": null, "weight": null, "iid": 23, "url": "http://example.com/diaspora/issues/23", @@ -1161,6 +1165,7 @@ X-Gitlab-Event: Pipeline Hook "id": 380987, "description": "shared-runners-manager-6.gitlab.com", "active": true, + "runner_type": "instance_type", "is_shared": true, "tags": [ "linux", @@ -1196,7 +1201,8 @@ X-Gitlab-Event: Pipeline Hook "id":380987, "description":"shared-runners-manager-6.gitlab.com", "active":true, - "is_shared":true, + "runner_type": "instance_type", + "is_shared": true, "tags": [ "linux", "docker" @@ -1230,6 +1236,7 @@ X-Gitlab-Event: Pipeline Hook "id": 380987, "description": "shared-runners-manager-6.gitlab.com", "active": true, + "runner_type": "instance_type", "is_shared": true, "tags": [ "linux", @@ -1333,6 +1340,7 @@ X-Gitlab-Event: Job Hook }, "runner": { "active": true, + "runner_type": "project_type", "is_shared": false, "id": 380987, "description": "shared-runners-manager-6.gitlab.com", diff --git a/doc/user/project/issue_board.md b/doc/user/project/issue_board.md index e1b6956f873..8f71d469e34 100644 --- a/doc/user/project/issue_board.md +++ b/doc/user/project/issue_board.md @@ -34,11 +34,11 @@ boards in the same project. Different issue board features are available in different [GitLab tiers](https://about.gitlab.com/pricing/), as shown in the following table: -| Tier | Number of project issue boards | Number of [group issue boards](#group-issue-boards) | [Configurable issue boards](#configurable-issue-boards) | [Assignee lists](#assignee-lists) | -|------------------|--------------------------------|------------------------------|---------------------------|----------------| -| Free | Multiple | 1 | No | No | -| Premium | Multiple | Multiple | Yes | Yes | -| Ultimate | Multiple | Multiple | Yes | Yes | +| Tier | Number of project issue boards | Number of [group issue boards](#group-issue-boards) | [Configurable issue boards](#configurable-issue-boards) | [Assignee lists](#assignee-lists) | +| -------- | ------------------------------ | --------------------------------------------------- | ------------------------------------------------------- | --------------------------------- | +| Free | Multiple | 1 | No | No | +| Premium | Multiple | Multiple | Yes | Yes | +| Ultimate | Multiple | Multiple | Yes | Yes | To learn more, visit [GitLab Enterprise features for issue boards](#gitlab-enterprise-features-for-issue-boards) below. @@ -203,7 +203,7 @@ When visiting a board, issues appear ordered in any list. You're able to change that order by dragging the issues. The changed order is saved, so that anybody who visits the same board later sees the reordering, with some exceptions. -The first time a given issue appears in any board (that is, the first time a user +The first time an issue appears in any board (that is, the first time a user loads a board containing that issue), it is ordered in relation to other issues in that list. The order is done according to [label priority](labels.md#label-priority). @@ -222,6 +222,28 @@ This ordering also affects [issue lists](issues/sorting_issue_lists.md). Changing the order in an issue board changes the ordering in an issue list, and vice versa. +### GraphQL-based issue boards + + + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/285074) in GitLab 13.9. +> - [Deployed behind a feature flag](../feature_flags.md), disabled by default. +> - Disabled on GitLab.com. +> - Not recommended for production use. +> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-graphql-based-issue-boards). **(FREE SELF)** + +This in-development feature might not be available for your use. There can be +[risks when enabling features still in development](../feature_flags.md#risks-when-enabling-features-still-in-development). +Refer to this feature's version history for more details. + +The work-in-progress GraphQL-based boards come with these features: + +- [Edit more issue attributes](#edit-an-issue) +- [View blocked issues](#blocked-issues) + +The GraphQL-based Issue Board is a work in progress. +Learn more about the known issues in [epic 5596](https://gitlab.com/groups/gitlab-org/-/epics/5596). + ## GitLab Enterprise features for issue boards GitLab issue boards are available on the GitLab Free tier, but some @@ -269,40 +291,12 @@ especially in combination with [assignee lists](#assignee-lists). ![issue board summed weights](img/issue_board_summed_weights_v13_6.png) -### Group issue boards **(PREMIUM)** +### Group issue boards Accessible at the group navigation level, a group issue board offers the same features as a project-level board. -It can display issues from all projects in that -group and its descendant subgroups. Similarly, you can only filter by group labels for these -boards. When updating milestones and labels for an issue through the sidebar update mechanism, again only -group-level objects are available. - -#### GraphQL-based sidebar for group issue boards **(PREMIUM)** - - - - -> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/285074) in GitLab 13.9. -> - It's [deployed behind a feature flag](../feature_flags.md), disabled by default. -> - It's disabled on GitLab.com. -> - It's not recommended for production use. -> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-graphql-based-sidebar-for-group-issue-boards). **(PREMIUM SELF)** - -WARNING: -This feature might not be available to you. Check the **version history** note above for details. - -The work-in-progress GraphQL-based sidebar for group issue boards brings better performance and the -ability to edit issue titles in the issue sidebar. - -To **edit an issue's title** in the issue sidebar: - -1. In a group issue board, select the issue card. The issue sidebar opens on the right. -1. Next to the issue's title, select **Edit**. +It can display issues from all projects that fall under the group and its descendant subgroups. -This is work in progress as of GitLab 13.9. Learn more about the known issues in -[MR 51480](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/51480). - - +Users on GitLab Free can use a single group issue board. ### Assignee lists **(PREMIUM)** @@ -318,7 +312,7 @@ assignee list: 1. Search and select the user you want to add as an assignee. Now that the assignee list is added, you can assign or unassign issues to that user -by [dragging issues](#drag-issues-between-lists) to and from an assignee list. +by [moving issues](#move-issues-and-lists) to and from an assignee list. To remove an assignee list, just as with a label list, click the trash icon. ![Assignee lists](img/issue_board_assignee_lists_v13_6.png) @@ -334,7 +328,7 @@ milestone, giving you more freedom and visibility on the issue board. To add a m 1. Select the **Milestone** tab. 1. Search and click the milestone. -Like the assignee lists, you're able to [drag issues](#drag-issues-between-lists) +Like the assignee lists, you're able to [drag issues](#move-issues-and-lists) to and from a milestone list to manipulate the milestone of the dragged issues. As in other list types, click the trash icon to remove a list. @@ -361,7 +355,7 @@ iteration. To add an iteration list: 1. In the dropdown, select an iteration. 1. Select **Add to board**. -Like the milestone lists, you're able to [drag issues](#drag-issues-between-lists) +Like the milestone lists, you're able to [drag issues](#move-issues-and-lists) to and from a iteration list to manipulate the iteration of the dragged issues. ![Iteration lists](img/issue_board_iteration_lists_v13_10.png) @@ -399,7 +393,7 @@ appears on the right. There you can see and edit the issue's: - Weight - Notifications setting -You can also [drag issues](#drag-issues-between-lists) to change their position and epic assignment: +You can also [drag issues](#move-issues-and-lists) to change their position and epic assignment: - To reorder an issue, drag it to the new position within a list. - To assign an issue to another epic, drag it to the epic's horizontal lane. @@ -442,27 +436,49 @@ status. When you hover over the blocked icon (**{issue-block}**), a detailed information popover is displayed. -To enable this in group issue boards, enable the [GraphQL-based sidebar](#graphql-based-sidebar-for-group-issue-boards). -The feature is enabled by default when you use group issue boards with epic swimlanes. +This feature is only supported when using the [GraphQL-based boards](#graphql-based-issue-boards). The feature is enabled by default regardless when you use group issue boards in epic swimlanes mode. ![Blocked issues](img/issue_boards_blocked_icon_v13_10.png) ## Actions you can take on an issue board +- [Edit an issue](#edit-an-issue). - [Create a new list](#create-a-new-list). - [Remove an existing list](#remove-a-list). - [Remove an issue from a list](#remove-an-issue-from-a-list). - [Filter issues](#filter-issues) that appear across your issue board. - [Create workflows](#create-workflows). -- [Drag issues between lists](#drag-issues-between-lists). +- [Move issues and lists](#move-issues-and-lists). - [Multi-select issue cards](#multi-select-issue-cards). - Drag and reorder the lists. - Change issue labels (by dragging an issue between lists). -- Close an issue (by dragging it to the **Done** list). +- Close an issue (by dragging it to the **Closed** list). If you're not able to do some of the things above, make sure you have the right [permissions](#permissions). +### Edit an issue + +You can edit an issue without leaving the board view. +To open the right sidebar, select an issue card (not its title). + +You can edit the following issue attributes in the right sidebar: + +- Assignees +- [Epic](../group/epics/index.md) +- Milestone +- Time tracking value (view only) +- Due date +- Labels +- [Weight](issues/issue_weight.md) +- Notifications setting + +When you use [GraphQL-based boards](#graphql-based-issue-boards), you can also edit the following issue attributes: + +- Title +- [Iteration](../group/iterations/index.md) +- Confidentiality + ### Create a new list Create a new list by clicking the **Add list** dropdown button in the upper right corner of the issue board. @@ -480,12 +496,12 @@ You can now choose it to create a list. ### Remove a list Removing a list doesn't have any effect on issues and labels, as it's just the -list view that's removed. You can always restore it later if you need. +list view that's removed. You can always create it again later if you need. To remove a list from an issue board: -1. Select the **List settings** icon (**{settings}**) on the top of the list you want to remove. The - list settings sidebar opens on the right. +1. On the top of the list you want to remove, select the **List settings** icon (**{settings}**). + The list settings sidebar opens on the right. 1. Select **Remove list**. A confirmation dialog appears. 1. Select **OK**. @@ -516,9 +532,8 @@ The steps depend on the scope of the list: ### Filter issues -You should be able to use the filters on top of your issue board to show only -the results you want. It's similar to the filtering used in the issue tracker, -as the metadata from the issues and labels is re-used in the issue board. +You can use the filters on top of your issue board to show only +the results you want. It's similar to the filtering used in the [issue tracker](issues/index.md). You can filter by the following: @@ -532,6 +547,16 @@ You can filter by the following: - Release - Weight +#### Filtering issues in a group board + +When [filtering issues](#filter-issues) in a **group** board, keep this behavior in mind: + +- Milestones: you can filter by the milestones belonging to the group and its descendant groups. +- Labels: you can only filter by the labels belonging to the group but not its descendant groups. + +When you edit issues individually using the right sidebar, you can additionally select the +milestones and labels from the **project** that the issue is from. + ### Create workflows By reordering your lists, you can create workflows. As lists in issue boards are @@ -570,20 +595,45 @@ to another list, the label changes and a system note is recorded. ![issue board system notes](img/issue_board_system_notes_v13_6.png) -### Drag issues between lists +### Move issues and lists + +You can move issues and lists by dragging them. + +Prerequisites: -When dragging issues between lists, different behavior occurs depending on the source list and the target list. +- A minimum of [Reporter](../permissions.md#project-members-permissions) access to a project in GitLab. -| | To Open | To Closed | To label `B` list | To assignee `Bob` list | -| ------------------------------ | ------------------ | ------------ | ---------------------------- | ------------------------------------- | -| **From Open** | - | Issue closed | `B` added | `Bob` assigned | -| **From Closed** | Issue reopened | - | Issue reopened
`B` added | Issue reopened
`Bob` assigned | -| **From label `A` list** | `A` removed | Issue closed | `A` removed
`B` added | `Bob` assigned | -| **From assignee `Alice` list** | `Alice` unassigned | Issue closed | `B` added | `Alice` unassigned
`Bob` assigned | +To move an issue, select the issue card and drag it to another position in its current list or +into a different list. Learn about possible effects in [Dragging issues between lists](#dragging-issues-between-lists). + +To move a list, select its top bar, and drag it horizontally. +You can't move the **Open** and **Closed** lists, but you can hide them when editing an issue board. + +#### Dragging issues between lists + +To move an issue to another list, select the issue card and drag it onto that list. + +When you drag issues between lists, the result is different depending on the source list +and the target list. + +| | To Open | To Closed | To label B list | To assignee Bob list | +| ---------------------------- | -------------- | ----------- | ------------------------------ | ----------------------------- | +| **From Open** | - | Close issue | Add label B | Assign Bob | +| **From Closed** | Reopen issue | - | Reopen issue and add label B | Reopen issue and assign Bob | +| **From label A list** | Remove label A | Close issue | Remove label A and add label B | Assign Bob | +| **From assignee Alice list** | Unassign Alice | Close issue | Add label B | Unassign Alice and assign Bob | ### Multi-select issue cards -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18954) in GitLab 12.4. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18954) in GitLab 12.4. +> - [Placed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61955) behind a [feature flag](../feature_flags.md), disabled by default in GitLab 14.0. +> - Disabled on GitLab.com. +> - Not recommended for production use. +> - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-multi-selecting-issue-cards). **(FREE SELF)** + +This in-development feature might not be available for your use. There can be +[risks when enabling features still in development](../feature_flags.md#risks-when-enabling-features-still-in-development). +Refer to this feature's version history for more details. You can select multiple issue cards, then drag the group to another position within the list, or to another list. This makes it faster to reorder many issues at once. @@ -626,10 +676,14 @@ A few things to remember: by default. If you have more than 20 issues, start scrolling down and the next 20 appear. -## Enable or disable GraphQL-based sidebar for group issue boards **(PREMIUM SELF)** +### Enable or disable GraphQL-based issue boards **(FREE SELF)** -GraphQL-based sidebar for group issue boards is under development and not ready for production use. -It is deployed behind a feature flag that is **disabled by default**. +NOTE: +When enabling GraphQL-based issue boards, you must also enable the +[new add list form](#enable-or-disable-new-add-list-form). + +GraphQL-based issue boards is not ready for production use. +It is deployed behind a feature flag that is **disabled by default** as of GitLab 13.12. [GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md) can enable it. @@ -685,3 +739,22 @@ To disable it: ```ruby Feature.disable(:iteration_board_lists) ``` + +### Enable or disable multi-selecting issue cards **(FREE SELF)** + +Multi-selecting issue cards is under development and not ready for production use. It is +deployed behind a feature flag that is **disabled by default**. +[GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md) +can enable it. + +To enable it: + +```ruby +Feature.enable(:board_multi_select) +``` + +To disable it: + +```ruby +Feature.disable(:board_multi_select) +``` diff --git a/doc/user/project/issues/confidential_issues.md b/doc/user/project/issues/confidential_issues.md index 25357a1db0b..ed15d7a2e63 100644 --- a/doc/user/project/issues/confidential_issues.md +++ b/doc/user/project/issues/confidential_issues.md @@ -77,11 +77,11 @@ least [Reporter access](../../permissions.md#project-members-permissions). Howev confidential issues, but can only view the ones that they created themselves. Confidential issues are also hidden in search results for unprivileged users. -For example, here's what a user with Maintainer and Guest access sees in the -project's search results respectively. +For example, here's what a user with the [Maintainer role](../../permissions.md) and Guest access +sees in the project's search results respectively. -| Maintainer access | Guest access | -| :-----------: | :----------: | +| Maintainer role | Guest access | +|:---------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------| | ![Confidential issues search by maintainer](img/confidential_issues_search_master.png) | ![Confidential issues search by guest](img/confidential_issues_search_guest.png) | ## Merge Requests for Confidential Issues diff --git a/doc/user/project/issues/csv_export.md b/doc/user/project/issues/csv_export.md index 5c95665230a..29adf396d4d 100644 --- a/doc/user/project/issues/csv_export.md +++ b/doc/user/project/issues/csv_export.md @@ -4,41 +4,46 @@ group: unassigned 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 --- -# Export Issues to CSV +# Export issues to CSV **(FREE)** > Moved to GitLab Free in 12.10. -Issues can be exported as CSV from GitLab and are sent to your default notification email as an attachment. +You can export issues as CSV files from GitLab, which are sent to your default +notification email address as an attachment. -## Overview +**Export Issues to CSV** enables you and your team to export all the data +collected from issues into a **[comma-separated values](https://en.wikipedia.org/wiki/Comma-separated_values)** (CSV) +file, which stores tabular data in plain text. -**Export Issues to CSV** enables you and your team to export all the data collected from issues into -a **[comma-separated values](https://en.wikipedia.org/wiki/Comma-separated_values)** (CSV) file, -which stores tabular data in plain text. +> _CSVs are a handy way of getting data from one program to another where one +program cannot read the other ones normal output._ [Ref](https://www.quora.com/What-is-a-CSV-file-and-its-uses) -> _CSVs are a handy way of getting data from one program to another where one program cannot read the other ones normal output._ [Ref](https://www.quora.com/What-is-a-CSV-file-and-its-uses) +CSV files can be used with any plotter or spreadsheet-based program, such as +Microsoft Excel, Open Office Calc, , +or Google Sheets. -CSV files can be used with any plotter or spreadsheet-based program, such as Microsoft Excel, -Open Office Calc, or Google Spreadsheets. +Here are some of the uses of exporting issues as CSV files: -## Use cases - -Among numerous use cases for exporting issues for CSV, we can name a few: - -- Make a snapshot of issues for offline analysis or to communicate with other teams who may not be in GitLab -- Create diagrams, graphs, and charts from the CSV data -- Present the data in any other format for auditing or sharing reasons -- Import the issues elsewhere to a system outside of GitLab -- Long-term issues' data analysis with multiple snapshots created along the time -- Use the long-term data to gather relevant feedback given in the issues, and improve your product based on real metrics +- Make a snapshot of issues for offline analysis or to communicate with other + teams who may not be in GitLab. +- Create diagrams, graphs, and charts from the CSV data. +- Present the data in any other format for auditing or sharing reasons. +- Import the issues elsewhere to a system outside of GitLab. +- Long-term issues' data analysis with multiple snapshots created along the + time. +- Use the long-term data to gather relevant feedback given in the issues, and + improve your product based on real metrics. ## Choosing which issues to include -After selecting a project, from the issues page you can narrow down which issues to export using the search bar, along with the All/Open/Closed tabs. All issues returned are exported, including those not shown on the first page. +After selecting a project, from the issues page you can narrow down which +issues to export using the search bar, along with the All/Open/Closed tabs. All +issues returned are exported, including those not shown on the first page. ![CSV export button](img/csv_export_button_v12_9.png) -GitLab asks you to confirm the number of issues and email address for the export, after which the email is prepared. +GitLab asks you to confirm the number of issues and email address for the +export, after which the email is prepared. ![CSV export modal dialog](img/csv_export_modal.png) @@ -48,33 +53,41 @@ Exported issues are always sorted by `Issue ID`. ## Format -Data is encoded with a comma as the column delimiter, with `"` used to quote fields if needed, and newlines to separate rows. The first row contains the headers, which are listed in the following table along with a description of the values: - -| Column | Description | -|---------|-------------| -| Issue ID | Issue `iid` | -| URL | A link to the issue on GitLab | -| Title | Issue `title` | -| State | `Open` or `Closed` | -| Description | Issue `description` | -| Author | Full name of the issue author | -| Author Username | Username of the author, with the `@` symbol omitted | -| Assignee | Full name of the issue assignee | +Data is encoded with a comma as the column delimiter, with `"` used to quote +fields if needed, and newlines to separate rows. The first row contains the +headers, which are listed in the following table along with a description of +the values: + +| Column | Description | +|-------------------|-------------| +| Issue ID | Issue `iid` | +| URL | A link to the issue on GitLab | +| Title | Issue `title` | +| State | `Open` or `Closed` | +| Description | Issue `description` | +| Author | Full name of the issue author | +| Author Username | Username of the author, with the `@` symbol omitted | +| Assignee | Full name of the issue assignee | | Assignee Username | Username of the author, with the `@` symbol omitted | -| Confidential | `Yes` or `No` | -| Locked | `Yes` or `No` | -| Due Date | Formatted as `YYYY-MM-DD` | -| Created At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` | -| Updated At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` | -| Milestone | Title of the issue milestone | -| Weight | Issue weight | -| Labels | Title of any labels joined with a `,` | -| Time Estimate | [Time estimate](../time_tracking.md#estimates) in seconds | -| Time Spent | [Time spent](../time_tracking.md#time-spent) in seconds | -| Epic ID | ID of the parent epic **(ULTIMATE)**, introduced in 12.7 | -| Epic Title | Title of the parent epic **(ULTIMATE)**, introduced in 12.7 | +| Confidential | `Yes` or `No` | +| Locked | `Yes` or `No` | +| Due Date | Formatted as `YYYY-MM-DD` | +| Created At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` | +| Updated At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` | +| Milestone | Title of the issue milestone | +| Weight | Issue weight | +| Labels | Title of any labels joined with a `,` | +| Time Estimate | [Time estimate](../time_tracking.md#estimates) in seconds | +| Time Spent | [Time spent](../time_tracking.md#time-spent) in seconds | +| Epic ID | ID of the parent epic **(ULTIMATE)**, introduced in 12.7 | +| Epic Title | Title of the parent epic **(ULTIMATE)**, introduced in 12.7 | ## Limitations - Export Issues to CSV is not available at the Group's Issues List. -- As the issues are sent as an email attachment, there is a limit on how much data can be exported. Currently this limit is 15MB to ensure successful delivery across a range of email providers. If this limit is reached we suggest narrowing the search before export, perhaps by exporting open and closed issues separately. +- Issues are sent as an email attachment, with a 15 MB export limit to ensure + successful delivery across a range of email providers. If you reach the limit, + we suggest narrowing the search before export, perhaps by exporting open and + closed issues separately. +- CSV files are plain text files. This means that the exported CSV file doesn't + contain any issue attachments. diff --git a/doc/user/project/issues/csv_import.md b/doc/user/project/issues/csv_import.md index de7a36a4886..02a4f6a4384 100644 --- a/doc/user/project/issues/csv_import.md +++ b/doc/user/project/issues/csv_import.md @@ -4,7 +4,7 @@ group: Import 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 --- -# Importing issues from CSV +# Importing issues from CSV **(FREE)** > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/23532) in GitLab 11.7. diff --git a/doc/user/project/issues/design_management.md b/doc/user/project/issues/design_management.md index 2a003e68a73..e0eb35d1e49 100644 --- a/doc/user/project/issues/design_management.md +++ b/doc/user/project/issues/design_management.md @@ -48,7 +48,7 @@ If the requirements are not met, the **Designs** tab displays a message to the u Files uploaded must have a file extension of either `png`, `jpg`, `jpeg`, `gif`, `bmp`, `tiff`, `ico`, `webp`, or `svg`. -Support for [PDF](https://gitlab.com/gitlab-org/gitlab/issues/32811) is planned for a future release. +Support for [PDF](https://gitlab.com/gitlab-org/gitlab/-/issues/32811) is planned for a future release. ## Limitations @@ -219,11 +219,14 @@ There are two ways to resolve/unresolve a Design thread: ![Resolve checkbox](img/resolve_design-discussion_checkbox_v13_1.png) +Resolving a discussion thread also marks any pending to-do items related to notes +inside the thread as done. This is applicable only for to-do items owned by the user triggering the action. + Note that your resolved comment pins disappear from the Design to free up space for new discussions. However, if you need to revisit or find a resolved discussion, all of your resolved threads are available in the **Resolved Comment** area at the bottom of the right sidebar. -## Add to dos for designs +## Add to-do items for designs > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/198439) in GitLab 13.4. > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/245074) in GitLab 13.5. diff --git a/doc/user/project/issues/due_dates.md b/doc/user/project/issues/due_dates.md index a82823947dc..5b8dd617ab9 100644 --- a/doc/user/project/issues/due_dates.md +++ b/doc/user/project/issues/due_dates.md @@ -4,13 +4,9 @@ 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/#assignments --- -# Due dates +# Due dates **(FREE)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/3614) in GitLab 8.7. - -Please read through the [GitLab Issue Documentation](index.md) for an overview on GitLab Issues. - -Due dates can be used in issues to keep track of deadlines and make sure features are +Due dates can be used in [issues](index.md) to keep track of deadlines and make sure features are shipped on time. Users need at least [Reporter permissions](../../permissions.md) to be able to edit the due date. All users with permission to view the issue can view the due date. @@ -24,11 +20,11 @@ the user setting the due date. ![Create a due date](img/due_dates_create.png) -You can also set a due date via the issue sidebar. Expand the -sidebar and click **Edit** to pick a due date or remove the existing one. +You can also set a due date by using the issue sidebar. Expand the +sidebar and select **Edit** to pick a due date or remove the existing one. Changes are saved immediately. -![Edit a due date via the sidebar](img/due_dates_edit_sidebar.png) +![Edit a due date with the sidebar](img/due_dates_edit_sidebar.png) The last way to set a due date is by using [quick actions](../quick_actions.md), directly in an issue's description or comment: @@ -52,9 +48,9 @@ of the issue. Like the due date, the "day before the due date" is determined by server's timezone. Issues with due dates can also be exported as an iCalendar feed. The URL of the -feed can be added to calendar applications. The feed is accessible by clicking -on the **Subscribe to calendar** button on the following pages: +feed can be added to calendar applications. The feed is accessible by selecting +the **Subscribe to calendar** button on the following pages: -- on the **Assigned Issues** page that is linked on the right-hand side of the GitLab header -- on the **Project Issues** page -- on the **Group Issues** page +- The **Assigned Issues** page linked on the right side of the GitLab header +- The **Project Issues** page +- The **Group Issues** page diff --git a/doc/user/project/issues/img/issue_type_change_v13_12.png b/doc/user/project/issues/img/issue_type_change_v13_12.png new file mode 100644 index 00000000000..3b4864ffbbb Binary files /dev/null and b/doc/user/project/issues/img/issue_type_change_v13_12.png differ diff --git a/doc/user/project/issues/issue_data_and_actions.md b/doc/user/project/issues/issue_data_and_actions.md index 3af6c528db9..13f5beadb16 100644 --- a/doc/user/project/issues/issue_data_and_actions.md +++ b/doc/user/project/issues/issue_data_and_actions.md @@ -221,7 +221,7 @@ merge request is also listed here. You can award emojis to issues. You can select the "thumbs up" and "thumbs down", or the gray "smiley-face" to choose from the list of available -[GitLab Flavored Markdown Emoji](../../markdown.md#emoji). +[GitLab Flavored Markdown Emoji](../../markdown.md#emojis). NOTE: Posting "+1" as a comment in a thread spams all subscribed participants of that issue, diff --git a/doc/user/project/issues/managing_issues.md b/doc/user/project/issues/managing_issues.md index 9e8a75743a7..35573518626 100644 --- a/doc/user/project/issues/managing_issues.md +++ b/doc/user/project/issues/managing_issues.md @@ -315,10 +315,15 @@ issues are still displayed, but are not closed automatically. ![disable issue auto close - settings](img/disable_issue_auto_close.png) +The automatic issue closing is also disabled in a project if the project has the issue tracker +disabled. If you want to enable automatic issue closing, make sure to +[enable GitLab Issues](../settings/index.md#sharing-and-permissions). + This only applies to issues affected by new merge requests or commits. Already -closed issues remain as-is. Disabling automatic issue closing only affects merge -requests *in* the project and does not prevent other projects from closing it -via cross-project issues. +closed issues remain as-is. +If issue tracking is enabled, disabling automatic issue closing only applies to merge requests +attempting to automatically close issues within the same project. +Merge requests in other projects can still close another project's issues. #### Customizing the issue closing pattern **(FREE SELF)** @@ -326,9 +331,20 @@ In order to change the default issue closing pattern, GitLab administrators must [`gitlab.rb` or `gitlab.yml` file](../../../administration/issue_closing_pattern.md) of your installation. +## Change the issue type + +Users with [developer permission](../../permissions.md) +can change an issue's type. To do this, edit the issue and select an issue type from the +**Issue type** selector menu: + +- [Issue](index.md) +- [Incident](../../../operations/incident_management/index.md) + +![Change the issue type](img/issue_type_change_v13_12.png) + ## Deleting issues -Users with [project owner permission](../../permissions.md) can delete an issue by +Users with the [Owner role](../../permissions.md) can delete an issue by editing it and selecting **Delete issue**. ![delete issue - button](img/delete_issue_v13_11.png) diff --git a/doc/user/project/labels.md b/doc/user/project/labels.md index 0cb5b5d993e..e7adc045e98 100644 --- a/doc/user/project/labels.md +++ b/doc/user/project/labels.md @@ -282,4 +282,4 @@ To resolve the duplication, [in GitLab 13.2](https://gitlab.com/gitlab-org/gitla and later, some duplicate labels have `_duplicate` appended to their titles. You can safely change these labels' titles if you prefer. -For details of the original problem, see [issue 30390](https://gitlab.com/gitlab-org/gitlab/issues/30390). +For details of the original problem, see [issue 30390](https://gitlab.com/gitlab-org/gitlab/-/issues/30390). diff --git a/doc/user/project/members/img/access_requests_management_v13_9.png b/doc/user/project/members/img/access_requests_management_v13_9.png deleted file mode 100644 index b7883e9d134..00000000000 Binary files a/doc/user/project/members/img/access_requests_management_v13_9.png and /dev/null differ diff --git a/doc/user/project/members/img/add_user_email_accept_v13_9.png b/doc/user/project/members/img/add_user_email_accept_v13_9.png deleted file mode 100644 index a6b303e05ca..00000000000 Binary files a/doc/user/project/members/img/add_user_email_accept_v13_9.png and /dev/null differ diff --git a/doc/user/project/members/img/add_user_email_ready_v13_8.png b/doc/user/project/members/img/add_user_email_ready_v13_8.png deleted file mode 100644 index a610b46a176..00000000000 Binary files a/doc/user/project/members/img/add_user_email_ready_v13_8.png and /dev/null differ diff --git a/doc/user/project/members/img/add_user_email_search_v13_8.png b/doc/user/project/members/img/add_user_email_search_v13_8.png deleted file mode 100644 index 934cf19bd3d..00000000000 Binary files a/doc/user/project/members/img/add_user_email_search_v13_8.png and /dev/null differ diff --git a/doc/user/project/members/img/withdraw_access_request_button.png b/doc/user/project/members/img/withdraw_access_request_button.png deleted file mode 100644 index e5a8fe0b356..00000000000 Binary files a/doc/user/project/members/img/withdraw_access_request_button.png and /dev/null differ diff --git a/doc/user/project/members/index.md b/doc/user/project/members/index.md index 7dc1a9c612f..ab33ff0f6d8 100644 --- a/doc/user/project/members/index.md +++ b/doc/user/project/members/index.md @@ -1,10 +1,10 @@ --- -stage: none -group: unassigned +stage: Manage +group: Access 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 --- -# Members of a project +# Members of a project **(FREE)** Members are the users and groups who have access to your project. @@ -17,12 +17,13 @@ to perform actions. Prerequisite: -- You must have maintainer or owner [permissions](../../permissions.md). +- You must have the [Maintainer or Owner role](../../permissions.md). To add a user to a project: 1. Go to your project and select **Members**. -1. On the **Invite member** tab, under **GitLab member of Email address**, type the username or email address. +1. On the **Invite member** tab, under **GitLab member or Email address**, type the username or email address. + In GitLab 13.11 and later, you can [replace this form with a modal window](#add-a-member-modal-window). 1. Select a [role](../../permissions.md). 1. Optional. Choose an expiration date. On that date, the user can no longer access the project. 1. Select **Invite**. @@ -30,15 +31,24 @@ To add a user to a project: If the user has a GitLab account, they are added to the members list. If you used an email address, the user receives an email. +If the invitation is not accepted, GitLab sends reminder emails two, +five, and ten days later. Unaccepted invites are automatically +deleted after 90 days. + +If the user does not have a GitLab account, they are prompted to create an account +using the email address the invitation was sent to. + ## Add groups to a project -When you assign a group to a project, each user in the group gets access to the project, -based on the role they're assigned in the group. However, the user's access is also -limited by the maximum role you choose when you invite the group. +When you add a group to a project, each user in the group gets access to the project. +Each user's access is based on: + +- The role they're assigned in the group. +- The maximum role you choose when you invite the group. Prerequisite: -- You must have maintainer or owner [permissions](../../permissions.md). +- You must have the [Maintainer or Owner role](../../permissions.md). To add groups to a project: @@ -61,7 +71,7 @@ retain the same permissions as the project you import them from. Prerequisite: -- You must have maintainer or owner [permissions](../../permissions.md). +- You must have the [Maintainer or Owner role](../../permissions.md). To import users: @@ -74,20 +84,39 @@ A success message is displayed and the new members are now displayed in the list ## Inherited membership -When your project belongs to a group, group members inherit the membership and permission -level for the project from the group. +When your project belongs to a group, group members inherit their role +from the group. ![Project members page](img/project_members_v13_9.png) -From the image above, we can deduce the following things: +In this example: + +- Three members have access to the project. +- **User 0** is a Reporter and has inherited their role from the **demo** group, + which contains the project. +- **User 1** belongs directly to the project. In the **Source** column, they are listed + as a **Direct member**. +- **Administrator** is the [Owner](../../permissions.md) and member of all groups. + They have inherited their role from the **demo** group. + +## Remove a member from a project + +If a user is a direct member of a project, you can remove them. +If membership is inherited from a parent group, then the member can be removed only from the parent +group itself. -- There are 3 members that have access to the project. -- User0 is a Reporter and has inherited their permissions from group `demo` - which contains current project. -- User1 is shown as a **Direct member** in the **Source** column, therefore they belong directly - to the project we're inspecting. -- Administrator is the Owner and member of **all** groups and for that reason, - there is an indication of an ancestor group and inherited Owner permissions. +Prerequisite: + +- You must have the [Owner role](../../permissions.md). +- Optional. Unassign the member from all issues and merge requests that + are assigned to them. + +To remove a member from a project: + +1. Go to your project and select **Members**. +1. Next to the project member you want to remove, select **Remove member** **{remove}**. +1. Optional. In the confirmation box, select the **Also unassign this user from related issues and merge requests** checkbox. +1. Select **Remove member**. ## Filter and sort members @@ -95,22 +124,21 @@ From the image above, we can deduce the following things: > - [Improved](https://gitlab.com/groups/gitlab-org/-/epics/4901) in GitLab 13.9. > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/299954) in GitLab 13.10. -The following sections illustrate how you can filter and sort members in a project. To view these options, -navigate to your desired project, go to **Members**, and include the noted search terms. - -### Membership filter - -By default, inherited and direct members are displayed. The membership filter can be used to display only inherited or only direct members. +You can filter and sort members in a project. -#### Display inherited members +### Display inherited members -To display inherited members, include `Membership` `=` `Inherited` in the search text box. +1. Go to your project and select **Members**. +1. In the **Filter members** box, select `Membership` `=` `Inherited`. +1. Press Enter. ![Project members filter inherited](img/project_members_filter_inherited_v13_9.png) -#### Display direct members +### Display direct members -To display direct members, include `Membership` `=` `Direct` in the search text box. +1. Go to your project and select **Members**. +1. In the **Filter members** box, select `Membership` `=` `Direct`. +1. Press Enter. ![Project members filter direct](img/project_members_filter_direct_v13_9.png) @@ -126,36 +154,41 @@ You can sort members by **Account**, **Access granted**, **Max role**, or **Last ![Project members sort](img/project_members_sort_v13_9.png) -## Invite people using their e-mail address +## Request access to a project -NOTE: -In GitLab 13.11, you can [replace this form with a modal window](#add-a-member-modal-window). +GitLab users can request to become a member of a project. -If a user you want to give access to doesn't have an account on your GitLab -instance, you can invite them just by typing their e-mail address in the -user search field. +1. Go to the project you'd like to be a member of. +1. By the project name, select **Request Access**. -![Invite user by mail](img/add_user_email_search_v13_8.png) +![Request access button](img/request_access_button.png) -As you can imagine, you can mix inviting multiple people and adding existing -GitLab users to the project. +An email is sent to the most recently active project maintainers. +Up to ten project maintainers are notified. +Any project maintainer can approve or decline the request. -![Invite user by mail ready to submit](img/add_user_email_ready_v13_8.png) +If a project does not have any maintainers, the notification is sent to the +most recently active owners of the project's group. + +If you change your mind before your request is approved, select +**Withdraw Access Request**. -Once done, hit **Add users to project** and watch that there is a new member -with the e-mail address we used above. From there on, you can resend the -invitation, change their access level, or even delete them. +## Prevent users from requesting access to a project -![Invite user members list](img/add_user_email_accept_v13_9.png) +You can prevent users from requesting access to a project. + +Prerequisite: -While unaccepted, the system automatically sends reminder emails on the second, fifth, -and tenth day after the invitation was initially sent. +- You must be the project owner. -After the user accepts the invitation, they are prompted to create a new -GitLab account using the same e-mail address the invitation was sent to. +1. Go to the project and select **Settings > General**. +1. Expand the **Visibility, project features, permissions** section. +1. Under **Project visibility**, select **Users can request access**. +1. Select **Save changes**. -NOTE: -Unaccepted invites are automatically deleted after 90 days. +## Share a project with a group + +Instead of adding users one by one, you can [share a project with an entire group](share_project_with_groups.md). ### Add a member modal window @@ -172,10 +205,10 @@ This feature might not be available to you. Check the **version history** note a In GitLab 13.11, you can optionally replace the form to add a member with a modal window. To add a member after enabling this feature: -1. Go to your project's page. -1. In the left sidebar, go to **Members**, and then select **Invite members**. -1. Enter an email address, and select a role permission for this user. -1. (Optional) Select an **Access expiration date**. +1. Go to your project and select **Members**. +1. Select **Invite members**. +1. Enter an email address and select a role. +1. Optional. Select an **Access expiration date**. 1. Select **Invite**. ### Enable or disable modal window **(FREE SELF)** @@ -196,65 +229,3 @@ To disable it: ```ruby Feature.disable(:invite_members_group_modal) ``` - -## Project membership and requesting access - -Project owners can : - -- Allow non-members to request access to the project. -- Prevent non-members from requesting access. - -To configure this, go to the project settings and click on **Allow users to request access**. - -GitLab users can request to become a member of a project. Go to the project you'd -like to be a member of and click the **Request Access** button on the right -side of your screen. - -![Request access button](img/request_access_button.png) - -After access is requested: - -- Up to ten project maintainers are notified of the request via email. - Email is sent to the most recently active project maintainers. -- Any project maintainer can approve or decline the request on the members page. - -NOTE: -If a project does not have any maintainers, the notification is sent to the -most recently active owners of the project's group. - -![Manage access requests](img/access_requests_management_v13_9.png) - -If you change your mind before your request is approved, just click the -**Withdraw Access Request** button. - -![Withdraw access request button](img/withdraw_access_request_button.png) - -## Share project with group - -Alternatively, you can [share a project with an entire group](share_project_with_groups.md) instead of adding users one by one. - -## Remove a member from the project - -Only users with permissions of [Owner](../../permissions.md#group-members-permissions) can manage -project members. - -You can remove a user from the project if the given member has a direct membership in the project. -If membership is inherited from a parent group, then the member can be removed only from the parent -group itself. - -When removing a member, you can decide whether to unassign the user from all issues and merge -requests they are currently assigned or leave the assignments as they are. - -- **Unassigning the removed member** from all issues and merge requests might be helpful when a user - is leaving a private project and you wish to revoke their access to any issues and merge requests - they are assigned. -- **Keeping the issues and merge requests assigned** might be helpful for projects that accept public - contributions where a user doesn't have to be a member to be able to contribute to issues and - merge requests. - -To remove a member from a project: - -1. Go to your project and select **Members**. -1. Next to the project member you want to remove, select **Remove member** **{remove}**. -1. Optional. In the confirmation box, select the **Also unassign this user from related issues and merge requests** checkbox. -1. Select **Remove member**. diff --git a/doc/user/project/members/share_project_with_groups.md b/doc/user/project/members/share_project_with_groups.md index 085e4db0b94..caef5ef60b7 100644 --- a/doc/user/project/members/share_project_with_groups.md +++ b/doc/user/project/members/share_project_with_groups.md @@ -60,7 +60,7 @@ To share a project after enabling this feature: 1. Go to your project's page. 1. In the left sidebar, go to **Members**, and then select **Invite a group**. -1. Select a group, and select a **Max access level**. +1. Select a group, and select a **Max role**. 1. (Optional) Select an **Access expiration date**. 1. Select **Invite**. diff --git a/doc/user/project/merge_requests/accessibility_testing.md b/doc/user/project/merge_requests/accessibility_testing.md index 09770bd447d..76aff18b00d 100644 --- a/doc/user/project/merge_requests/accessibility_testing.md +++ b/doc/user/project/merge_requests/accessibility_testing.md @@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: reference, howto --- -# Accessibility Testing +# Accessibility testing **(FREE)** > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25144) in GitLab 12.8. @@ -17,11 +17,11 @@ impact of pending code changes. GitLab uses [pa11y](https://pa11y.org/), a free and open source tool for measuring the accessibility of web sites, and has built a simple -[CI job template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml). +[CI job template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml). This job outputs accessibility violations, warnings, and notices for each page analyzed to a file called `accessibility`. -## Accessibility Merge Request widget +## Accessibility merge request widget > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/39425) in GitLab 13.0 behind the disabled [feature flag](../../../administration/feature_flags.md) `:accessibility_report_view`. > - [Feature Flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/217372) in GitLab 13.1. @@ -29,7 +29,7 @@ analyzed to a file called `accessibility`. In addition to the report artifact that is created, GitLab will also show the Accessibility Report in the merge request widget area: -![Accessibility Merge Request Widget](img/accessibility_mr_widget_v13_0.png) +![Accessibility merge request widget](img/accessibility_mr_widget_v13_0.png) ## Configure Accessibility Testing @@ -38,7 +38,7 @@ on your code with GitLab CI/CD using the [GitLab Accessibility Docker image](htt For GitLab 12.9 and later, to define the `a11y` job, you must [include](../../../ci/yaml/README.md#includetemplate) the -[`Accessibility.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml) +[`Accessibility.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml) included with your GitLab installation, as shown below. Add the following to your `.gitlab-ci.yml` file: @@ -67,7 +67,7 @@ For GitLab 12.10 and earlier, the [artifact generated is named `accessibility.js NOTE: For GitLab versions earlier than 12.9, you can use `include:remote` and use a -link to the [current template in `master`](https://gitlab.com/gitlab-org/gitlab/-/raw/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml) +link to the [current template in the default branch](https://gitlab.com/gitlab-org/gitlab/-/raw/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml) NOTE: The job definition provided by the template does not support Kubernetes yet. diff --git a/doc/user/project/merge_requests/allow_collaboration.md b/doc/user/project/merge_requests/allow_collaboration.md index 5917d67c398..63d5119c1b4 100644 --- a/doc/user/project/merge_requests/allow_collaboration.md +++ b/doc/user/project/merge_requests/allow_collaboration.md @@ -24,19 +24,17 @@ of the merge request. ## Enabling commit edits from upstream members In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/23308), -this setting is enabled by default. It can be changed by users with Developer -permissions to the source project. Once enabled, upstream members can -retry the pipelines and jobs of the merge request: +this setting is enabled by default. It can be changed by users with the +Developer [role](../../permissions.md) for the source project. After it's enabled, +upstream members can retry the pipelines and jobs of the merge request: -1. While creating or editing a merge request, select the checkbox **Allow - commits from members who can merge to the target branch**. +1. While creating or editing a merge request, scroll to **Contribution** and + then select the **Allow commits from members who can merge to the target branch**. + checkbox. +1. Finish creating your merge request. - ![Enable contribution](img/allow_collaboration.png) - -1. Once the merge request is created, you can see that commits from members who - can merge to the target branch are allowed. - - ![Check that contribution is enabled](img/allow_collaboration_after_save.png) +After you create the merge request, the merge request widget displays a message: +**Members who can merge are allowed to add commits.** ## Pushing to the fork as the upstream member @@ -48,41 +46,39 @@ Assuming that: - The forked project URL is `git@gitlab.com:thedude/awesome-project.git`. - The branch of the merge request is `update-docs`. -Here's how the process would look like: - -1. First, you need to get the changes that the merge request has introduced. - Click the **Check out branch** button that has some pre-populated - commands that you can run. - - ![Check out branch button](img/checkout_button.png) +To find and work with the changes from the fork: -1. Use the copy button to copy the first command and paste them - in your terminal: +1. Open the merge request page, and select the **Overview** tab. +1. Scroll to the merge request widget, and select **Check out branch**: + ![Check out branch button](img/commit-button_v13_12.png) +1. In the modal window, select **{copy-to-clipboard}** (**Copy**) for step 1 + to copy the `git fetch` and `git checkout` instructions to your clipboard. + Paste the commands (which look like this example) into your terminal: ```shell git fetch git@gitlab.com:thedude/awesome-project.git update-docs git checkout -b thedude-awesome-project-update-docs FETCH_HEAD ``` - This fetches the branch of the forked project and then create a local branch + These commands fetch the branch from the forked project, and create a local branch based off the fetched branch. -1. Make any changes you want and commit. -1. Push to the forked project: +1. Make your changes to the local copy of the branch, and then commit them. +1. In your terminal, push your local changes back up to the forked project. This + command pushes the local branch `thedude-awesome-project-update-docs` to the + `update-docs` branch of the `git@gitlab.com:thedude/awesome-project.git` repository: ```shell git push git@gitlab.com:thedude/awesome-project.git thedude-awesome-project-update-docs:update-docs ``` - Note the colon (`:`) between the two branches. The above command pushes the - local branch `thedude-awesome-project-update-docs` to the - `update-docs` branch of the `git@gitlab.com:thedude/awesome-project.git` repository. + Note the colon (`:`) between the two branches. ## Troubleshooting ### Pipeline status unavailable from MR page of forked project -When a user forks a project, the permissions on the forked copy are not copied over +When a user forks a project, the permissions of the forked copy are not copied from the original project. The creator of the fork must grant permissions to the forked copy before members in the upstream project can view or merge the changes in the merge request. diff --git a/doc/user/project/merge_requests/approvals/index.md b/doc/user/project/merge_requests/approvals/index.md index ac48e44da52..3c47c2af344 100644 --- a/doc/user/project/merge_requests/approvals/index.md +++ b/doc/user/project/merge_requests/approvals/index.md @@ -42,7 +42,7 @@ for more control of the level of oversight and security your project needs, incl - [Require security team approval.](settings.md#security-approvals-in-merge-requests) You can configure your merge request approval rules and settings through the GitLab -user interface or [with the API](../../../../api/merge_request_approvals.md). +user interface or with the [Merge request approvals API](../../../../api/merge_request_approvals.md). ## Approve a merge request @@ -97,36 +97,6 @@ Without the approvals, the work cannot merge. Required approvals enable multiple - [Require approval from a security team](../../../application_security/index.md#security-approvals-in-merge-requests) before merging code that could introduce a vulnerability. **(ULTIMATE)** -## Notify external services **(ULTIMATE)** - -> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3869) in GitLab Ultimate 13.10. -> - [Deployed behind a feature flag](../../../feature_flags.md), disabled by default. -> - Disabled on GitLab.com. -> - Not recommended for production use. -> - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](../../../../api/merge_request_approvals.md#enable-or-disable-external-project-level-mr-approvals). **(ULTIMATE SELF)** - -WARNING: -This feature might not be available to you. Check the **version history** note above for details. - -You can create an external approval rule to integrate approvals with third-party tools. -When users create, change, or close merge requests, GitLab sends a notification. -The users of the third-party tools can then approve merge requests from outside of GitLab. - -With this integration, you can integrate with third-party workflow tools, like -[ServiceNow](https://www.servicenow.co.uk/), or the custom tool of your choice. -You can modify your external approval rules -[by using the REST API](../../../../api/merge_request_approvals.md#external-project-level-mr-approvals). - -The lack of an external approval doesn't block the merging of a merge request. - -When [approval rule overrides](settings.md#prevent-overrides-of-default-approvals) are allowed, -changes to default approval rules will **not** be applied to existing -merge requests, except for changes to the [target branch](rules.md#approvals-for-protected-branches) -of the rule. - -To learn more about use cases, feature discovery, and development timelines, -see the [External API approval rules epic](https://gitlab.com/groups/gitlab-org/-/epics/3869). - ## Related links - [Merge request approvals API](../../../../api/merge_request_approvals.md) diff --git a/doc/user/project/merge_requests/approvals/rules.md b/doc/user/project/merge_requests/approvals/rules.md index 32f0160771f..1e4b0f659ee 100644 --- a/doc/user/project/merge_requests/approvals/rules.md +++ b/doc/user/project/merge_requests/approvals/rules.md @@ -5,7 +5,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated type: reference, concepts --- -# Merge request approval rules +# Merge request approval rules **(FREE)** Approval rules define how many [approvals](index.md) a merge request must receive before it can be merged, and which users should do the approving. You can define approval rules: @@ -144,7 +144,7 @@ approve in these ways: [**Prevent committers approval**](settings.md#prevent-committers-from-approving-their-own-work) project setting. -### Code owners as eligible approvers +### Code owners as eligible approvers **(PREMIUM)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/7933) in GitLab 11.5. > - Moved to GitLab Premium in 13.9. @@ -162,7 +162,7 @@ You can also [require code owner approval](../../protected_branches.md#protected-branches-approval-by-code-owners) for protected branches. **(PREMIUM)** -## Merge request approval segregation of duties +## Merge request approval segregation of duties **(PREMIUM)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40491) in GitLab 13.4. > - Moved to GitLab Premium in 13.9. diff --git a/doc/user/project/merge_requests/approvals/settings.md b/doc/user/project/merge_requests/approvals/settings.md index 8769f6a7470..97e4b7da396 100644 --- a/doc/user/project/merge_requests/approvals/settings.md +++ b/doc/user/project/merge_requests/approvals/settings.md @@ -5,7 +5,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated type: reference, concepts --- -# Merge request approval settings +# Merge request approval settings **(FREE)** You can configure the settings for [merge request approvals](index.md) to ensure the approval rules meet your use case. You can also configure diff --git a/doc/user/project/merge_requests/authorization_for_merge_requests.md b/doc/user/project/merge_requests/authorization_for_merge_requests.md index aa43d34cdd9..930df65f3fc 100644 --- a/doc/user/project/merge_requests/authorization_for_merge_requests.md +++ b/doc/user/project/merge_requests/authorization_for_merge_requests.md @@ -16,17 +16,17 @@ There are two main ways to have a merge request flow with GitLab: With the protected branch flow everybody works within the same GitLab project. -The project maintainers get Maintainer access and the regular developers get -Developer access. +The project maintainers get the [Maintainer role](../../permissions.md) and the regular developers +get Developer access. -The maintainers mark the authoritative branches as 'Protected'. +Maintainers mark the authoritative branches as 'Protected'. -The developers push feature branches to the project and create merge requests +Developers push feature branches to the project and create merge requests to have their feature branches reviewed and merged into one of the protected branches. -By default, only users with Maintainer access can merge changes into a protected -branch. +By default, only users with the [Maintainer role](../../permissions.md) can merge changes into a +protected branch. **Advantages** @@ -39,14 +39,14 @@ branch. ## Forking workflow -With the forking workflow the maintainers get Maintainer access and the regular +With the forking workflow, maintainers get the [Maintainer role](../../permissions.md) and regular developers get Reporter access to the authoritative repository, which prohibits them from pushing any changes to it. Developers create forks of the authoritative project and push their feature branches to their own forks. -To get their changes into master they need to create a merge request across +To get their changes into the default branch, they need to create a merge request across forks. **Advantages** diff --git a/doc/user/project/merge_requests/browser_performance_testing.md b/doc/user/project/merge_requests/browser_performance_testing.md index b33919c7fbe..d11ad53a9d6 100644 --- a/doc/user/project/merge_requests/browser_performance_testing.md +++ b/doc/user/project/merge_requests/browser_performance_testing.md @@ -40,18 +40,18 @@ Consider the following workflow: ## How browser performance testing works First, define a job in your `.gitlab-ci.yml` file that generates the -[Browser Performance report artifact](../../../ci/yaml/README.md#artifactsreportsperformance). +[Browser Performance report artifact](../../../ci/yaml/README.md#artifactsreportsbrowser_performance). GitLab then checks this report, compares key performance metrics for each page between the source and target branches, and shows the information in the merge request. -For an example Performance job, see +For an example Browser Performance job, see [Configuring Browser Performance Testing](#configuring-browser-performance-testing). NOTE: If the Browser Performance report has no data to compare, such as when you add the Browser Performance job in your `.gitlab-ci.yml` for the very first time, -the Browser Performance report widget doesn't show. It must have run at least -once on the target branch (`master`, for example), before it displays in a +the Browser Performance report widget doesn't display. It must have run at least +once on the target branch (`main`, for example), before it displays in a merge request targeting that branch. ![Browser Performance Widget](img/browser_performance_testing.png) @@ -70,27 +70,26 @@ using Docker-in-Docker. include: template: Verify/Browser-Performance.gitlab-ci.yml - performance: + browser_performance: variables: URL: https://example.com ``` WARNING: -In GitLab 14.0 and later, the job [is scheduled to be renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/225914) -from `performance` to `browser_performance`. +In GitLab 13.12 and earlier, the job [was named](https://gitlab.com/gitlab-org/gitlab/-/issues/225914) `performance`. The above example: -- Creates a `performance` job in your CI/CD pipeline and runs sitespeed.io against the webpage you +- Creates a `browser_performance` job in your CI/CD pipeline and runs sitespeed.io against the webpage you defined in `URL` to gather key metrics. - Uses a template that doesn't work with Kubernetes clusters. If you are using a Kubernetes cluster, - use [`template: Jobs/Browser-Performance-Testing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Browser-Performance-Testing.gitlab-ci.yml) + use [`template: Jobs/Browser-Performance-Testing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Browser-Performance-Testing.gitlab-ci.yml) instead. - Uses a CI/CD template that is included in all GitLab installations since 12.4. If you are using GitLab 12.3 or earlier, you must [add the configuration manually](#gitlab-versions-132-and-earlier). The template uses the [GitLab plugin for sitespeed.io](https://gitlab.com/gitlab-org/gl-performance), -and it saves the full HTML sitespeed.io report as a [Browser Performance report artifact](../../../ci/yaml/README.md#artifactsreportsperformance) +and it saves the full HTML sitespeed.io report as a [Browser Performance report artifact](../../../ci/yaml/README.md#artifactsreportsbrowser_performance) that you can later download and analyze. This implementation always takes the latest Browser Performance artifact available. If [GitLab Pages](../pages/index.md) is enabled, you can view the report directly in your browser. @@ -108,7 +107,7 @@ makes on the given URL, and change the version: include: template: Verify/Browser-Performance.gitlab-ci.yml -performance: +browser_performance: variables: URL: https://www.sitespeed.io/ SITESPEED_VERSION: 13.2.0 @@ -127,7 +126,7 @@ if the `Total Score` metric degrades by 5 points or more: include: template: Verify/Browser-Performance.gitlab-ci.yml -performance: +browser_performance: variables: URL: https://example.com DEGRADATION_THRESHOLD: 5 @@ -140,13 +139,13 @@ The `Total Score` metric is based on sitespeed.io's [coach performance score](ht The above CI YAML configuration is great for testing against static environments, and it can be extended for dynamic environments, but a few extra steps are required: -1. The `performance` job should run after the dynamic environment has started. +1. The `browser_performance` job should run after the dynamic environment has started. 1. In the `review` job: 1. Generate a URL list file with the dynamic URL. 1. Save the file as an artifact, for example with `echo $CI_ENVIRONMENT_URL > environment_url.txt` in your job's `script`. 1. Pass the list as the URL environment variable (which can be a URL or a file containing URLs) - to the `performance` job. + to the `browser_performance` job. 1. You can now run the sitespeed.io container against the desired hostname and paths. @@ -176,7 +175,7 @@ review: except: - master -performance: +browser_performance: dependencies: - review variables: @@ -191,7 +190,7 @@ GitLab version: - In 13.2 the feature was renamed from `Performance` to `Browser Performance` with additional template CI/CD variables. -- In GitLab 12.4 [a job template was made available](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Verify/Browser-Performance.gitlab-ci.yml). +- In GitLab 12.4 [a job template was made available](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Verify/Browser-Performance.gitlab-ci.yml). - For 11.5 to 12.3 no template is available and the job has to be defined manually as follows: ```yaml diff --git a/doc/user/project/merge_requests/changes.md b/doc/user/project/merge_requests/changes.md index adcf4518209..e594f8048e3 100644 --- a/doc/user/project/merge_requests/changes.md +++ b/doc/user/project/merge_requests/changes.md @@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: index, reference --- -# Changes tab in merge requests +# Changes tab in merge requests **(FREE)** The **Changes** tab on a [merge request](index.md), below the main merge request details and next to the discussion tab, shows the changes to files between branches or commits. This view of changes to a @@ -70,21 +70,6 @@ merge request: This change overrides the choice you made in your user preferences and persists until you clear your browser's cookies or change this behavior again. -## Merge requests commit navigation - -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18140) in GitLab 13.0. - -To seamlessly navigate among commits in a merge request: - -1. Select the **Commits** tab. -1. Select a commit to open it in the single-commit view. -1. Navigate through the commits by either: - - - Selecting **Prev** and **Next** buttons below the tab buttons. - - Using the X and C keyboard shortcuts. - -![Merge requests commit navigation](img/commit_nav_v13_11.png) - ## Incrementally expand merge request diffs By default, the diff shows only the parts of a file which are changed. @@ -106,10 +91,6 @@ specific commit page. ![MR diff](img/merge_request_diff.png) -NOTE: -You can append `?w=1` while on the diffs page of a merge request to ignore any -whitespace changes. - ## Mark files as viewed > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/51513) in GitLab 13.9. @@ -149,3 +130,42 @@ To disable it: ```ruby Feature.disable(:local_file_reviews) ``` + +## Show merge request conflicts in diff + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/232484) in GitLab 13.5. +> - [Deployed behind a feature flag](../../feature_flags.md), disabled by default. +> - Disabled on GitLab.com. +> - Not recommended for production use. +> - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-merge-request-conflicts-in-diff). **(FREE SELF)** + +This in-development feature might not be available for your use. There can be +[risks when enabling features still in development](../../feature_flags.md#risks-when-enabling-features-still-in-development). +Refer to this feature's version history for more details. + +To avoid displaying the changes that are already on target branch in the diff, +we compare the merge request's source branch with HEAD of the target branch. + +When there are conflicts between the source and target branch, we show the +conflicts on the merge request diff as well: + +![Example of a conflict shown in a merge request diff](img/conflict_ui_v14_0.png) + +### Enable or disable merge request conflicts in diff **(FREE SELF)** + +Merge request conflicts in diff is under development and not ready for production use. It is +deployed behind a feature flag that is **disabled by default**. +[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md) +can enable it. + +To enable it: + +```ruby +Feature.enable(:display_merge_conflicts_in_diff) +``` + +To disable it: + +```ruby +Feature.disable(:display_merge_conflicts_in_diff) +``` diff --git a/doc/user/project/merge_requests/cherry_pick_changes.md b/doc/user/project/merge_requests/cherry_pick_changes.md index eaeef12444e..710638128f3 100644 --- a/doc/user/project/merge_requests/cherry_pick_changes.md +++ b/doc/user/project/merge_requests/cherry_pick_changes.md @@ -63,10 +63,7 @@ git cherry-pick -m 2 7a39eb0 ### Cherry-pick into a project > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/21268) in GitLab 13.11. -> - It's [deployed behind a feature flag](../../feature_flags.md), disabled by default. -> - It's disabled on GitLab.com. -> - It's not recommended for production use. -> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-cherry-picking-into-a-project). **(FREE SELF)** +> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/324154) in GitLab 14.0 WARNING: This feature might not be available to you. Check the **version history** note above for details. @@ -81,24 +78,10 @@ merge request is from a fork: 1. (Optional) Select **Start a new merge request** if you're ready to create a merge request. 1. Click **Cherry-pick**. -### Enable or disable cherry-picking into a project **(FREE SELF)** +## Related links -Cherry-picking into a project is under development and not ready for production use. It is -deployed behind a feature flag that is **disabled by default**. -[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md) -can enable it. - -To enable it: - -```ruby -Feature.enable(:pick_into_project) -``` - -To disable it: - -```ruby -Feature.disable(:pick_into_project) -``` +- The [Commits API](../../../api/commits.md) enables you to add custom messages + to changes you cherry-pick through the API.