Commit f9778021 authored by Marcel Amirault's avatar Marcel Amirault Committed by Marcia Ramos

Docs: (EE Port) Fix all anchors in /user docs

parent d39ef1a1
This document was moved to [another location](../user/group/index.md#user-contribution-analysis-ees-eep)
---
redirect_to: '../user/group/index.md#user-contribution-analysis-starter'
---
This document was moved to [another location](../user/group/index.md#user-contribution-analysis-starter)
......@@ -15,7 +15,7 @@ templates are also available from this API endpoint.
Support will be added for [Issue and Merge Request templates](../user/project/description_templates.md)
in a future release.
Support for [Group-level file templates](../user/group/index.md#group-level-file-templates-premium)
Support for [Group-level file templates](../user/group/index.md#group-file-templates-premium)
**[PREMIUM]** was [added](https://gitlab.com/gitlab-org/gitlab-ee/issues/5987)
in GitLab 11.5
......
......@@ -156,7 +156,7 @@ Example response:
### Example with user / group level access
Elements in the `allowed_to_push` / `allowed_to_merge` / `allowed_to_unprotect` array should take the
form `{user_id: integer}`, `{group_id: integer}` or `{access_level: integer}`. Each user must have access to the project and each group must [have this project shared](../user/project/members/share_project_with_groups.md). These access levels allow [more granular control over protected branch access](../user/project/protected_branches.md#restricting-push-and-merge-access-to-certain-users) and were [added to the API in ][ee-3516] in GitLab 10.3 EE.
form `{user_id: integer}`, `{group_id: integer}` or `{access_level: integer}`. Each user must have access to the project and each group must [have this project shared](../user/project/members/share_project_with_groups.md). These access levels allow [more granular control over protected branch access](../user/project/protected_branches.md#restricting-push-and-merge-access-to-certain-users-starter) and were [added to the API in ][ee-3516] in GitLab 10.3 EE.
```bash
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" 'https://gitlab.example.com/api/v4/projects/5/protected_branches?name=*-stable&allowed_to_push%5B%5D%5Buser_id%5D=1'
......
......@@ -56,7 +56,7 @@ group. That way you can have different clusters for different environments,
like dev, staging, production, etc.
Add another cluster similar to the first one and make sure to
[set an environment scope](#environment-scopes) that will
[set an environment scope](#environment-scopes-premium) that will
differentiate the new cluster from the rest.
## Base domain
......
......@@ -171,7 +171,7 @@ The setting can set to "None", "Maintainers", or "Developers + Maintainers".
## Transfer projects into groups
Learn how to [transfer a project into a group](../project/index.md#transfer-an-existing-project-into-a-group).
Learn how to [transfer a project into a group](../project/settings/index.md#transferring-an-existing-project-into-another-namespace).
## Sharing a project with a group
......
# Subgroups
NOTE: **Note:**
[Introduced][ce-2772] in GitLab 9.0. Not available when using MySQL as external
database (support removed in GitLab 9.3 [due to performance reasons][issue]).
[Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/2772) in GitLab 9.0. Not available when using MySQL as external
database (support removed in GitLab 9.3 [due to performance reasons](https://gitlab.com/gitlab-org/gitlab-ce/issues/30472#note_27747600)).
With subgroups (aka nested groups or hierarchical groups) you can have
up to 20 levels of nested groups, which among other things can help you to:
......@@ -13,7 +13,7 @@ up to 20 levels of nested groups, which among other things can help you to:
- **Organize large projects.** For large projects, subgroups makes it
potentially easier to separate permissions on parts of the source code.
- **Make it easier to manage people and control visibility.** Give people
different [permissions][] depending on their group [membership](#membership).
different [permissions](../../permissions.md#group-members-permissions) depending on their group [membership](#membership).
## Database Requirements
......@@ -80,9 +80,9 @@ structure.
NOTE: **Note:**
You need to be an Owner of a group in order to be able to create a subgroup. For
more information check the [permissions table][permissions].
more information check the [permissions table](../../permissions.md#group-members-permissions).
For a list of words that are not allowed to be used as group names see the
[reserved names][reserved].
[reserved names](../../reserved_names.md).
Users can always create subgroups if they are explicitly added as an Owner to
a parent group even if group creation is disabled by an administrator in their
settings.
......@@ -176,6 +176,6 @@ Here's a list of what you can't do with subgroups:
`group/subgroup01/subgroup03`.
[ce-2772]: https://gitlab.com/gitlab-org/gitlab-ce/issues/2772
[permissions]: ../../permissions.md#group
[permissions]: ../../permissions.md#group-members-permissions
[reserved]: ../../reserved_names.md
[issue]: https://gitlab.com/gitlab-org/gitlab-ce/issues/30472#note_27747600
......@@ -39,7 +39,7 @@ From there, you can:
- Manage [personal access tokens](personal_access_tokens.md) to access your account via API and authorized applications
- Add and delete emails linked to your account
- Choose which email to use for notifications, web-based commits, and display on your public profile
- Manage [SSH keys](../../ssh/README.md#ssh) to access your account via SSH
- Manage [SSH keys](../../ssh/README.md) to access your account via SSH
- Manage your [preferences](preferences.md#syntax-highlighting-theme)
to customize your own GitLab experience
- [View your active sessions](active_sessions.md) and revoke any of them if necessary
......
......@@ -88,7 +88,7 @@ To add an existing Kubernetes cluster to your project:
1. Click **Add an existing Kubernetes cluster** and fill in the details:
- **Kubernetes cluster name** (required) - The name you wish to give the cluster.
- **Environment scope** (required) - The
[associated environment](#setting-the-environment-scope) to this cluster.
[associated environment](#setting-the-environment-scope-premium) to this cluster.
- **API URL** (required) -
It's the URL that GitLab uses to access the Kubernetes API. Kubernetes
exposes several APIs, we want the "base" URL that is common to all of them,
......@@ -473,7 +473,7 @@ project. That way you can have different clusters for different environments,
like dev, staging, production, etc.
Simply add another cluster, like you did the first time, and make sure to
[set an environment scope](#setting-the-environment-scope) that will
[set an environment scope](#setting-the-environment-scope-premium) that will
differentiate the new cluster with the rest.
## Setting the environment scope **[PREMIUM]**
......
......@@ -8,7 +8,7 @@ between the two, for more information consult your favorite search engine.
There are two approaches to SVN to Git migration:
1. [Git/SVN Mirror](#smooth-migration-with-a-git-svn-mirror-using-subgit) which:
1. [Git/SVN Mirror](#smooth-migration-with-a-gitsvn-mirror-using-subgit) which:
- Makes the GitLab repository to mirror the SVN project.
- Git and SVN repositories are kept in sync; you can use either one.
- Smoothens the migration process and allows to manage migration risks.
......
......@@ -158,7 +158,7 @@ and Git push/pull redirects.
Depending on the situation, different things apply.
When [renaming a user](../profile/index.md#changing-your-username),
[changing a group path](../group/index.md#changing-a-group-s-path) or [renaming a repository](settings/index.md#renaming-a-repository):
[changing a group path](../group/index.md#changing-a-groups-path) or [renaming a repository](settings/index.md#renaming-a-repository):
- Existing web URLs for the namespace and anything under it (e.g., projects) will
redirect to the new URLs.
......
......@@ -152,7 +152,7 @@ trigger word followed by <kbd>help</kbd>. Example: <samp>/gitlab help</samp>
## Permissions
The permissions to run the [available commands](#available-slash-commands) derive from
the [permissions you have on the project](../../permissions.md#project).
the [permissions you have on the project](../../permissions.md#project-members-permissions).
## Further reading
......
......@@ -13,7 +13,7 @@ There are two ways to set up Prometheus integration, depending on where your app
- For deployments on Kubernetes, GitLab can automatically [deploy and manage Prometheus](#managed-prometheus-on-kubernetes).
- For other deployment targets, simply [specify the Prometheus server](#manual-configuration-of-prometheus).
Once enabled, GitLab will automatically detect metrics from known services in the [metric library](#monitoring-ci-cd-environments). You are also able to [add your own metrics](#adding-additional-metrics) as well.
Once enabled, GitLab will automatically detect metrics from known services in the [metric library](#monitoring-ci-cd-environments). You are also able to [add your own metrics](#adding-additional-metrics-premium) as well.
## Enabling Prometheus Integration
......@@ -122,7 +122,7 @@ To specify a variable in a query, enclose it in curly braces with a leading perc
#### Managed Prometheus instances
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6590) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.2 for [custom metrics](#adding-additional-metrics), and 11.3 for [library metrics](prometheus_library/metrics.md).
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6590) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.2 for [custom metrics](#adding-additional-metrics-premium), and 11.3 for [library metrics](prometheus_library/metrics.md).
For managed Prometheus instances using auto configuration, alerts for metrics [can be configured](#adding-additional-metrics-premium) directly in the performance dashboard.
......@@ -184,7 +184,7 @@ If the "No data found" screen continues to appear, it could be due to:
- No successful deployments have occurred to this environment.
- Prometheus does not have performance data for this environment, or the metrics
are not labeled correctly. To test this, connect to the Prometheus server and
[run a query](#gitlab-prometheus-queries), replacing `$CI_ENVIRONMENT_SLUG`
[run a query](prometheus_library/kubernetes.html#metrics-supported), replacing `$CI_ENVIRONMENT_SLUG`
with the name of your environment.
[autodeploy]: ../../../ci/autodeploy/index.md
......
......@@ -152,7 +152,7 @@ the merge request is unblocked and can be merged.
Note, that meeting the required number of approvals is a necessary, but not
sufficient condition for unblocking a merge request from being merged. There
are other conditions that may block it, such as merge conflicts,
[pending discussions](../../discussions/index.md#l#only-allow-merge-requests-to-be-merged-if-all-discussions-are-resolved)
[pending discussions](../../discussions/index.md#only-allow-merge-requests-to-be-merged-if-all-discussions-are-resolved)
or a [failed CI/CD pipeline](merge_when_pipeline_succeeds.md).
## Code Owners approvals **[PREMIUM]**
......
......@@ -26,7 +26,7 @@ For an overview, check the video demonstration on [Mapping Work Versus Time, Wit
Burndown Charts, in general, are used for tracking and analyzing the completion of
a milestone. Therefore, their use cases are tied to the
[use you are giving to your milestone](index.md#use-cases).
[use you are assigning your milestone to](index.md).
To exemplify, suppose you lead a team of developers in a large company,
and you follow this workflow:
......
......@@ -124,7 +124,7 @@ These features are only available for project milestones and not group milestone
- Issues assigned to the milestone are displayed in three columns: Unstarted issues, ongoing issues, and completed issues.
- Merge requests assigned to the milestone are displayed in four columns: Work in progress merge requests, waiting for merge, rejected, and closed.
- Participants and labels that are used in issues and merge requests that have the milestone assigned are displayed.
- [Burndown chart](#burndown-charts).
- [Burndown chart](#project-burndown-charts-starter).
### Project Burndown Charts **[STARTER]**
......
......@@ -59,7 +59,7 @@ which is highly recommendable and much faster than hardcoding.
If you set up a GitLab Pages project on GitLab.com,
it will automatically be accessible under a
[subdomain of `namespace.gitlab.io`](introduction.md#gitlab-pages-on-gitlab-com).
[subdomain of `namespace.gitlab.io`](introduction.md#gitlab-pages-on-gitlabcom).
The `namespace` is defined by your username on GitLab.com,
or the group name you created this project under.
......
......@@ -20,13 +20,13 @@ you should consider first, which we'll cover in this guide:
1. Either if you're adding a **root domain** or a **subdomain**, for which
you'll need to set up [DNS records](#dns-records)
1. Whether you want to add an [SSL/TLS certificate](#ssl-tls-certificates) or not
1. Whether you want to add an [SSL/TLS certificate](#ssltls-certificates) or not
To finish the association, you need to [add your domain to your project's Pages settings](#add-your-custom-domain-to-gitlab-pages-settings).
Let's start from the beginning with [DNS records](#dns-records).
If you already know how they work and want to skip the introduction to DNS,
you may be interested in skipping it until the [TL;DR](#tl-dr) section below.
you may be interested in skipping it until the [TL;DR](#tldr) section below.
### DNS Records
......@@ -148,7 +148,7 @@ verify your domain's ownership with a TXT record:
Once you've set the DNS record, you'll need navigate to your project's
**Setting > Pages** and click **+ New domain** to add your custom domain to
GitLab Pages. You can choose whether to add an [SSL/TLS certificate](#ssl-tls-certificates)
GitLab Pages. You can choose whether to add an [SSL/TLS certificate](#ssltls-certificates)
to make your website accessible under HTTPS or leave it blank. If don't add a certificate,
your site will be accessible only via HTTP:
......
......@@ -141,7 +141,7 @@ You can also take some optional further steps:
_Advanced options:_
- [Use a custom domain](getting_started_part_three.md#adding-your-custom-domain-to-gitlab-pages)
- Apply [SSL/TLS certification](getting_started_part_three.md#ssl-tls-certificates) to your custom domain
- Apply [SSL/TLS certification](getting_started_part_three.md#ssltls-certificates) to your custom domain
## Explore GitLab Pages
......
......@@ -11,7 +11,7 @@ With GitLab Pages you can host for free your static websites on GitLab.
Combined with the power of [GitLab CI] and the help of [GitLab Runner] you can
deploy static pages for your individual projects, your user or your group.
Read [GitLab Pages on GitLab.com](#gitlab-pages-on-gitlab-com) for specific
Read [GitLab Pages on GitLab.com](#gitlab-pages-on-gitlabcom) for specific
information, if you are using GitLab.com to host your website.
## Getting started with GitLab Pages domains
......@@ -410,7 +410,7 @@ file for both the `/data` and `/data/` URL paths.
### Add a custom domain to your Pages website
For a complete guide on Pages domains, read through the article
[GitLab Pages from A to Z: Part 3 - Setting Up Custom Domains - DNS Records and SSL/TLS Certificates](getting_started_part_three.md#setting-up-custom-domains-dns-records-and-ssl-tls-certificates)
[GitLab Pages from A to Z: Part 3 - GitLab Pages custom domains and SSL/TLS Certificates](getting_started_part_three.md)
If this setting is enabled by your GitLab administrator, you should be able to
see the **New Domain** button when visiting your project's settings through the
......@@ -451,7 +451,7 @@ private key when adding a new domain.
![Pages upload cert](img/pages_upload_cert.png)
For a complete guide on Pages domains, read through the article
[GitLab Pages from A to Z: Part 3 - Setting Up Custom Domains - DNS Records and SSL/TLS Certificates](getting_started_part_three.md#setting-up-custom-domains-dns-records-and-ssl-tls-certificates)
[GitLab Pages from A to Z: Part 3 - GitLab Pages custom domains and SSL/TLS Certificates](getting_started_part_three.md)
### Custom error codes pages
......
......@@ -38,7 +38,7 @@ turn are defined with the `paths` keyword. All paths to files and directories
are relative to the repository that was cloned during the build. These uploaded
artifacts will be kept in GitLab for 1 week as defined by the `expire_in`
definition. You have the option to keep the artifacts from expiring via the
[web interface](#browsing-job-artifacts). If the expiry time is not defined,
[web interface](#browsing-artifacts). If the expiry time is not defined,
it defaults to the [instance wide
setting](../../admin_area/settings/continuous_integration.md#default-artifacts-expiration-core-only).
......
......@@ -11,7 +11,7 @@ Read through GiLab's branching documentation:
See also:
- [Branches API](../../../../api/branches.md), for information on operating on repository branches using the GitLab API.
- [GitLab Flow](../../../../university/training/gitlab_flow.md#gitlab-flow). Use the best of GitLab for your branching strategies.
- [GitLab Flow](../../../../university/training/gitlab_flow.md). Use the best of GitLab for your branching strategies.
- [Getting started with Git](../../../../topics/git/index.md) and GitLab.
## Default branch
......
......@@ -102,7 +102,7 @@ quickly access issues and merge requests created or assigned to you within that
Your [todos](../../workflow/todos.md#gitlab-todos) can be searched by "to do" and "done".
You can [filter](../../workflow/todos.md#filtering-your-todos) them per project,
author, type, and action. Also, you can sort them by
[**Label priority**](../../user/project/labels.md#prioritize-labels),
[**Label priority**](../../user/project/labels.md#label-priority),
**Last created** and **Oldest created**.
## Projects
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment