Change absolute links to relative
Change assorted absolute links to ce and ee docs to relative links
This commit is contained in:
Marcel Amirault
Achilleas Pipinellis
parent
821c298419
commit
6feda1df3b
18 changed files with 43 additions and 43 deletions
|
|
@ -441,12 +441,12 @@ and want to eliminate NFS from your environment altogether, there are
|
|||
a few things that you need to do:
|
||||
|
||||
1. Make sure the [`git` user home directory](https://docs.gitlab.com/omnibus/settings/configuration.html#moving-the-home-directory-for-a-user) is on local disk.
|
||||
1. Configure [database lookup of SSH keys](https://docs.gitlab.com/ce/administration/operations/fast_ssh_key_lookup.html)
|
||||
1. Configure [database lookup of SSH keys](../operations/fast_ssh_key_lookup.md)
|
||||
to eliminate the need for a shared authorized_keys file.
|
||||
1. Configure [object storage for job artifacts](https://docs.gitlab.com/ce/administration/job_artifacts.html#using-object-storage)
|
||||
including [live tracing](https://docs.gitlab.com/ce/administration/job_traces.html#new-live-trace-architecture).
|
||||
1. Configure [object storage for LFS objects](https://docs.gitlab.com/ce/workflow/lfs/lfs_administration.html#storing-lfs-objects-in-remote-object-storage).
|
||||
1. Configure [object storage for uploads](https://docs.gitlab.com/ce/administration/uploads.html#using-object-storage-core-only).
|
||||
1. Configure [object storage for job artifacts](../job_artifacts.md#using-object-storage)
|
||||
including [live tracing](../job_traces.md#new-live-trace-architecture).
|
||||
1. Configure [object storage for LFS objects](../../workflow/lfs/lfs_administration.md#storing-lfs-objects-in-remote-object-storage).
|
||||
1. Configure [object storage for uploads](../uploads.md#using-object-storage-core-only).
|
||||
|
||||
NOTE: **Note:** One current feature of GitLab still requires a shared directory (NFS): [GitLab Pages](../../user/project/pages/index.md).
|
||||
There is [work in progress](https://gitlab.com/gitlab-org/gitlab-pages/issues/196)
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ GitLab has an advanced log system where everything is logged so that you
|
|||
can analyze your instance using various system log files. In addition to
|
||||
system log files, GitLab Enterprise Edition comes with Audit Events.
|
||||
Find more about them [in Audit Events
|
||||
documentation](https://docs.gitlab.com/ee/administration/audit_events.html)
|
||||
documentation](audit_events.md)
|
||||
|
||||
System log files are typically plain text in a standard log file format.
|
||||
This guide talks about how to read and use these system log files.
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ It will check that each component was set up according to the installation guide
|
|||
|
||||
You may also have a look at our Troubleshooting Guides:
|
||||
|
||||
- [Troubleshooting Guide (GitLab)](http://docs.gitlab.com/ee/README.html#troubleshooting)
|
||||
- [Troubleshooting Guide (GitLab)](../index.md#troubleshooting)
|
||||
- [Troubleshooting Guide (Omnibus Gitlab)](https://docs.gitlab.com/omnibus/README.html#troubleshooting)
|
||||
|
||||
**Omnibus Installation**
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@ your repository:
|
|||
new commits.
|
||||
|
||||
The web hook URL should be set to the GitLab API to
|
||||
[trigger pull mirroring](https://docs.gitlab.com/ee/api/projects.html#start-the-pull-mirroring-process-for-a-project-starter),
|
||||
[trigger pull mirroring](../../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter),
|
||||
using the GitLab personal access token we just created.
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ the `author` field. GitLab team members **should not**.
|
|||
|
||||
- Any user-facing change **should** have a changelog entry. Example: "GitLab now
|
||||
uses system fonts for all text."
|
||||
- Any change behind a feature flag **should not** have a changelog entry. The entry should be added [in the merge request removing the feature flags](https://docs.gitlab.com/ee/development/feature_flags.html#developing-with-feature-flags).
|
||||
- Any change behind a feature flag **should not** have a changelog entry. The entry should be added [in the merge request removing the feature flags](feature_flags/development.md).
|
||||
- A fix for a regression introduced and then fixed in the same release (i.e.,
|
||||
fixing a bug introduced during a monthly release candidate) **should not**
|
||||
have a changelog entry.
|
||||
|
|
|
|||
|
|
@ -17,6 +17,6 @@ To request access to Chatops on GitLab.com:
|
|||
|
||||
## See also
|
||||
|
||||
- [Chatops Usage](https://docs.gitlab.com/ee/ci/chatops/README.html)
|
||||
- [Chatops Usage](../ci/chatops/README.md)
|
||||
- [Understanding EXPLAIN plans](understanding_explain_plans.md)
|
||||
- [Feature Groups](feature_flags/development.md#feature-groups)
|
||||
|
|
|
|||
|
|
@ -393,7 +393,7 @@ Instead:
|
|||
Example:
|
||||
|
||||
```md
|
||||
For more information, see the [confidential issue](https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html) `https://gitlab.com/gitlab-org/gitlab-ce/issues/<issue_number>`.
|
||||
For more information, see the [confidential issue](../../user/project/issues/confidential_issues.md) `https://gitlab.com/gitlab-org/gitlab-ce/issues/<issue_number>`.
|
||||
```
|
||||
|
||||
### Unlinking emails
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ GitLab Inc. provided environments such as staging and production, you need to
|
|||
have access to the chatops bot. Chatops bot is currently running on the ops instance,
|
||||
which is different from GitLab.com or dev.gitlab.org.
|
||||
|
||||
Follow the Chatops document to [request access](https://docs.gitlab.com/ee/development/chatops_on_gitlabcom.html#requesting-access).
|
||||
Follow the Chatops document to [request access](../chatops_on_gitlabcom.md#requesting-access).
|
||||
|
||||
Once you are added to the project test if your access propagated,
|
||||
run:
|
||||
|
|
@ -112,7 +112,7 @@ instances. Make sure to add the ~"feature flag" label to this merge request so
|
|||
release managers are aware the changes are hidden behind a feature flag. If the
|
||||
merge request has to be picked into a stable branch, make sure to also add the
|
||||
appropriate "Pick into X" label (e.g. "Pick into XX.X").
|
||||
See [the process document](https://docs.gitlab.com/ee/development/feature_flags/process.html#including-a-feature-behind-feature-flag-in-the-final-release) for further details.
|
||||
See [the process document](process.md#including-a-feature-behind-feature-flag-in-the-final-release) for further details.
|
||||
|
||||
When a feature gate has been removed from the code base, the value still exists
|
||||
in the database.
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ the feature flag check will default to `true`.
|
|||
|
||||
As an example, if you were to ship the backend half of a feature behind a flag,
|
||||
you'd want to explicitly disable that flag until the frontend half is also ready
|
||||
to be shipped. [You can do this via Chatops](https://docs.gitlab.com/ee/development/feature_flags/controls.html):
|
||||
to be shipped. [You can do this via Chatops](controls.md):
|
||||
|
||||
```
|
||||
/chatops run feature set some_feature 0
|
||||
|
|
|
|||
|
|
@ -394,15 +394,15 @@ end
|
|||
|
||||
By defining the `api_get_path` method, we allow the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to get a single issue.
|
||||
|
||||
> This `GET` path can be found in the [public API documentation](https://docs.gitlab.com/ee/api/issues.html#single-issue).
|
||||
> This `GET` path can be found in the [public API documentation](../../../api/issues.md#single-issue).
|
||||
|
||||
By defining the `api_post_path` method, we allow the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to create a new issue in a specific project.
|
||||
|
||||
> This `POST` path can be found in the [public API documentation](https://docs.gitlab.com/ee/api/issues.html#new-issue).
|
||||
> This `POST` path can be found in the [public API documentation](../../../api/issues.md#new-issue).
|
||||
|
||||
By defining the `api_post_body` method, we allow the [`ApiFabricator.api_post`](https://gitlab.com/gitlab-org/gitlab-ee/blob/a9177ca1812bac57e2b2fa4560e1d5dd8ffac38b/qa/qa/resource/api_fabricator.rb#L68) method to know which data to send when making the `POST` request.
|
||||
|
||||
> Notice that we pass both `labels` and `title` attributes in the `api_post_body`, where `labels` receives an array of labels, and [`title` is required](https://docs.gitlab.com/ee/api/issues.html#new-issue). Also, notice that we keep them alphabetically organized.
|
||||
> Notice that we pass both `labels` and `title` attributes in the `api_post_body`, where `labels` receives an array of labels, and [`title` is required](../../../api/issues.md#new-issue). Also, notice that we keep them alphabetically organized.
|
||||
|
||||
**Label resource**
|
||||
|
||||
|
|
@ -441,7 +441,7 @@ By defining the `api_post_path` method, we allow for the [`ApiFabricator `](http
|
|||
|
||||
By defining the `api_post_body` method, we we allow for the [`ApiFabricator.api_post`](https://gitlab.com/gitlab-org/gitlab-ee/blob/a9177ca1812bac57e2b2fa4560e1d5dd8ffac38b/qa/qa/resource/api_fabricator.rb#L68) method to know which data to send when making the `POST` request.
|
||||
|
||||
> Notice that we pass both `color` and `name` attributes in the `api_post_body` since [those are required](https://docs.gitlab.com/ee/api/labels.html#create-a-new-label). Also, notice that we keep them alphabetically organized.
|
||||
> Notice that we pass both `color` and `name` attributes in the `api_post_body` since [those are required](../../../api/labels.md#create-a-new-label). Also, notice that we keep them alphabetically organized.
|
||||
|
||||
### 8. Page Objects
|
||||
|
||||
|
|
|
|||
|
|
@ -128,9 +128,9 @@ GitLab can be configured to authenticate with other OAuth providers, LDAP, SAML,
|
|||
Kerberos, etc. Here are some documents you might be interested in reading:
|
||||
|
||||
- [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/)
|
||||
- [Integration documentation](https://docs.gitlab.com/ce/integration/)
|
||||
- [GitLab Pages configuration](https://docs.gitlab.com/ce/administration/pages/index.html)
|
||||
- [GitLab Container Registry configuration](https://docs.gitlab.com/ce/administration/container_registry.html)
|
||||
- [Integration documentation](../../integration/README.md)
|
||||
- [GitLab Pages configuration](../../administration/pages/index.md)
|
||||
- [GitLab Container Registry configuration](../../administration/container_registry.md)
|
||||
|
||||
[freetrial]: https://console.cloud.google.com/freetrial "GCP free trial"
|
||||
[ip]: https://cloud.google.com/compute/docs/configure-instance-ip-addresses#promote_ephemeral_ip "Configuring an Instance's IP Addresses"
|
||||
|
|
|
|||
|
|
@ -13,6 +13,6 @@ comments: false
|
|||
- [User management](user_management.md)
|
||||
- [Webhooks](web_hooks.md)
|
||||
- [Import](import.md) of git repositories in bulk
|
||||
- [Rebuild authorized_keys file](http://docs.gitlab.com/ce/raketasks/maintenance.html#rebuild-authorized_keys-file) task for administrators
|
||||
- [Rebuild authorized_keys file](../administration/raketasks/maintenance.md#rebuild-authorized_keys-file) task for administrators
|
||||
- [Migrate Uploads](../administration/raketasks/uploads/migrate.md)
|
||||
- [Sanitize Uploads](../administration/raketasks/uploads/sanitize.md)
|
||||
|
|
|
|||
|
|
@ -9,10 +9,10 @@ The GitLab Application Development Platform aims to:
|
|||
|
||||
- Reduce and even eliminate the time it takes for an Operations team
|
||||
to provide a full environment for software developers.
|
||||
- Get developers up and running fast so they can focus on writing
|
||||
- Get developers up and running fast so they can focus on writing
|
||||
great applications with a robust development feature set.
|
||||
- Provide best-of-breed security features so that applications developed
|
||||
with GitLab are not affected by vulnerabilities that may lead to security
|
||||
- Provide best-of-breed security features so that applications developed
|
||||
with GitLab are not affected by vulnerabilities that may lead to security
|
||||
problems and unintended use.
|
||||
|
||||
It is comprised of the following high-level elements:
|
||||
|
|
@ -35,28 +35,28 @@ with various cloud providers.
|
|||
### Build, test, deploy
|
||||
|
||||
In order to provide modern DevOps workflows, our Application Development Platform will rely on
|
||||
[Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) to provide those workflows. Auto DevOps works with
|
||||
any Kubernetes cluster; you're not limited to running on GitLab's infrastructure. Additionally, Auto DevOps offers
|
||||
an incremental consumption path. Because it is [composable](https://docs.gitlab.com/ee/topics/autodevops/#using-components-of-auto-devops),
|
||||
[Auto DevOps](../autodevops/index.md) to provide those workflows. Auto DevOps works with
|
||||
any Kubernetes cluster; you're not limited to running on GitLab's infrastructure. Additionally, Auto DevOps offers
|
||||
an incremental consumption path. Because it is [composable](../autodevops/index.md#using-components-of-auto-devops),
|
||||
you can use as much or as little of the default pipeline as you'd like, and deeply customize without having to integrate a completely different platform.
|
||||
|
||||
### Security
|
||||
|
||||
The Application Development Platform helps you ensure that the applications you create are not affected by vulnerabilities
|
||||
The Application Development Platform helps you ensure that the applications you create are not affected by vulnerabilities
|
||||
that may lead to security problems and unintended use. This can be achieved by making use of the embedded security features of Auto DevOps,
|
||||
which inform security teams and developers if there is something to consider changing in their apps
|
||||
which inform security teams and developers if there is something to consider changing in their apps
|
||||
before it is too late to create a preventative fix. The following features are included:
|
||||
|
||||
- [Auto SAST (Static Application Security Testing)](https://docs.gitlab.com/ee/topics/autodevops/#auto-sast-ultimate)
|
||||
- [Auto Dependency Scanning](https://docs.gitlab.com/ee/topics/autodevops/#auto-dependency-scanning-ultimate)
|
||||
- [Auto Container Scanning](https://docs.gitlab.com/ee/topics/autodevops/#auto-container-scanning-ultimate)
|
||||
- [Auto DAST (Dynamic Application Security Testing)](https://docs.gitlab.com/ee/topics/autodevops/#auto-dast-ultimate)
|
||||
- [Auto SAST (Static Application Security Testing)](../autodevops/index.md#auto-sast-ultimate)
|
||||
- [Auto Dependency Scanning](../autodevops/index.md#auto-dependency-scanning-ultimate)
|
||||
- [Auto Container Scanning](../autodevops/index.md#auto-container-scanning-ultimate)
|
||||
- [Auto DAST (Dynamic Application Security Testing)](../autodevops/index.md#auto-dast-ultimate)
|
||||
|
||||
### Observability
|
||||
|
||||
Performance is a critical aspect of the user experience, and ensuring your application is responsive and available is everyone's
|
||||
responsibility. The Application Development Platform integrates key performance analytics and feedback
|
||||
responsibility. The Application Development Platform integrates key performance analytics and feedback
|
||||
into GitLab, automatically. The following features are included:
|
||||
|
||||
- [Auto Monitoring](https://docs.gitlab.com/ee/topics/autodevops/#auto-monitoring)
|
||||
- [In-app Kubernetes Pod Logs](https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html)
|
||||
- [Auto Monitoring](../autodevops/index.md#auto-monitoring)
|
||||
- [In-app Kubernetes Pod Logs](../../user/project/clusters/kubernetes_pod_logs.md)
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ The GitLab University curriculum is composed of GitLab videos, screencasts, pres
|
|||
- Being part of our Great Community and Contributing to GitLab
|
||||
1. [Getting Started with the GitLab Development Kit (GDK)](https://about.gitlab.com/2016/06/08/getting-started-with-gitlab-development-kit/)
|
||||
1. [Contributing Technical Articles to the GitLab Blog](https://about.gitlab.com/2016/01/26/call-for-writers/)
|
||||
1. [GitLab Training Workshops](https://docs.gitlab.com/ce/university/training/end-user/)
|
||||
1. [GitLab Training Workshops](training/end-user/README.md)
|
||||
1. [GitLab Professional Services](https://about.gitlab.com/services/)
|
||||
|
||||
### 1.8 GitLab Training Material
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ to the webhook URL.
|
|||
|
||||
In most cases, you'll need to set up your own [webhook receiver](#example-webhook-receiver)
|
||||
to receive information from GitLab, and send it to another app, according to your needs.
|
||||
We already have a [built-in receiver](https://docs.gitlab.com/ce/project_services/slack.html)
|
||||
We already have a [built-in receiver](slack.md)
|
||||
for sending [Slack](https://api.slack.com/incoming-webhooks) notifications _per project_.
|
||||
|
||||
## Overview
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ The "Move issue" button is at the bottom of the right-sidebar when viewing the i
|
|||
|
||||
If you have advanced technical skills you can also bulk move all the issues from one project to another in the rails console. The below script will move all the issues from one project to another that are not in status **closed**.
|
||||
|
||||
To access rails console run `sudo gitlab-rails console` on the GitLab server and run the below script. Please be sure to change **project**, **admin_user** and **target_project** to your values. We do also recommend [creating a backup](https://docs.gitlab.com/ee/raketasks/backup_restore.html#creating-a-backup-of-the-gitlab-system) before attempting any changes in the console.
|
||||
To access rails console run `sudo gitlab-rails console` on the GitLab server and run the below script. Please be sure to change **project**, **admin_user** and **target_project** to your values. We do also recommend [creating a backup](../../../raketasks/backup_restore.md#creating-a-backup-of-the-gitlab-system) before attempting any changes in the console.
|
||||
|
||||
```ruby
|
||||
project = Project.find_by_full_path('full path of the project where issues are moved from')
|
||||
|
|
|
|||
|
|
@ -380,7 +380,7 @@ What you can do with GitLab CI is pretty much up to your
|
|||
creativity. Once you get used to it, you start creating
|
||||
awesome scripts that automate most of tasks you'd do
|
||||
manually in the past. Read through the
|
||||
[documentation of GitLab CI](https://docs.gitlab.com/ce/ci/yaml/README.html)
|
||||
[documentation of GitLab CI](../../../ci/yaml/README.md)
|
||||
to understand how to go even further on your scripts.
|
||||
|
||||
- On this blog post, understand the concept of
|
||||
|
|
|
|||
|
|
@ -286,10 +286,10 @@ project mirroring again by [Forcing an update](#forcing-an-update-core).
|
|||
[GitLab Starter](https://about.gitlab.com/pricing/) 10.3.
|
||||
|
||||
Pull mirroring uses polling to detect new branches and commits added upstream, often minutes
|
||||
afterwards. If you notify GitLab by [API](https://docs.gitlab.com/ee/api/projects.html#start-the-pull-mirroring-process-for-a-project-starter),
|
||||
afterwards. If you notify GitLab by [API](../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter),
|
||||
updates will be pulled immediately.
|
||||
|
||||
For more information, see [Start the pull mirroring process for a Project](https://docs.gitlab.com/ee/api/projects.html#start-the-pull-mirroring-process-for-a-project-starter).
|
||||
For more information, see [Start the pull mirroring process for a Project](../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter).
|
||||
|
||||
## Forcing an update **[CORE]**
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue