diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-10-16 21:09:04 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-10-16 21:09:04 +0300 |
commit | b58ab6c33c0369e402109d5388d4f6f73b7eb2bb (patch) | |
tree | b4f09ac9cf03dd11328050ab1e26df5fad351695 /doc/user | |
parent | 3940f59a61a749824aa4425ebdcaed6f3ed601f2 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/user')
35 files changed, 108 insertions, 116 deletions
diff --git a/doc/user/admin_area/settings/project_integration_management.md b/doc/user/admin_area/settings/project_integration_management.md index 750bec1d91a..748d608676d 100644 --- a/doc/user/admin_area/settings/project_integration_management.md +++ b/doc/user/admin_area/settings/project_integration_management.md @@ -6,74 +6,53 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Project integration management -Project integrations can be configured and enabled by project administrators. As a GitLab instance administrator, you can set default configuration parameters for a given integration that all projects can inherit and use, enabling the integration for all projects that are not already using custom settings. +Project integrations can be configured and enabled by project administrators. As a GitLab instance +administrator, you can set default configuration parameters for a given integration that all projects +can inherit and use. This enables the integration for all projects that are not already using custom +settings. -You can update these default settings at any time, changing the settings used for all -projects that are set to use instance-level or group-level defaults. Updating the -default settings also enables the integration for all projects that didn't have it -already enabled. +You can update these default settings at any time, changing the settings used for all projects that +are set to use instance-level defaults. Updating the default settings also enables the integration +for all projects that didn't have it already enabled. -Only the complete settings for an integration can be inherited. Per-field inheritance is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137). +Only the complete settings for an integration can be inherited. Per-field inheritance is +[planned](https://gitlab.com/groups/gitlab-org/-/epics/2137) as is +[group-level management](https://gitlab.com/groups/gitlab-org/-/epics/2543) of integration settings. ## Manage instance-level default settings for a project integration **(CORE ONLY)** > [Introduced in](https://gitlab.com/groups/gitlab-org/-/epics/2137) GitLab 13.3. 1. Navigate to **Admin Area > Settings > Integrations**. -1. Select an integration. +1. Select a project integration. 1. Enter configuration details and click **Save changes**. CAUTION: **Caution:** -This may affect all or most of the groups and projects on your GitLab instance. Please review the details below. +This may affect all or most of the projects on your GitLab instance. Please review the details +below. If this is the first time you are setting up instance-level settings for an integration: -- The integration is enabled for all groups and projects that do not already have this integration configured if you have the **Enable integration** toggle turned on in the instance-level settings. -- Groups and projects that already have the integration configured are not affected, but can choose to use the inherited settings at any time. +- The integration is enabled for all projects that don't already have this integration configured, + if you have the **Enable integration** toggle turned on in the instance-level settings. +- Projects that already have the integration configured are not affected, but can choose to use the + inherited settings at any time. When you make further changes to the instance defaults: -- They are immediately applied to all groups and projects that have the integration set to use default settings. -- They are immediately applied to newer groups and projects, created since you last - saved defaults for the integration. If your instance-level default setting has the - **Enable integration** toggle turned on, the integration is automatically enabled for - all such groups and projects. -- Groups and projects with custom settings selected for the integration are not immediately affected and may choose to use the latest defaults at any time. +- They are immediately applied to all projects that have the integration set to use default settings. +- They are immediately applied to newer projects, created since you last saved defaults for the + integration. If your instance-level default setting has the **Enable integration** toggle turned + on, the integration is automatically enabled for all such projects. +- Projects with custom settings selected for the integration are not immediately affected and may + choose to use the latest defaults at any time. Only the complete settings for an integration can be inherited. Per-field inheritance is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137). This would allow -administrators to update settings inherited by groups and projects without enabling the -integration on all non-configured groups and projects by default. +administrators to update settings inherited by projects without enabling the +integration on all non-configured projects by default. -## Manage group-level default settings for a project integration - -> [Introduced in](https://gitlab.com/groups/gitlab-org/-/epics/2543) GitLab 13.5. - -1. Navigate to the group's **Settings > Integrations**. -1. Select an integration. -1. Enter configuration details and click **Save changes**. - -CAUTION: **Caution:** -This may affect all or most of the subgroups and projects belonging to the group. Please review the details below. - -If this is the first time you are setting up group-level settings for an integration: - -- The integration is enabled for all subgroups and projects belonging to the group that do not already have this integration configured if you have the **Enable integration** toggle turned on in the group-level settings. -- Subgroups and projects that already have the integration configured are not affected, but can choose to use the inherited settings at any time. - -When you make further changes to the group defaults: - -- They are immediately applied to all subgroups and projects belonging to the group that have the integration set to use default settings. -- They are immediately applied to newer subgroups and projects, created since you last saved defaults for the integration. - - If your group-level default setting has the **Enable integration** toggle turned on, the integration is automatically enabled for all such subgroups and projects. -- Subgroups and projects with custom settings selected for the integration are not immediately affected and may choose to use the latest defaults at any time. - -Only the complete settings for an integration can be inherited. Per-field inheritance -is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137). This would allow -administrators to update settings inherited by subgroups and projects without enabling the -integration on all non-configured groups and projects by default. - -## Use instance-level or group-level default settings for a project integration +## Use instance-level default settings for a project integration 1. Navigate to **Project > Settings > Integrations**. 1. Choose the integration you want to enable or update. @@ -81,9 +60,9 @@ integration on all non-configured groups and projects by default. 1. Ensure the toggle is set to **Enable integration**. 1. Click **Save changes**. -## Use custom settings for a group or project integration +## Use custom settings for a project integration -1. Navigate to project or group's **Settings > Integrations**. +1. Navigate to project's **Settings > Integrations**. 1. Choose the integration you want to enable or update. 1. From the drop-down, select **Use custom settings**. 1. Ensure the toggle is set to **Enable integration** and enter all required settings. diff --git a/doc/user/group/index.md b/doc/user/group/index.md index 92ca7033dcb..2c838724cb3 100644 --- a/doc/user/group/index.md +++ b/doc/user/group/index.md @@ -742,7 +742,6 @@ To enable prevent project forking: - **Audit Events**: View [Audit Events](../../administration/audit_events.md) for the group. **(STARTER ONLY)** - **Pipelines quota**: Keep track of the [pipeline quota](../admin_area/settings/continuous_integration.md) for the group. -- **Integrations**: Configure [integrations](../admin_area/settings/project_integration_management.md) for your group. #### Storage usage quota **(STARTER)** diff --git a/doc/user/markdown.md b/doc/user/markdown.md index e0612bad3b8..8b65da4ab94 100644 --- a/doc/user/markdown.md +++ b/doc/user/markdown.md @@ -82,7 +82,7 @@ We flag any significant differences between Redcarpet and CommonMark Markdown in If you have a large volume of Markdown files, it can be tedious to determine if they display correctly or not. You can use the -[diff_redcarpet_cmark](https://gitlab.com/digitalmoksha/diff_redcarpet_cmark) +[`diff_redcarpet_cmark`](https://gitlab.com/digitalmoksha/diff_redcarpet_cmark) tool (not an officially supported product) to generate a list of files and the differences between how RedCarpet and CommonMark render the files. It gives an indication if anything needs to be changed - often nothing needs diff --git a/doc/user/packages/container_registry/index.md b/doc/user/packages/container_registry/index.md index 3152966a6b3..baadd3c91a7 100644 --- a/doc/user/packages/container_registry/index.md +++ b/doc/user/packages/container_registry/index.md @@ -67,7 +67,7 @@ Images follow this naming convention: ``` If your project is `gitlab.example.com/mynamespace/myproject`, for example, -then your image must be named `gitlab.example.com/mynamespace/myproject/my-app` at a mimimum. +then your image must be named `gitlab.example.com/mynamespace/myproject/my-app` at a minimum. You can append additional names to the end of an image name, up to three levels deep. diff --git a/doc/user/packages/workflows/monorepo.md b/doc/user/packages/workflows/monorepo.md index 94a2b8b8dba..f20f3427ac5 100644 --- a/doc/user/packages/workflows/monorepo.md +++ b/doc/user/packages/workflows/monorepo.md @@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Monorepo package management workflows Oftentimes, one project or Git repository may contain multiple different -subprojects or submodules that all get packaged and published individually. +sub-projects or submodules that all get packaged and published individually. ## Publishing different packages to the parent project @@ -36,9 +36,9 @@ as well as `Foo`. Following the instructions in the [GitLab NPM registry documentation](../npm_registry/index.md), publishing `MyProject` consists of modifying the `package.json` file with a -`publishConfig` section, as well as either modifying your local NPM config with +`publishConfig` section, as well as either modifying your local NPM configuration with CLI commands like `npm config set`, or saving a `.npmrc` file in the root of the -project specifying these config settings. +project specifying these configuration settings. If you follow the instructions you can publish `MyProject` by running `npm publish` from the root directory. @@ -65,7 +65,7 @@ A package is associated with a project on GitLab, but the package does not need to be associated with the code in that project. Notice when configuring NPM or Maven, you only use the `Project ID` to set the registry URL that the package is to be uploaded to. If you set this to any project that you have -access to and update any other config similarly depending on the package type, +access to and update any other configuration similarly depending on the package type, your packages are published to that project. This means you can publish multiple packages to one project, even if their code does not exist in the same place. See the [project registry workflow documentation](./project_registry.md) diff --git a/doc/user/permissions.md b/doc/user/permissions.md index 92d89a303d2..2e9f36360c6 100644 --- a/doc/user/permissions.md +++ b/doc/user/permissions.md @@ -399,7 +399,7 @@ Administrators can add members with a "minimal access" role to a parent group. S automatically have access to projects and subgroups underneath. To support such access, administrators must explicitly add these "minimal access" users to the specific subgroups/projects. Users with minimal access can list the group in the UI and through the API. However, they cannot see -details such as projects or subgroups. They do not have access to the group's page or list any of itssubgroups or projects. +details such as projects or subgroups. They do not have access to the group's page or list any of its subgroups or projects. ## Project features diff --git a/doc/user/profile/preferences.md b/doc/user/profile/preferences.md index f84fc1ae898..61944bb9d0b 100644 --- a/doc/user/profile/preferences.md +++ b/doc/user/profile/preferences.md @@ -84,7 +84,7 @@ The default syntax theme is White, and you can choose among 5 different themes: [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2389) in 13.0, the theme you choose also applies to the [Web IDE](../project/web_ide/index.md)'s code editor and [Snippets](../snippets.md). The themes are available only in the Web IDE file editor, except for the [dark theme](https://gitlab.com/gitlab-org/gitlab/-/issues/209808) and -the [solarized dark theme](https://gitlab.com/gitlab-org/gitlab/-/issues/219228), +the [Solarized dark theme](https://gitlab.com/gitlab-org/gitlab/-/issues/219228), which apply to the entire Web IDE screen. ## Behavior @@ -131,15 +131,9 @@ You can choose between 2 options: ### Project overview content -The project overview content setting allows you to choose what content you want to +The **Project overview content** setting allows you to choose what content you want to see on a project’s home page. -You can choose between 3 options: - -- Files and Readme (default) -- Readme -- Activity - ### Tab width You can set the displayed width of tab characters across various parts of diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md index 00be3ea54b3..5816bdf782b 100644 --- a/doc/user/project/clusters/index.md +++ b/doc/user/project/clusters/index.md @@ -252,7 +252,7 @@ GitLab CI/CD build environment. | `KUBE_NAMESPACE` | The namespace associated with the project's deployment service account. In the format `<project_name>-<project_id>-<environment>`. For GitLab-managed clusters, a matching namespace is automatically created by GitLab in the cluster. If your cluster was created before GitLab 12.2, the default `KUBE_NAMESPACE` is set to `<project_name>-<project_id>`. | | `KUBE_CA_PEM_FILE` | Path to a file containing PEM data. Only present if a custom CA bundle was specified. | | `KUBE_CA_PEM` | (**deprecated**) Raw PEM data. Only if a custom CA bundle was specified. | -| `KUBECONFIG` | Path to a file containing `kubeconfig` for this deployment. CA bundle would be embedded if specified. This config also embeds the same token defined in `KUBE_TOKEN` so you likely will only need this variable. This variable name is also automatically picked up by `kubectl` so you won't actually need to reference it explicitly if using `kubectl`. | +| `KUBECONFIG` | Path to a file containing `kubeconfig` for this deployment. CA bundle would be embedded if specified. This configuration also embeds the same token defined in `KUBE_TOKEN` so you likely will only need this variable. This variable name is also automatically picked up by `kubectl` so you won't actually need to reference it explicitly if using `kubectl`. | | `KUBE_INGRESS_BASE_DOMAIN` | From GitLab 11.8, this variable can be used to set a domain per cluster. See [cluster domains](#base-domain) for more information. | ### Custom namespace diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md index d70d4e26ee0..836df77a79b 100644 --- a/doc/user/project/clusters/serverless/index.md +++ b/doc/user/project/clusters/serverless/index.md @@ -789,7 +789,7 @@ or with other versions of Python. kubectl edit gateway knative-ingress-gateway --namespace knative-serving ``` - Update the gateway to include the following tls: section and configuration: + Update the gateway to include the following `tls:` section and configuration: ```shell tls: diff --git a/doc/user/project/code_intelligence.md b/doc/user/project/code_intelligence.md index f56673e69b7..d0c5a24826a 100644 --- a/doc/user/project/code_intelligence.md +++ b/doc/user/project/code_intelligence.md @@ -58,9 +58,9 @@ relevant language. | Language | Implementation | |---|---| -| Go | [sourcegraph/lsif-go](https://github.com/sourcegraph/lsif-go) | -| JavaScript | [sourcegraph/lsif-node](https://github.com/sourcegraph/lsif-node) | -| TypeScript | [sourcegraph/lsif-node](https://github.com/sourcegraph/lsif-node) | +| Go | [`sourcegraph/lsif-go`](https://github.com/sourcegraph/lsif-go) | +| JavaScript | [`sourcegraph/lsif-node`](https://github.com/sourcegraph/lsif-node) | +| TypeScript | [`sourcegraph/lsif-node`](https://github.com/sourcegraph/lsif-node) | View a complete list of [available LSIF indexers](https://lsif.dev/#implementations-server) on their website and refer to their documentation to see how to generate an LSIF file for your specific language. diff --git a/doc/user/project/code_owners.md b/doc/user/project/code_owners.md index 7c71d18e5be..4ae3d5ec032 100644 --- a/doc/user/project/code_owners.md +++ b/doc/user/project/code_owners.md @@ -75,7 +75,6 @@ be used for merge request approvals: - As [merge request eligible approvers](merge_requests/merge_request_approvals.md#code-owners-as-eligible-approvers). - As required approvers for [protected branches](protected_branches.md#protected-branches-approval-by-code-owners). **(PREMIUM)** -NOTE: **Note:** Developer or higher [permissions](../permissions.md) are required in order to approve a merge request. @@ -93,12 +92,14 @@ to specify the actual owners and granular permissions. Using Code Owners in conjunction with [Protected Branches](protected_branches.md#protected-branches-approval-by-code-owners) will prevent any user who is not specified in the `CODEOWNERS` file from pushing -changes for the specified files/paths, even if their role is included in the +changes for the specified files/paths, except those included in the **Allowed to push** column. This allows for a more inclusive push strategy, as administrators don't have to restrict developers from pushing directly to the protected branch, but can restrict pushing to certain files where a review by Code Owners is required. +[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35097) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.5, users and groups who are allowed to push to protected branches do not require a merge request to merge their feature branches. Thus, they can skip merge request approval rules, Code Owners included. + ## The syntax of Code Owners files Files can be specified using the same kind of patterns you would use diff --git a/doc/user/project/deploy_boards.md b/doc/user/project/deploy_boards.md index 536d5950228..3c6494d5f1a 100644 --- a/doc/user/project/deploy_boards.md +++ b/doc/user/project/deploy_boards.md @@ -85,7 +85,7 @@ To display the Deploy Boards for a specific [environment](../../ci/environments/ [`kubernetes`](https://docs.gitlab.com/runner/executors/kubernetes.html) executor. 1. Configure the [Kubernetes integration](clusters/index.md) in your project for the cluster. The Kubernetes namespace is of particular note as you will need it - for your deployment scripts (exposed by the `KUBE_NAMESPACE` env variable). + for your deployment scripts (exposed by the `KUBE_NAMESPACE` environment variable). 1. Ensure Kubernetes annotations of `app.gitlab.com/env: $CI_ENVIRONMENT_SLUG` and `app.gitlab.com/app: $CI_PROJECT_PATH_SLUG` are applied to the deployments, replica sets, and pods, where `$CI_ENVIRONMENT_SLUG` and diff --git a/doc/user/project/file_lock.md b/doc/user/project/file_lock.md index 6fd33901621..46c2e211d57 100644 --- a/doc/user/project/file_lock.md +++ b/doc/user/project/file_lock.md @@ -69,7 +69,7 @@ brew install git-lfs ``` Once installed, **open your local repository in a terminal window** and -install Git LFS in your repo. If you're sure that LFS is already installed, +install Git LFS in your repository. If you're sure that LFS is already installed, you can skip this step. If you're unsure, re-installing it won't do any harm: ```shell @@ -159,7 +159,7 @@ command line interface, file locks can be created for any file. ### View exclusively-locked files To list all the files locked with LFS locally, open a terminal window in your -repo and run: +repository and run: ```shell git lfs locks @@ -189,7 +189,7 @@ Suggested workflow for shared projects: 1. Lock the file. 1. Edit the file. 1. Commit your changes. -1. Push to the repo. +1. Push to the repository. 1. Get your changes reviewed, approved, and merged. 1. Unlock the file. diff --git a/doc/user/project/import/gemnasium.md b/doc/user/project/import/gemnasium.md index f21ec26bdef..2d0caa7d46e 100644 --- a/doc/user/project/import/gemnasium.md +++ b/doc/user/project/import/gemnasium.md @@ -96,7 +96,7 @@ back to both GitLab and GitHub when completed. The mirroring is pull-only by default, so you may create or update the file on GitHub: - ![Edit gitlab-ci.yml file](img/gemnasium/edit_gitlab-ci.png) + ![Edit YAML file](img/gemnasium/edit_gitlab-ci.png) 1. Once your file has been committed, a new pipeline will be automatically triggered if your file is valid: diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md index be1641f8b16..6c0105aaded 100644 --- a/doc/user/project/import/github.md +++ b/doc/user/project/import/github.md @@ -101,7 +101,7 @@ If you are using a self-managed GitLab instance or if you are importing from Git 1. From the top navigation bar, click **+** and select **New project**. 1. Select the **Import project** tab and then select **GitHub**. 1. Select the first button to **List your GitHub repositories**. You are redirected to a page on [GitHub](https://github.com) to authorize the GitLab application. -1. Click **Authorize gitlabhq**. You are redirected back to GitLab's Import page and all of your GitHub repositories are listed. +1. Click **Authorize GitlabHQ**. You are redirected back to GitLab's Import page and all of your GitHub repositories are listed. 1. Continue on to [selecting which repositories to import](#selecting-which-repositories-to-import). ### Using a GitHub token @@ -119,7 +119,7 @@ If you are not using the GitHub integration, you can still perform an authorizat 1. Go to <https://github.com/settings/tokens/new> 1. Enter a token description. -1. Select the repo scope. +1. Select the repository scope. 1. Click **Generate token**. 1. Copy the token hash. 1. Go back to GitLab and provide the token to the GitHub importer. @@ -136,10 +136,10 @@ your GitHub repositories are listed. 1. Select the **Import** button next to any number of repositories, or select **Import all repositories**. Additionally, you can filter projects by name. If filter is applied, **Import all repositories** only imports matched repositories. 1. The **Status** column shows the import status of each repository. You can choose to leave the page open and it will - update in realtime or you can return to it later. + update in real-time or you can return to it later. 1. Once a repository has been imported, click its GitLab path to open its GitLab URL. -![Github importer page](img/import_projects_from_github_importer_v12_3.png) +![GitHub importer page](img/import_projects_from_github_importer_v12_3.png) ## Mirroring and pipeline status sharing @@ -149,7 +149,7 @@ your imported repository in sync with its GitHub copy. Additionally, you can configure GitLab to send pipeline status updates back GitHub with the [GitHub Project Integration](../integrations/github.md). **(PREMIUM)** -If you import your project using [CI/CD for external repo](../../../ci/ci_cd_for_external_repos/index.md), then both +If you import your project using [CI/CD for external repository](../../../ci/ci_cd_for_external_repos/index.md), then both of the above are automatically configured. **(PREMIUM)** ## Improving the speed of imports on self-managed instances diff --git a/doc/user/project/import/index.md b/doc/user/project/import/index.md index 86b671c8371..a1c28cfa2b7 100644 --- a/doc/user/project/import/index.md +++ b/doc/user/project/import/index.md @@ -18,7 +18,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w 1. [From Perforce](perforce.md) 1. [From SVN](svn.md) 1. [From TFVC](tfvc.md) -1. [From repo by URL](repo_by_url.md) +1. [From repository by URL](repo_by_url.md) 1. [By uploading a manifest file (AOSP)](manifest.md) 1. [From Gemnasium](gemnasium.md) 1. [From Phabricator](phabricator.md) @@ -32,7 +32,7 @@ There is also the option of [connecting your external repository to get CI/CD be ## Migrating from self-managed GitLab to GitLab.com -If you only need to migrate Git repos, you can [import each project by URL](repo_by_url.md). Issues and merge requests can't be imported. +If you only need to migrate Git repositories, you can [import each project by URL](repo_by_url.md). Issues and merge requests can't be imported. If you want to retain all metadata like issues and merge requests, you can use the [import/export feature](../settings/import_export.md) to export projects from self-managed GitLab and import those projects into GitLab.com. diff --git a/doc/user/project/import/manifest.md b/doc/user/project/import/manifest.md index 60524f3cc69..ba1e2011d08 100644 --- a/doc/user/project/import/manifest.md +++ b/doc/user/project/import/manifest.md @@ -56,7 +56,7 @@ You can start the import with: 1. From your GitLab dashboard click **New project** 1. Switch to the **Import project** tab 1. Click on the **Manifest file** button -1. Provide GitLab with a manifest xml file +1. Provide GitLab with a manifest XML file 1. Select a group you want to import to (you need to create a group first if you don't have one) 1. Click **List available repositories**. At this point, you will be redirected to the import status page with projects list based on the manifest file. diff --git a/doc/user/project/import/perforce.md b/doc/user/project/import/perforce.md index dbc1c491493..4ccc34efe30 100644 --- a/doc/user/project/import/perforce.md +++ b/doc/user/project/import/perforce.md @@ -20,7 +20,7 @@ Git: it creates an integration record in their proprietary database for every file in the branch, regardless how many were actually changed. Whereas Git was implemented with a different architecture so that a single SHA acts as a pointer - to the state of the whole repo after the changes, making it very easy to branch. + to the state of the whole repository after the changes, making it very easy to branch. This is what made feature branching workflows so easy to adopt with Git. 1. Also, context switching between branches is much easier in Git. If your manager said 'You need to stop work on that new feature and fix this security diff --git a/doc/user/project/import/repo_by_url.md b/doc/user/project/import/repo_by_url.md index 9b5e43aae79..5c53b6eaf06 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/#designated-technical-writers --- -# Import project from repo by URL +# Import project from repository by URL You can import your existing repositories by providing the Git URL: @@ -16,4 +16,4 @@ You can import your existing repositories by providing the Git URL: 1. Click **Create project** to begin the import process 1. Once complete, you will be redirected to your newly created project -![Import project by repo URL](img/import_projects_from_repo_url.png) +![Import project by repository URL](img/import_projects_from_repo_url.png) diff --git a/doc/user/project/integrations/irker.md b/doc/user/project/integrations/irker.md index 443ca11be27..bb4a5b2b97f 100644 --- a/doc/user/project/integrations/irker.md +++ b/doc/user/project/integrations/irker.md @@ -14,8 +14,8 @@ See the project homepage for further information: <https://gitlab.com/esr/irker> ## Needed setup -You will first need an Irker daemon. You can download the Irker code from its -repository on <https://gitlab.com/esr/irker>: +You will first need an Irker daemon. You can download the Irker code +[from its repository](https://gitlab.com/esr/irker): ```shell git clone https://gitlab.com/esr/irker.git @@ -55,6 +55,6 @@ case, `Aorimn` is treated as a nick and no more as a channel name. Irker can also join password-protected channels. Users need to append `?key=thesecretpassword` to the channel name. When using this feature remember to **not** put the `#` sign in front of the channel name; failing to do so will -result on irker joining a channel literally named `#chan?key=password` henceforth +result on Irker joining a channel literally named `#chan?key=password` henceforth leaking the channel key through the `/whois` IRC command (depending on IRC server -configuration). This is due to a long standing irker bug. +configuration). This is due to a long standing Irker bug. diff --git a/doc/user/project/issue_board.md b/doc/user/project/issue_board.md index 5843272bb5a..bce40e9a838 100644 --- a/doc/user/project/issue_board.md +++ b/doc/user/project/issue_board.md @@ -368,7 +368,7 @@ If you're not able to do some of the things above, make sure you have the right ### First time using an issue board -> The automatic creation of the **To Do** and **Doing** lists was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202144) in GitLab 13.4. +> The automatic creation of the **To Do** and **Doing** lists was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202144) in GitLab 13.5. The first time you open an issue board, you are presented with the default lists (**Open**, **To Do**, **Doing**, and **Closed**). diff --git a/doc/user/project/merge_requests/accessibility_testing.md b/doc/user/project/merge_requests/accessibility_testing.md index f3a0aac9ff4..a07a155745e 100644 --- a/doc/user/project/merge_requests/accessibility_testing.md +++ b/doc/user/project/merge_requests/accessibility_testing.md @@ -55,7 +55,7 @@ include: ``` creates an `a11y` job in your CI/CD pipeline, runs -Pa11y against the webpages defined in `a11y_urls`, and builds an HTML report for each. +Pa11y against the web pages defined in `a11y_urls`, and builds an HTML report for each. The report for each URL is saved as an artifact that can be [viewed directly in your browser](../../../ci/pipelines/job_artifacts.md#browsing-artifacts). diff --git a/doc/user/project/merge_requests/load_performance_testing.md b/doc/user/project/merge_requests/load_performance_testing.md index daebd71e14f..2675f509eed 100644 --- a/doc/user/project/merge_requests/load_performance_testing.md +++ b/doc/user/project/merge_requests/load_performance_testing.md @@ -164,8 +164,8 @@ For example: 1. Capture the dynamic URL and save it into a `.env` file, e.g. `echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env`. 1. Set the `.env` file to be a [job artifact](../../../ci/pipelines/job_artifacts.md#job-artifacts). 1. In the `load_performance` job: - 1. Set it to depend on the review job, so it inherits the env file. - 1. Set the `K6_DOCKER_OPTIONS` variable with the [Docker cli option for env files](https://docs.docker.com/engine/reference/commandline/run/#set-environment-variables--e---env---env-file), for example `--env-file review.env`. + 1. Set it to depend on the review job, so it inherits the environment file. + 1. Set the `K6_DOCKER_OPTIONS` variable with the [Docker CLI option for environment files](https://docs.docker.com/engine/reference/commandline/run/#set-environment-variables--e---env---env-file), for example `--env-file review.env`. 1. Configure the k6 test script to use the environment variable in it's steps. Your `.gitlab-ci.yml` file might be similar to: diff --git a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md index 2e0c0d7aeeb..aef68e0e771 100644 --- a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md +++ b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md @@ -84,7 +84,7 @@ Click **Expand file** on any file to view the changes for that file. > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-file-by-file-diff-navigation). For larger merge requests it might sometimes be useful to review single files at a time. To enable, -from your avatar on the top-right navbar, click **Settings**, and go to **Preferences** on the left +from your avatar on the top-right navigation bar, click **Settings**, and go to **Preferences** on the left sidebar. Scroll down to the **Behavior** section and select **Show one file at a time on merge request's Changes tab**. Click **Save changes** to apply. diff --git a/doc/user/project/merge_requests/squash_and_merge.md b/doc/user/project/merge_requests/squash_and_merge.md index 69a0dd6e84f..68f5478038a 100644 --- a/doc/user/project/merge_requests/squash_and_merge.md +++ b/doc/user/project/merge_requests/squash_and_merge.md @@ -65,8 +65,8 @@ meaningful commit messages and: ## Enabling squash for a merge request Anyone who can create or edit a merge request can choose for it to be squashed -on the merge request form. Users can select or unselect the checkbox at the moment -they are creating the merge request: +on the merge request form. Users can select or clear the check box when they +create the merge request: ![Squash commits checkbox on edit form](img/squash_edit_form.png) diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md index 735d27ec04d..810538ab460 100644 --- a/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md +++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md @@ -30,6 +30,8 @@ to do it for you. To help you out, we've gathered some instructions on how to do that for the most popular hosting services: +<!-- vale gitlab.Spelling = NO --> + - [Amazon](https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html) - [Bluehost](https://www.bluehost.com/help/article/dns-management-add-edit-or-delete-dns-entries) - [Cloudflare](https://support.cloudflare.com/hc/en-us/articles/201720164-Creating-a-Cloudflare-account-and-adding-a-website) @@ -41,6 +43,8 @@ for the most popular hosting services: - [Media Temple](https://mediatemple.net/community/products/dv/204403794/how-can-i-change-the-dns-records-for-my-domain) - [Microsoft](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/bb727018(v=technet.10)) +<!-- vale gitlab.Spelling = YES --> + If your hosting service is not listed above, you can just try to search the web for `how to add dns record on <my hosting service>`. diff --git a/doc/user/project/pages/getting_started/new_or_existing_website.md b/doc/user/project/pages/getting_started/new_or_existing_website.md index 86f36447b93..f19334a1764 100644 --- a/doc/user/project/pages/getting_started/new_or_existing_website.md +++ b/doc/user/project/pages/getting_started/new_or_existing_website.md @@ -2,4 +2,4 @@ redirect_to: 'pages_ci_cd_template.md' --- -This document was moved to [pages_ci_cd_template.md](pages_ci_cd_template.md). +This document was moved to [another location](pages_ci_cd_template.md). diff --git a/doc/user/project/pages/getting_started/pages_forked_sample_project.md b/doc/user/project/pages/getting_started/pages_forked_sample_project.md index de9bd97b262..7dc3d2197b5 100644 --- a/doc/user/project/pages/getting_started/pages_forked_sample_project.md +++ b/doc/user/project/pages/getting_started/pages_forked_sample_project.md @@ -53,4 +53,4 @@ You can take some **optional** further steps: ![Change repo's path](../img/change_path_v12_10.png) - Now go to your SSG's configuration file and change the [base URL](../getting_started_part_one.md#urls-and-baseurls) - from `"project-name"` to `""`. The project name setting varies by SSG and may not be in the config file. + from `"project-name"` to `""`. The project name setting varies by SSG and may not be in the configuration file. diff --git a/doc/user/project/protected_branches.md b/doc/user/project/protected_branches.md index 09757bc73eb..7265fd330e3 100644 --- a/doc/user/project/protected_branches.md +++ b/doc/user/project/protected_branches.md @@ -185,6 +185,8 @@ When enabled, all merge requests targeting these branches will require approval by a Code Owner per matched rule before they can be merged. Additionally, direct pushes to the protected branch are denied if a rule is matched. +[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35097) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.5, users and groups who are allowed to push to protected branches do not require a merge request to merge their feature branches. Thus, they can skip merge request approval rules. + ## Running pipelines on protected branches The permission to merge or push to protected branches is used to define if a user can diff --git a/doc/user/project/repository/index.md b/doc/user/project/repository/index.md index 536cae263b8..5473439a162 100644 --- a/doc/user/project/repository/index.md +++ b/doc/user/project/repository/index.md @@ -86,7 +86,7 @@ according to the markup language. | [reStructuredText](https://docutils.sourceforge.io/rst.html) | `rst` | | [AsciiDoc](../../asciidoc.md) | `adoc`, `ad`, `asciidoc` | | [Textile](https://textile-lang.com/) | `textile` | -| [rdoc](http://rdoc.sourceforge.net/doc/index.html) | `rdoc` | +| [Rdoc](http://rdoc.sourceforge.net/doc/index.html) | `rdoc` | | [Org mode](https://orgmode.org/) | `org` | | [creole](http://www.wikicreole.org/) | `creole` | | [MediaWiki](https://www.mediawiki.org/wiki/MediaWiki) | `wiki`, `mediawiki` | @@ -234,7 +234,7 @@ lock your files to prevent any conflicting changes. ## Repository's API -You can access your repos via [repository API](../../../api/repositories.md). +You can access your repositories via [repository API](../../../api/repositories.md). ## Clone in Apple Xcode diff --git a/doc/user/project/requirements/img/requirement_create_v13_5.png b/doc/user/project/requirements/img/requirement_create_v13_5.png Binary files differnew file mode 100644 index 00000000000..ef1bab6e6d2 --- /dev/null +++ b/doc/user/project/requirements/img/requirement_create_v13_5.png diff --git a/doc/user/project/requirements/img/requirement_view_v13_5.png b/doc/user/project/requirements/img/requirement_view_v13_5.png Binary files differnew file mode 100644 index 00000000000..7fcb24a5e3b --- /dev/null +++ b/doc/user/project/requirements/img/requirement_view_v13_5.png diff --git a/doc/user/project/requirements/img/requirements_list_v13_1.png b/doc/user/project/requirements/img/requirements_list_v13_1.png Binary files differdeleted file mode 100644 index 0ebda571928..00000000000 --- a/doc/user/project/requirements/img/requirements_list_v13_1.png +++ /dev/null diff --git a/doc/user/project/requirements/img/requirements_list_v13_5.png b/doc/user/project/requirements/img/requirements_list_v13_5.png Binary files differnew file mode 100644 index 00000000000..19516e5e66e --- /dev/null +++ b/doc/user/project/requirements/img/requirements_list_v13_5.png diff --git a/doc/user/project/requirements/index.md b/doc/user/project/requirements/index.md index ffdb7e21472..f533f8807d2 100644 --- a/doc/user/project/requirements/index.md +++ b/doc/user/project/requirements/index.md @@ -7,7 +7,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Requirements Management **(ULTIMATE)** -> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2703) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.10. +> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2703) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.10. +> - The ability to add and edit a requirement's long description [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/224622) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.5. With requirements, you can set criteria to check your products against. They can be based on users, stakeholders, system, software, or anything else you find important to capture. @@ -22,7 +23,7 @@ When a feature is no longer necessary, you can [archive the related requirement] <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> For an overview, see [GitLab 12.10 Introduces Requirements Management](https://www.youtube.com/watch?v=uSS7oUNSEoU). -![requirements list view](img/requirements_list_v13_1.png) +![requirements list view](img/requirements_list_v13_5.png) ## Create a requirement @@ -32,31 +33,43 @@ can create a new requirement. To create a requirement: 1. From your project page, go to **{requirements}** **Requirements**. -1. Click **New requirement**. -1. Enter a descriptive title and click **Create requirement**. +1. Select **New requirement**. +1. Enter a title and description and select **Create requirement**. -You will see the newly created requirement on the top of the list, as the requirements -list is sorted by creation date in descending order. +![requirement create view](img/requirement_create_v13_5.png) + +You can see the newly created requirement on the top of the list, with the requirements +list being sorted by creation date, in descending order. + +## View a requirement + +You can view a requirement from the list by selecting it. + +![requirement view](img/requirement_view_v13_5.png) + +To edit a requirement while viewing it, select the **Edit** icon (**{pencil}**) +next to the requirement title. ## Edit a requirement -> - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/218607) ability to mark a requirement as Satisfied in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.5. +> The ability to mark a requirement as Satisfied [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/218607) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.5. You can edit a requirement (if you have the necessary privileges) from the requirements list page. To edit a requirement: -1. From the requirements list, click **Edit** (**{pencil}**). -1. Update the title in text input field. You can also mark a requirement as satisfied in the edit form by using the checkbox labeled "Satisfied". -1. Click **Save changes**. +1. From the requirements list, select the **Edit** icon (**{pencil}**). +1. Update the title and description in text input field. You can also mark a + requirement as satisfied in the edit form by using the check box **Satisfied**. +1. Select **Save changes**. ## Archive a requirement You can archive an open requirement (if you have the necessary privileges) while you're in the **Open** tab. -To archive a requirement, click **Archive** (**{archive}**). +To archive a requirement, select **Archive** (**{archive}**). As soon as a requirement is archived, it no longer appears in the **Open** tab. @@ -66,7 +79,7 @@ You can view the list of archived requirements in the **Archived** tab. ![archived requirements list](img/requirements_archived_list_view_v13_1.png) -To reopen an archived requirement, click **Reopen**. +To reopen an archived requirement, select **Reopen**. As soon as a requirement is reopened, it no longer appears in the **Archived** tab. @@ -82,7 +95,7 @@ You can search for a requirement from the requirements list page based on the fo To search for a requirement: 1. In a project, go to **{requirements}** **Requirements > List**. -1. Click the **Search or filter results** field. A dropdown menu appears. +1. Select the **Search or filter results** field. A dropdown menu appears. 1. Select the requirement author from the dropdown or enter plain text to search by requirement title. 1. Press <kbd>Enter</kbd> on your keyboard to filter the list. |