@@ -273,3 +273,11 @@ In case you are experiencing any issues connecting through PgBouncer, the first
```
Additionally, you can check the output from `show databases` in the [Administrative console](#administrative-console). In the output, you would expect to see values in the `host` field for the `gitlabhq_production` database. Additionally, `current_connections` should be greater than 1.
### Message: `LOG: invalid CIDR mask in address`
See the suggested fix [in Geo documentation](../geo/replication/troubleshooting.md#message-log--invalid-cidr-mask-in-address).
### Message: `LOG: invalid IP mask "md5": Name or service not known`
See the suggested fix [in Geo documentation](../geo/replication/troubleshooting.md#message-log--invalid-ip-mask-md5-name-or-service-not-known).
@@ -10,9 +10,9 @@ It allows you to see (from left to right):
- the current host serving the page
- time taken and number of DB queries; click through for details of these queries
![SQL profiling using the Performance Bar](img/performance_bar_sql_queries.png)
- time taken and number of [Gitaly] calls; click through for details of these calls
- time taken and number of [Gitaly](../../gitaly/index.md) calls; click through for details of these calls
![Gitaly profiling using the Performance Bar](img/performance_bar_gitaly_calls.png)
- time taken and number of [Rugged] calls; click through for details of these calls
- time taken and number of [Rugged](../../high_availability/nfs.md#improving-nfs-performance-with-gitlab) calls; click through for details of these calls
![Rugged profiling using the Performance Bar](img/performance_bar_rugged_calls.png)
- time taken and number of Redis calls; click through for details of these calls
![Redis profiling using the Performance Bar](img/performance_bar_redis_calls.png)
...
...
@@ -68,6 +68,3 @@ display it.
You can toggle the Bar using the same shortcut.
![GitLab Performance Bar Admin Settings](img/performance_bar_configuration_settings.png)
@@ -217,17 +217,17 @@ You can visit `http://localhost:9090` for the dashboard that Prometheus offers b
>**Note:**
If SSL has been enabled on your GitLab instance, you may not be able to access
Prometheus on the same browser as GitLab if using the same FQDN due to [HSTS][hsts]. We plan to
[provide access via GitLab][multi-user-prometheus], but in the interim there are
Prometheus on the same browser as GitLab if using the same FQDN due to [HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security). We plan to
[provide access via GitLab](https://gitlab.com/gitlab-org/multi-user-prometheus), but in the interim there are
some workarounds: using a separate FQDN, using server IP, using a separate browser for Prometheus, resetting HSTS, or
having [NGINX proxy it][nginx-custom-config].
having [NGINX proxy it](https://docs.gitlab.com/omnibus/settings/nginx.html#inserting-custom-nginx-settings-into-the-gitlab-server-block).
The performance data collected by Prometheus can be viewed directly in the
Prometheus console, or through a compatible dashboard tool.
The Prometheus interface provides a [flexible query language](https://prometheus.io/docs/prometheus/latest/querying/basics/)
to work with the collected data where you can visualize the output.
For a more fully featured dashboard, Grafana can be used and has
[official support for Prometheus][prom-grafana].
[official support for Prometheus](https://prometheus.io/docs/visualization/grafana/).
Sample Prometheus queries:
...
...
@@ -305,7 +305,7 @@ The GitLab exporter allows you to measure various GitLab metrics, pulled from Re
> - Introduced in GitLab 9.0.
> - Pod monitoring introduced in GitLab 9.4.
If your GitLab server is running within Kubernetes, Prometheus will collect metrics from the Nodes and [annotated Pods](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config) in the cluster, including performance data on each container. This is particularly helpful if your CI/CD environments run in the same cluster, as you can use the [Prometheus project integration][prometheus integration] to monitor them.
If your GitLab server is running within Kubernetes, Prometheus will collect metrics from the Nodes and [annotated Pods](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config) in the cluster, including performance data on each container. This is particularly helpful if your CI/CD environments run in the same cluster, as you can use the [Prometheus project integration](../../../user/project/integrations/prometheus.md) to monitor them.
To disable the monitoring of Kubernetes:
...
...
@@ -316,14 +316,5 @@ To disable the monitoring of Kubernetes:
prometheus['monitor_kubernetes']=false
```
1. Save the file and [reconfigure GitLab][reconfigure] for the changes to
1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to
| `id` | integer/string | yes | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
| `job_id` | integer | yes | ID of a job. |
| `job_token`**(PREMIUM)** | string | no | To be used with [triggers] for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
| `job_token`**(PREMIUM)** | string | no | To be used with [triggers](../ci/triggers/README.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline-premium) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
Example request using the `PRIVATE-TOKEN` header:
...
...
@@ -406,8 +406,8 @@ Possible response status codes:
> **Notes**:
>
> - [Introduced][ce-5347] in GitLab 8.10.
> - The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced][ee-2346]
> in [GitLab Premium][ee] 9.5.
> - The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2346)
> in [GitLab Premium](https://about.gitlab.com/pricing/) 9.5.
Download the artifacts zipped archive from the latest successful pipeline for
the given reference name and job, provided the job finished successfully. This
...
...
@@ -425,7 +425,7 @@ Parameters
| `id` | integer/string | yes | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
| `ref_name` | string | yes | Branch or tag name in repository. HEAD or SHA references are not supported. |
| `job` | string | yes | The name of the job. |
| `job_token`**(PREMIUM)** | string | no | To be used with [triggers] for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
| `job_token`**(PREMIUM)** | string | no | To be used with [triggers](../ci/triggers/README.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline-premium) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
# How to run Jenkins in development environment (on OSX) **(STARTER)**
# How to run Jenkins in development environment (on macOS) **(STARTER)**
This is a step by step guide on how to set up [Jenkins](https://jenkins.io/) on your local machine and connect to it from your GitLab instance. GitLab triggers webhooks on Jenkins, and Jenkins is connects to GitLab using the API. By running both applications on the same machine, we can make sure they are able to access each other.
This is a step by step guide on how to set up [Jenkins](https://jenkins.io/) on your local machine and connect to it from your GitLab instance. GitLab triggers webhooks on Jenkins, and Jenkins connects to GitLab using the API. By running both applications on the same machine, we can make sure they are able to access each other.
## Install Jenkins
...
...
@@ -17,12 +17,12 @@ GitLab does not allow requests to localhost or the local network by default. Whe
1. Log into your GitLab instance as an admin.
1. Go to **{admin}****Admin Area > Settings > Network**.
1. Expand `Outbound requests` and check the following checkboxes:
1. Expand **Outbound requests** and check the following checkboxes:
-**Allow requests to the local network from web hooks and services**
-**Allow requests to the local network from system hooks**
-**Allow requests to the local network from web hooks and services**
-**Allow requests to the local network from system hooks**
For more details about GitLab webhooks, see [Webhooks and insecure internal web services](../../security/webhooks.md).
For more details about GitLab webhooks, see [Webhooks and insecure internal web services](../../security/webhooks.md).
Jenkins uses the GitLab API and needs an access token.
...
...
@@ -36,7 +36,9 @@ Jenkins uses the GitLab API and needs an access token.
Configure your GitLab API connection in Jenkins.
1. Make sure the GitLab plugin is installed on Jenkins. You can manage plugins in **Manage Jenkins > Manage Plugins**.
1. Set up the GitLab connection: Go to **Manage Jenkins > Configure System**, find the **GitLab** section and check the `Enable authentication for '/project' end-point` checkbox.
1. Set up the GitLab connection:
1. Go to **Manage Jenkins > Configure System**.
1. Find the **GitLab** section and check the **Enable authentication for '/project' end-point** checkbox.
1. To add your credentials, click **Add** then choose **Jenkins Credential Provider**.
1. Choose **GitLab API token** as the type of token.
1. Paste your GitLab access token and click **Add**.
...
...
@@ -48,23 +50,23 @@ For more details, see [GitLab documentation about Jenkins CI](../../integration/
## Configure Jenkins Project
Set up the Jenkins project you are going to run your build on.
Set up the Jenkins project you're going to run your build on. A **Freestyle** project is the easiest option because the Jenkins plugin will update the build status on GitLab. In a **Pipeline** project, updating the status on GitLab needs to be configured in a script.
1. On your Jenkins instance, go to **New Item**.
1. Pick a name, choose **Pipeline** and click **ok**.
1. Pick a name, choose **Freestyle** or **Pipeline** and click **ok**.
1. Choose your GitLab connection from the dropdown.
1. Check the **Build when a change is pushed to GitLab** checkbox.
1. Check the following checkboxes:
-**Accepted Merge Request Events**
-**Closed Merge Request Events**
-**Accepted Merge Request Events**
-**Closed Merge Request Events**
1.Updating the status on GitLab must be done by a pipeline script. Add GitLab update steps, using the following as an example:
1.If you created a **Freestyle** project, choose **Publish build status to GitLab** in the **Post-build Actions** section.
**Example Pipeline Script:**
If you created a **Pipeline** project, updating the status on GitLab has to be done by the pipeline script. Add GitLab update steps as in this example:
```groovy
pipeline{
```groovy
pipeline{
agentany
stages{
...
...
@@ -76,36 +78,17 @@ pipeline {
}
}
}
}
```
}
```
## Configure your GitLab project
To activate the Jenkins service you must have a Starter subscription or higher.
1. Go to your project's page, then **Settings > Integrations > Jenkins CI**.
1. Check the `Active` checkbox and the triggers for `Push` and `Merge request`.
1. Check the **Active** checkbox and the triggers for **Push** and **Merge request**.
1. Fill in your Jenkins host, project name, username and password and click **Test settings and save changes**.
## Test your setup
Make a change in your repository and open an MR. In your Jenkins project it should have triggered a new build and on your MR, there should be a widget saying "Pipeline #NUMBER passed". It will also include a link to your Jenkins build.
### Run QA test
The [jenkins_build_status_spec](https://gitlab.com/gitlab-org/gitlab/-/blob/v12.9.0-ee/qa/qa/specs/features/ee/browser_ui/3_create/jenkins/jenkins_build_status_spec.rb) performs an end-to-end test of the Jenkins setup using [GitLab QA](https://gitlab.com/gitlab-org/gitlab-qa).
To run the test against your GDK, follow the [run QA tests against your GDK setup](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/run_qa_against_gdk.md#run-qa-tests-against-your-gdk-setup) instructions.
The following environment variables are required to run the test:
Make a change in your repository and open an MR. In your Jenkins project it should have triggered a new build and on your MR, there should be a widget saying **Pipeline #NUMBER passed**. It will also include a link to your Jenkins build.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/37115) in GitLab 10.0.
> - Generally available on GitLab 11.0.
Auto DevOps provides pre-defined CI/CD configuration which allows you to automatically detect, build, test,
...
...
@@ -317,7 +317,7 @@ When using Auto DevOps, you may want to deploy different environments to
different Kubernetes clusters. This is possible due to the 1:1 connection that
[exists between them](../../user/project/clusters/index.md#multiple-kubernetes-clusters-premium).
In the [Auto DevOps template] (used behind the scenes by Auto DevOps), there
In the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)(used behind the scenes by Auto DevOps), there
are currently 3 defined environment names that you need to know:
-`review/` (every environment starting with `review/`)
...
...
@@ -369,7 +369,7 @@ Auto Build creates a build of the application using an existing `Dockerfile` or
Heroku buildpacks.
Either way, the resulting Docker image is automatically pushed to the
[Container Registry][container-registry] and tagged with the commit SHA or tag.
[Container Registry](../../user/packages/container_registry/index.md) and tagged with the commit SHA or tag.
#### Auto Build using a Dockerfile
...
...
@@ -430,7 +430,7 @@ Any differences between the source and target branches are also
### Auto SAST **(ULTIMATE)**
> Introduced in [GitLab Ultimate][ee] 10.3.
> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.3.
Static Application Security Testing (SAST) uses the
[SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast) to run static
...
...
@@ -445,7 +445,7 @@ Any security warnings are also shown in the merge request widget. Read more how
### Auto Dependency Scanning **(ULTIMATE)**
> Introduced in [GitLab Ultimate][ee] 10.7.
> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.7.
@@ -498,7 +498,7 @@ This is an optional step, since many projects do not have a Kubernetes cluster
available. If the [requirements](#requirements) are not met, the job will
silently be skipped.
[Review Apps][review-app] are temporary application environments based on the
[Review Apps](../../ci/review_apps/index.md) are temporary application environments based on the
branch's code so developers, designers, QA, product managers, and other
reviewers can actually see and interact with code changes as part of the review
process. Auto Review Apps create a Review App for each branch.
...
...
@@ -533,7 +533,7 @@ in the first place, and thus not realize that it needs to re-apply the old confi
### Auto DAST **(ULTIMATE)**
> Introduced in [GitLab Ultimate][ee] 10.4.
> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4.
Dynamic Application Security Testing (DAST) uses the
popular open source tool [OWASP ZAProxy](https://github.com/zaproxy/zaproxy)
...
...
@@ -570,7 +570,7 @@ DAST can be disabled:
### Auto Browser Performance Testing **(PREMIUM)**
> Introduced in [GitLab Premium][ee] 10.4.
> Introduced in [GitLab Premium](https://about.gitlab.com/pricing/) 10.4.
Auto Browser Performance Testing utilizes the [Sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/) to measure the performance of a web page. A JSON report is created and uploaded as an artifact, which includes the overall performance score for each page. By default, the root page of Review and Production environments will be tested. If you would like to add additional URL's to test, simply add the paths to a file named `.gitlab-urls.txt` in the root directory, one per line. For example:
...
...
@@ -595,7 +595,7 @@ the Kubernetes cluster, with a namespace based on the project name and unique
project ID, for example `project-4321`.
Auto Deploy doesn't include deployments to staging or canary by default, but the
[Auto DevOps template] contains job definitions for these tasks if you want to
[Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) contains job definitions for these tasks if you want to
enable them.
You can make use of [environment variables](#environment-variables) to automatically
...
...
@@ -619,7 +619,7 @@ deploys with Auto DevOps can undo your changes. Also, if you change something
and want to undo it by deploying again, Helm may not detect that anything changed
in the first place, and thus not realize that it needs to re-apply the old config.
> [Introduced][ce-19507] in GitLab 11.0.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/19507) in GitLab 11.0.
For internal and private projects a [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token)
will be automatically created, when Auto DevOps is enabled and the Auto DevOps settings are saved. This Deploy Token
...
...
@@ -669,7 +669,7 @@ restore your database before opting into version `2`.
#### Migrations
> [Introduced][ce-21955] in GitLab 11.4
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21955) in GitLab 11.4
Database initialization and migrations for PostgreSQL can be configured to run
within the application pod by setting the project variables `DB_INITIALIZE` and
...
...
@@ -1017,7 +1017,7 @@ to the desired environment. See [Limiting environment scopes of variables](../..
### Customizing `.gitlab-ci.yml`
Auto DevOps is completely customizable because the [Auto DevOps template]:
Auto DevOps is completely customizable because the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml):
- Is just an implementation of a [`.gitlab-ci.yml`](../../ci/yaml/README.md) file.
- Uses only features available to any implementation of `.gitlab-ci.yml`.
...
...
@@ -1033,7 +1033,7 @@ include:
```
Then add any extra changes you want. Your additions will be merged with the
[Auto DevOps template] using the behaviour described for
[Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) using the behaviour described for
[`include`](../../ci/yaml/README.md#include).
It is also possible to copy and paste the contents of the [Auto DevOps
...
...
@@ -1083,12 +1083,12 @@ include:
-template:Jobs/Build.gitlab-ci.yml
```
Consult the [Auto DevOps template] for information on available jobs.
Consult the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) for information on available jobs.
### PostgreSQL database support
In order to support applications that require a database,
[PostgreSQL][postgresql] is provisioned by default. The credentials to access
[PostgreSQL](https://www.postgresql.org/) is provisioned by default. The credentials to access
the database are preconfigured, but can be customized by setting the associated
[variables](#environment-variables). These credentials can be used for defining a
`DATABASE_URL` of the format:
...
...
@@ -1550,16 +1550,6 @@ spec:
service account for your project. For help debugging this issue, see
> [Introduced][ee-1659] in [GitLab Premium][eep] 9.1.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1659) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.1.
A popular [Continuous Deployment](https://en.wikipedia.org/wiki/Continuous_deployment)
strategy, where a small portion of the fleet is updated to the new version of
...
...
@@ -8,7 +8,7 @@ your application.
## Overview
When embracing [Continuous Delivery][cd-blog], a company needs to decide what
When embracing [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/), a company needs to decide what
type of deployment strategy to use. One of the most popular strategies is canary
deployments, where a small portion of the fleet is updated to the new version
first. This subset, the canaries, then serve as the proverbial
...
...
@@ -18,8 +18,8 @@ If there is a problem with the new version of the application, only a small
percentage of users are affected and the change can either be fixed or quickly
reverted.
Leveraging [Kubernetes' Canary deployments][kube-canary], visualize your canary
deployments right inside the [Deploy Board], without the need to leave GitLab.
Leveraging [Kubernetes' Canary deployments](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments), visualize your canary
deployments right inside the [Deploy Board](deploy_boards.md), without the need to leave GitLab.
## Use cases
...
...
@@ -35,7 +35,7 @@ to be careful when using canaries with user-facing changes, because by default,
requests from the same user will be randomly distributed between canary and
non-canary pods, which could result in confusion or even errors. If needed, you
may want to consider [setting `service.spec.sessionAffinity` to `ClientIP` in
your Kubernetes service definitions][kube-net], but that is beyond the scope of
your Kubernetes service definitions][kube-net](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies), but that is beyond the scope of
this document.
## Enabling Canary Deployments
...
...
@@ -61,10 +61,3 @@ Canary deployments are marked with a yellow dot in the Deploy Board so that you
can easily notice them.
![Canary deployments on Deploy Board](img/deploy_boards_canary_deployments.png)
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17894) in GitLab 10.7.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/issues/199370) from **Settings > Repository** in GitLab 12.9.
Deploy tokens allow you to download (`git clone`) or read the container registry images of a project without having a user and a password.
...
...
@@ -43,7 +43,7 @@ the following table.
| Scope | Description |
| ----- | ----------- |
| `read_repository` | Allows read-access to the repository through `git clone` |
| `read_registry` | Allows read-access to [container registry] images if a project is private and authorization is required. |
| `read_registry` | Allows read-access to [container registry](../../packages/container_registry/index.md) images if a project is private and authorization is required. |
## Deploy token custom username
...
...
@@ -101,7 +101,7 @@ apply consistently when cloning the repository of related projects.
### GitLab Deploy Token
> [Introduced][ce-18414] in GitLab 10.8.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18414) in GitLab 10.8.
There's a special case when it comes to Deploy Tokens. If a user creates one
named `gitlab-deploy-token`, the username and token of the Deploy Token will be
@@ -32,7 +32,7 @@ as created by the pusher (local push or via the UI) and any job created in this
pipeline will have the read permissions of the pusher but not write permissions.
This allows us to make it really easy to evaluate the access for all projects
that have [Git submodules][gitsub] or are using container images that the pusher
that have [Git submodules](../../ci/git_submodules.md) or are using container images that the pusher
would have access too. **The permission is granted only for the time that the job
is running. The access is revoked after the job is finished.**
...
...
@@ -132,7 +132,7 @@ With the new job permissions model, there is now an easy way to access all
dependent source code in a project. That way, we can:
1. Access a project's dependent repositories
1. Access a project's [Git submodules][gitsub]
1. Access a project's [Git submodules](../../ci/git_submodules.md)
1. Access private container images
1. Access project's and submodule LFS objects
...
...
@@ -151,15 +151,15 @@ In short here's what you need to do should you encounter any issues.
As an administrator:
-**500 errors**: You will need to update [GitLab Workhorse][workhorse] to at
-**500 errors**: You will need to update [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) to at
least 0.8.2. This is done automatically for Omnibus installations, you need to
[check manually][update-docs] for installations from source.
[check manually](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/doc/update) for installations from source.
-**500 errors**: Check if you have another web proxy sitting in front of NGINX (HAProxy,
Apache, etc.). It might be a good idea to let GitLab use the internal NGINX
web server and not disable it completely. See [this comment][comment] for an
web server and not disable it completely. See [this comment](https://gitlab.com/gitlab-org/gitlab-foss/issues/22484#note_16648302) for an
example.
-**403 errors**: You need to make sure that your installation has [HTTP(S)
cloning enabled][https]. HTTP(S) support is now a **requirement** by GitLab CI
cloning enabled](../admin_area/settings/visibility_and_access_controls.md#enabled-git-access-protocols). HTTP(S) support is now a **requirement** by GitLab CI
to clone all sources.
As a user:
...
...
@@ -170,7 +170,7 @@ As a user:
### Dependent repositories
The [Job environment variable][jobenv]`CI_JOB_TOKEN` can be used to
The [Job environment variable](../../ci/variables/README.md#predefined-environment-variables)`CI_JOB_TOKEN` can be used to
authenticate any clones of dependent repositories. For example:
@@ -21,7 +21,7 @@ In brief, this is what you need to upload your website in GitLab Pages:
1. Domain of the instance: domain name that is used for GitLab Pages
(ask your administrator).
1. GitLab CI/CD: a `.gitlab-ci.yml` file with a specific job named [`pages`][pages] in the root directory of your repository.
1. GitLab CI/CD: a `.gitlab-ci.yml` file with a specific job named [`pages`](../../../ci/yaml/README.md#pages) in the root directory of your repository.
1. A directory called `public` in your site's repo containing the content
to be published.
1. GitLab Runner enabled for the project.
...
...
@@ -61,7 +61,7 @@ If the case of `404.html`, there are different scenarios. For example:
Since you cannot use any custom server configuration files, like `.htaccess` or
any `.conf` file, if you want to redirect a page to another
location, you can use the [HTTP meta refresh tag][metarefresh].
location, you can use the [HTTP meta refresh tag](https://en.wikipedia.org/wiki/Meta_refresh).
Some static site generators provide plugins for that functionality so that you
don't have to create and edit HTML files manually. For example, Jekyll has the
...
...
@@ -286,8 +286,4 @@ No, you don't. You can create your project first and it will be accessed under
## Known issues
For a list of known issues, visit GitLab's [public issue tracker].