diff options
Diffstat (limited to 'doc/user/project')
| -rw-r--r-- | doc/user/project/clusters/index.md | 45 | ||||
| -rw-r--r-- | doc/user/project/clusters/serverless/index.md | 22 | ||||
| -rw-r--r-- | doc/user/project/cycle_analytics.md | 37 | ||||
| -rw-r--r-- | doc/user/project/img/cycle_analytics_landing_page.png | bin | 42114 -> 184131 bytes | |||
| -rw-r--r-- | doc/user/project/integrations/prometheus_library/nginx_ingress.md | 2 | ||||
| -rw-r--r-- | doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md | 2 | ||||
| -rw-r--r-- | doc/user/project/pages/getting_started_part_four.md | 20 | ||||
| -rw-r--r-- | doc/user/project/pages/getting_started_part_two.md | 97 | ||||
| -rw-r--r-- | doc/user/project/pages/img/pages_project_templates_11-8.png | bin | 0 -> 69702 bytes | |||
| -rw-r--r-- | doc/user/project/pages/index.md | 63 |
10 files changed, 140 insertions, 148 deletions
diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md index 6e64053a6ca..ef85b2f6837 100644 --- a/doc/user/project/clusters/index.md +++ b/doc/user/project/clusters/index.md @@ -182,7 +182,7 @@ To add an existing Kubernetes cluster to your project: namespace: 11 bytes token: <authentication_token> ``` - + NOTE: **Note:** For GKE clusters, you will need the `container.clusterRoleBindings.create` permission to create a cluster @@ -326,7 +326,7 @@ install it manually. NOTE: **Note:** Before starting the installation of applications, make sure that time is synchronized between your GitLab server and your Kubernetes cluster. Otherwise, installation could fail -and you may get errors like `Error: remote error: tls: bad certificate` +and you may get errors like `Error: remote error: tls: bad certificate` in the `stdout` of pods created by GitLab in your Kubernetes cluster. GitLab provides a one-click install for various applications which can @@ -353,7 +353,7 @@ by GitLab before installing any of the applications. | [Cert Manager](http://docs.cert-manager.io/en/latest/) | 11.6+ | Cert Manager is a native Kubernetes certificate management controller that helps with issuing certificates. Installing Cert Manager on your cluster will issue a certificate by [Let's Encrypt](https://letsencrypt.org/) and ensure that certificates are valid and up-to-date. | [stable/cert-manager](https://github.com/helm/charts/tree/master/stable/cert-manager) | | [Prometheus](https://prometheus.io/docs/introduction/overview/) | 10.4+ | Prometheus is an open-source monitoring and alerting system useful to supervise your deployed applications. | [stable/prometheus](https://github.com/helm/charts/tree/master/stable/prometheus) | | [GitLab Runner](https://docs.gitlab.com/runner/) | 10.6+ | GitLab Runner is the open source project that is used to run your jobs and send the results back to GitLab. It is used in conjunction with [GitLab CI/CD](https://about.gitlab.com/features/gitlab-ci-cd/), the open-source continuous integration service included with GitLab that coordinates the jobs. When installing the GitLab Runner via the applications, it will run in **privileged mode** by default. Make sure you read the [security implications](#security-implications) before doing so. | [runner/gitlab-runner](https://gitlab.com/charts/gitlab-runner) | -| [JupyterHub](http://jupyter.org/) | 11.0+ | [JupyterHub](https://jupyterhub.readthedocs.io/en/stable/) is a multi-user service for managing notebooks across a team. [Jupyter Notebooks](https://jupyter-notebook.readthedocs.io/en/latest/) provide a web-based interactive programming environment used for data analysis, visualization, and machine learning. We use a [custom Jupyter image](https://gitlab.com/gitlab-org/jupyterhub-user-image/blob/master/Dockerfile) that installs additional useful packages on top of the base Jupyter. You will also see ready-to-use DevOps Runbooks built with Nurtch's [Rubix library](https://github.com/amit1rrr/rubix). More information on creating executable runbooks can be found in [our Nurtch documentation](runbooks/index.md#nurtch-executable-runbooks). **Note**: Authentication will be enabled for any user of the GitLab server via OAuth2. HTTPS will be supported in a future release. | [jupyter/jupyterhub](https://jupyterhub.github.io/helm-chart/) | +| [JupyterHub](http://jupyter.org/) | 11.0+ | [JupyterHub](https://jupyterhub.readthedocs.io/en/stable/) is a multi-user service for managing notebooks across a team. [Jupyter Notebooks](https://jupyter-notebook.readthedocs.io/en/latest/) provide a web-based interactive programming environment used for data analysis, visualization, and machine learning. We use a [custom Jupyter image](https://gitlab.com/gitlab-org/jupyterhub-user-image/blob/master/Dockerfile) that installs additional useful packages on top of the base Jupyter. Authentication will be enabled only for [project members](../members/index.md) with [Developer or higher](../../permissions.md) access to the project. You will also see ready-to-use DevOps Runbooks built with Nurtch's [Rubix library](https://github.com/amit1rrr/rubix). More information on creating executable runbooks can be found in [our Nurtch documentation](runbooks/index.md#nurtch-executable-runbooks). | [jupyter/jupyterhub](https://jupyterhub.github.io/helm-chart/) | | [Knative](https://cloud.google.com/knative) | 11.5+ | Knative provides a platform to create, deploy, and manage serverless workloads from a Kubernetes cluster. It is used in conjunction with, and includes [Istio](https://istio.io) to provide an external IP address for all programs hosted by Knative. You will be prompted to enter a wildcard domain where your applications will be exposed. Configure your DNS server to use the external IP address for that domain. For any application created and installed, they will be accessible as `<program_name>.<kubernetes_namespace>.<domain_name>`. This will require your kubernetes cluster to have [RBAC enabled](#role-based-access-control-rbac). | [knative/knative](https://storage.googleapis.com/triggermesh-charts) With the exception of Knative, the applications will be installed in a dedicated @@ -387,27 +387,27 @@ Upgrades will reset values back to the values built into the `runner` chart plus the values set by [`values.yaml`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/vendor/runner/values.yaml) -## Getting the external IP address +## Getting the external endpoint NOTE: **Note:** With the following procedure, a load balancer must be installed in your cluster -to obtain the external IP address. You can use either +to obtain the endpoint. You can use either [Ingress](#installing-applications), or Knative's own load balancer ([Istio](https://istio.io)) if using [Knative](#installing-applications). -In order to publish your web application, you first need to find the external IP -address associated to your load balancer. +In order to publish your web application, you first need to find the endpoint which will be either an IP +address or a hostname associated with your load balancer. -### Let GitLab fetch the IP address +### Let GitLab fetch the external endpoint > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17052) in GitLab 10.6. If you [installed Ingress or Knative](#installing-applications), -you should see the Ingress IP address on this same page within a few minutes. -If you don't see this, GitLab might not be able to determine the IP address of +you should see the Ingress Endpoint on this same page within a few minutes. +If you don't see this, GitLab might not be able to determine the external endpoint of your ingress application in which case you should manually determine it. -### Manually determining the IP address +### Manually determining the external endpoint If the cluster is on GKE, click the **Google Kubernetes Engine** link in the **Advanced settings**, or go directly to the @@ -417,7 +417,7 @@ the `gcloud` command in a local terminal or using the **Cloud Shell**. If the cluster is not on GKE, follow the specific instructions for your Kubernetes provider to configure `kubectl` with the right credentials. -The output of the following examples will show the external IP address of your +The output of the following examples will show the external endpoint of your cluster. This information can then be used to set up DNS entries and forwarding rules that allow external access to your deployed applications. @@ -425,19 +425,19 @@ If you installed the Ingress [via the **Applications**](#installing-applications run the following command: ```bash -kubectl get svc --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip} ' +kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}' ``` -For Istio/Knative, the command will be different: +Some Kubernetes clusters return a hostname instead, like [Amazon EKS](https://aws.amazon.com/eks/). For these platforms, run: ```bash -kubectl get svc --namespace=istio-system knative-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip} ' +kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' ``` -Some Kubernetes clusters return a hostname instead, like [Amazon EKS](https://aws.amazon.com/eks/). For these platforms, run: +For Istio/Knative, the command will be different: ```bash -kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps -o jsonpath="{.status.loadBalancer.ingress[0].hostname}". +kubectl get svc --namespace=istio-system knative-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip} ' ``` Otherwise, you can list the IP addresses of all load balancers: @@ -456,13 +456,12 @@ reserved IP. Read how to [promote an ephemeral external IP address in GKE](https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address#promote_ephemeral_ip). -### Pointing your DNS at the cluster IP +### Pointing your DNS at the external endpoint -Once you've set up the static IP, you should associate it to a [wildcard DNS -record](https://en.wikipedia.org/wiki/Wildcard_DNS_record), in order to be able -to reach your apps. This heavily depends on your domain provider, but in case -you aren't sure, just create an A record with a wildcard host like -`*.example.com.`. +Once you've set up the external endpoint, you should associate it with a [wildcard DNS +record](https://en.wikipedia.org/wiki/Wildcard_DNS_record) such as `*.example.com.` +in order to be able to reach your apps. If your external endpoint is an IP address, +use an A record. If your external endpoint is a hostname, use a CNAME record. ## Multiple Kubernetes clusters **[PREMIUM]** diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md index 856ae03f4bc..e6804666e22 100644 --- a/doc/user/project/clusters/serverless/index.md +++ b/doc/user/project/clusters/serverless/index.md @@ -37,9 +37,9 @@ To run Knative on Gitlab, you will need: applications or functions onto your cluster. You can install the GitLab Runner onto the existing Kubernetes cluster. See [Installing Applications](../index.md#installing-applications) for more information. 1. **Domain Name:** Knative will provide its own load balancer using Istio. It will provide an - external IP address for all the applications served by Knative. You will be prompted to enter a + external IP address or hostname for all the applications served by Knative. You will be prompted to enter a wildcard domain where your applications will be served. Configure your DNS server to use the - external IP address for that domain. + external IP address or hostname for that domain. 1. **`.gitlab-ci.yml`:** GitLab uses [Kaniko](https://github.com/GoogleContainerTools/kaniko) to build the application and the [TriggerMesh CLI](https://github.com/triggermesh/tm) to simplify the deployment of knative services and functions. @@ -62,18 +62,8 @@ The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.  -1. After the Knative installation has finished, you can wait for the IP address to be displayed in the - **Knative IP Address** field (takes up to 5 minutes) or retrieve the Istio Ingress IP address by running the following command: - - ```bash - kubectl get svc --namespace=istio-system knative-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip} ' - ``` - - Output: - - ```bash - 35.161.143.124 my-machine-name:~ my-user$ - ``` +1. After the Knative installation has finished, you can wait for the IP address or hostname to be displayed in the + **Knative Endpoint** field or [retrieve the Istio Ingress Endpoint manually](../#manually-determining-the-external-endpoint). NOTE: **Note:** Running `kubectl` commands on your cluster requires setting up access to the cluster first. @@ -82,8 +72,8 @@ The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22. 1. The ingress is now available at this address and will route incoming requests to the proper service based on the DNS name in the request. To support this, a wildcard DNS A record should be created for the desired domain name. For example, - if your Knative base domain is `example.com` then you need to create an A record with domain `*.example.com` - pointing the ip address of the ingress. + if your Knative base domain is `knative.info` then you need to create an A record or CNAME record with domain `*.knative.info` + pointing the ip address or hostname of the ingress.  diff --git a/doc/user/project/cycle_analytics.md b/doc/user/project/cycle_analytics.md index 05127b274e0..19ab911e39f 100644 --- a/doc/user/project/cycle_analytics.md +++ b/doc/user/project/cycle_analytics.md @@ -3,45 +3,40 @@ > [Introduced][ce-5986] in GitLab 8.12. Further features were added in GitLab 8.14. -Cycle Analytics measures the time it takes to go from an [idea to production] for -each project you have. This is achieved by not only indicating the total time it -takes to reach that point, but the total time is broken down into the -multiple stages an idea has to pass through to be shipped. +Cycle Analytics measures the time spent to go from an [idea to production] for +each of your projects. Cycle Analytics displays the median time for an idea to +reach production, along with the time typically spent in each DevOps stage along the way. + +Cycle Analytics is useful in order to quickly determine the velocity of a given +project. It points to bottlenecks in the development process, enabling management +to uncover, triage, and root-cause slowdowns in the software development life cycle. Cycle Analytics is tightly coupled with the [GitLab flow] and calculates a separate median for each stage. ## Overview -You can find the Cycle Analytics page under your project's **Pipelines ➔ Cycle +You can find the Cycle Analytics page under your project's **Project ➔ Cycle Analytics** tab.  -You can see that there are seven stages in total: +There are seven stages that are tracked as part of the Cycle Analytics calculations. - **Issue** (Tracker) - - Median time from issue creation until given a milestone or list label - (first assignment, any milestone, milestone date or assignee is not required) + - Time to schedule an issue (by milestone or by adding it to an issue board) - **Plan** (Board) - - Median time from giving an issue a milestone or label until pushing the - first commit to the branch + - Time to first commit - **Code** (IDE) - - Median time from the first commit to the branch until the merge request is - created + - Time to create a merge request - **Test** (CI) - - Median total test time for all commits/merges + - Time it takes GitLab CI/CD to test your code - **Review** (Merge Request/MR) - - Median time from merge request creation until the merge request is merged - (closed merge requests won't be taken into account) + - Time spent on code review - **Staging** (Continuous Deployment) - - Median time from when the merge request got merged until the deploy to - production (production is last stage/environment) + - Time between merging and deploying to production - **Production** (Total) - - Sum of all the above stages' times excluding the Test (CI) time. To clarify, - it's not so much that CI time is "excluded", but rather CI time is already - counted in the review stage since CI is done automatically. Most of the - other stages are purely sequential, but **Test** is not. + - Total lifecycle time; i.e. the velocity of the project or team ## How the data is measured diff --git a/doc/user/project/img/cycle_analytics_landing_page.png b/doc/user/project/img/cycle_analytics_landing_page.png Binary files differindex 8b17fae5e05..cf46098b9a4 100644 --- a/doc/user/project/img/cycle_analytics_landing_page.png +++ b/doc/user/project/img/cycle_analytics_landing_page.png diff --git a/doc/user/project/integrations/prometheus_library/nginx_ingress.md b/doc/user/project/integrations/prometheus_library/nginx_ingress.md index b7601f26802..de7fc93f0a4 100644 --- a/doc/user/project/integrations/prometheus_library/nginx_ingress.md +++ b/doc/user/project/integrations/prometheus_library/nginx_ingress.md @@ -30,7 +30,7 @@ For other deployments, there is [some configuration](#manually-setting-up-nginx- ### About managed NGINX Ingress deployments -NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's IP](../../clusters/index.md#getting-the-external-ip-address). +NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's Endpoint](../../clusters/index.md#getting-the-external-endpoint). NGINX is configured for Prometheus monitoring, by setting: diff --git a/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md b/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md index 081eb8732ad..31ac53c0d14 100644 --- a/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md +++ b/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md @@ -30,7 +30,7 @@ For other deployments, there is [some configuration](#manually-setting-up-nginx- ### About managed NGINX Ingress deployments -NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's IP](../../clusters/index.md#getting-the-external-ip-address). +NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's Endpoint](../../clusters/index.md#getting-the-external-endpoint). NGINX is configured for Prometheus monitoring, by setting: diff --git a/doc/user/project/pages/getting_started_part_four.md b/doc/user/project/pages/getting_started_part_four.md index 05d5a2fd99a..021139d486d 100644 --- a/doc/user/project/pages/getting_started_part_four.md +++ b/doc/user/project/pages/getting_started_part_four.md @@ -9,14 +9,26 @@ date: 2017-02-22 # Creating and Tweaking GitLab CI/CD for GitLab Pages -[GitLab CI](https://about.gitlab.com/gitlab-ci/) serves +To [get started with GitLab Pages](index.md#getting-started), you can +use one of the project templates, a `.gitlab-ci.yml` template, +or fork an existing example project. Therefore, you don't need to +understand _all_ the ins and odds of GitLab CI/CD to get your site +deployed. Still, there are cases where you want to write your own +script or tweak an existing one. This document guides you through +this process. + +This guide also provides a general overview and clear introduction +for **getting familiar with the `.gitlab-ci.yml` file and writing +one for the first time.** + +[GitLab CI/CD](../../../ci/README.md) serves numerous purposes, to build, test, and deploy your app from GitLab through -[Continuous Integration, Continuous Delivery, and Continuous Deployment](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/) +[Continuous Integration, Continuous Delivery, and Continuous Deployment](../../../ci/introduction/index.md#introduction-to-continuous-methods) methods. You will need it to build your website with GitLab Pages, and deploy it to the Pages server. -To implement GitLab CI/CD, the first thing we need is a configuration +To implement GitLab CI/CD, the first thing you need is a configuration file called `.gitlab-ci.yml` placed at your website's root directory. What this file actually does is telling the @@ -26,7 +38,7 @@ terminal. GitLab CI/CD tells the Runner which commands to run. Both are built-in in GitLab, and you don't need to set up anything for them to work. -Explaining [every detail of GitLab CI](https://docs.gitlab.com/ce/ci/yaml/README.html) +Explaining [every detail of GitLab CI/CD](../../../ci/yaml/README.md) and GitLab Runner is out of the scope of this guide, but we'll need to understand just a few things to be able to write our own `.gitlab-ci.yml` or tweak an existing one. It's an diff --git a/doc/user/project/pages/getting_started_part_two.md b/doc/user/project/pages/getting_started_part_two.md index 644a1c951d3..901fb226cda 100644 --- a/doc/user/project/pages/getting_started_part_two.md +++ b/doc/user/project/pages/getting_started_part_two.md @@ -1,5 +1,5 @@ --- -last_updated: 2018-02-16 +last_updated: 2019-03-05 author: Marcia Ramos author_gitlab: marcia level: beginner @@ -21,8 +21,8 @@ To get started with GitLab Pages, you need: Optional Features: -1. A custom domain or subdomain -1. A DNS pointing your (sub)domain to your Pages site +1. A custom domain or subdomain. +1. A DNS pointing your (sub)domain to your Pages site. 1. **Optional**: an SSL/TLS certificate so your custom domain is accessible under HTTPS. @@ -33,54 +33,73 @@ The optional settings, custom domain, DNS records, and SSL/TLS certificates, are Your GitLab Pages project is a regular project created the same way you do for the other ones. To get started with GitLab Pages, you have three ways: -- Use one of the popular templates already in the app, -- Fork one of the templates from Page Examples, or -- Create a new project from scratch - -Let's go over each option. +- [Use one of the popular project templates bundled with GitLab](#use-one-of-the-popular-pages-templates-bundled-with-gitlab). +- [Fork one of the templates from Page Examples](#fork-a-project-to-get-started-from). +- [Create a new project from scratch](#create-a-project-from-scratch). ### Use one of the popular Pages templates bundled with GitLab > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/47857) in GitLab 11.8. -The simplest way to create a GitLab Pages site is to use one of the most -popular templates, which come already bundled and ready to go. To use one -of these templates: - -1. From the top navigation, click the **+** button and select **New project** -1. Select **Create from Template** -1. Choose one of the templates starting with **Pages** +The simplest way to create a GitLab Pages site is to +[use one of the most popular templates](index.md#getting-started), +which come already bundled with GitLab and are ready to go. ### Fork a project to get started from -To make things easy for you, we've created this -[group](https://gitlab.com/pages) of default projects -containing the most popular SSGs templates. - -Watch the [video tutorial](https://youtu.be/TWqh9MtT4Bg) we've -created for the steps below. - -1. [Fork a sample project](../../../gitlab-basics/fork-project.md) from the [Pages group](https://gitlab.com/pages) -1. Trigger a build (push a change to any file) -1. As soon as the build passes, your website will have been deployed with GitLab Pages. Your website URL will be available under your project's **Settings** > **Pages** -1. Optionally, remove the fork relationship by navigating to your project's **Settings** > expanding **Advanced settings** and scrolling down to **Remove fork relationship**: +If you don't find an existing project template that suits you, +we've created this [group](https://gitlab.com/pages) of default projects +containing the most popular SSGs templates to get you started. + +<table class="borderless-table center fixed-table middle width-80"> + <tr> + <td style="width: 30%"><img src="img/icons/fork.png" alt="Fork" class="image-noshadow half-width"></td> + <td style="width: 10%"> + <strong> + <i class="fa fa-angle-double-right" aria-hidden="true"></i> + </strong> + </td> + <td style="width: 30%"><img src="img/icons/terminal.png" alt="Deploy" class="image-noshadow half-width"></td> + <td style="width: 10%"> + <strong> + <i class="fa fa-angle-double-right" aria-hidden="true"></i> + </strong> + </td> + <td style="width: 30%"><img src="img/icons/click.png" alt="Visit" class="image-noshadow half-width"></td> + </tr> + <tr> + <td><em>Fork an example project</em></td> + <td></td> + <td><em>Deploy your website</em></td> + <td></td> + <td><em>Visit your website's URL</em></td> + </tr> +</table> + +**<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Watch a [video tutorial](https://www.youtube.com/watch?v=TWqh9MtT4Bg) with all the steps below.** + +1. [Fork](../../../gitlab-basics/fork-project.md) a sample project from the [GitLab Pages examples](https://gitlab.com/pages) group. +1. From the left sidebar, navigate to your project's **CI/CD > Pipelines** +and click **Run pipeline** to trigger GitLab CI/CD to build and deploy your +site to the server. +1. Once the pipeline has finished successfully, find the link to visit your +website from your project's **Settings > Pages**. + +You can also take some **optional** further steps: + +- _Remove the fork relationship._ The fork relashionship is necessary to contribute back to the project you originally forked from. If you don't have any intentions to do so, you can remove it. To do so, navigate to your project's **Settings**, expand **Advanced settings**, and scroll down to **Remove fork relationship**:  -To turn a **project website** forked from the Pages group into a **user/group** website, you'll need to: - -- Rename it to `namespace.gitlab.io`: navigate to project's **Settings** > expand **Advanced settings** > and scroll down to **Rename repository** -- Adjust your SSG's [base URL](#urls-and-baseurls) from `"project-name"` to `""`. This setting will be at a different place for each SSG, as each of them have their own structure and file tree. Most likely, it will be in the SSG's config file. - -> **Notes:** -> -> Why do I need to remove the fork relationship? -> -> Unless you want to contribute to the original project, -you won't need it connected to the upstream. A -[fork](https://about.gitlab.com/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/#fork) -is useful for submitting merge requests to the upstream. +- _Make it a user or group website._ To turn a **project website** forked +from the Pages group into a **user/group** website, you'll need to: + - Rename it to `namespace.gitlab.io`: navigate to project's **Settings** > + expand **Advanced settings** > and scroll down to **Rename repository**. + - Adjust your SSG's [base URL](#urls-and-baseurls) from `"project-name"` to + `""`. This setting will be at a different place for each SSG, as each of them + have their own structure and file tree. Most likely, it will be in the SSG's + config file. ### Create a project from scratch diff --git a/doc/user/project/pages/img/pages_project_templates_11-8.png b/doc/user/project/pages/img/pages_project_templates_11-8.png Binary files differnew file mode 100644 index 00000000000..a645d28260b --- /dev/null +++ b/doc/user/project/pages/img/pages_project_templates_11-8.png diff --git a/doc/user/project/pages/index.md b/doc/user/project/pages/index.md index ee471fa6534..885df9f0850 100644 --- a/doc/user/project/pages/index.md +++ b/doc/user/project/pages/index.md @@ -1,5 +1,6 @@ --- description: 'Learn how to use GitLab Pages to deploy a static website at no additional cost.' +last_updated: 2019-03-05 --- # GitLab Pages @@ -8,8 +9,8 @@ description: 'Learn how to use GitLab Pages to deploy a static website at no add directly from a repository in GitLab.** You can use it either for personal or business websites, such as -portfolios, documentation, manifestos, and business presentations, -and attribute any license to your content. +portfolios, documentation, manifestos, and business presentations. +You can also attribute any license to your content. <table class="borderless-table center fixed-table"> <tr> @@ -91,52 +92,28 @@ site under the HTTPS protocol. ## Getting started -To get started with GitLab Pages, you can either [create a project from scratch](getting_started_part_two.md#create-a-project-from-scratch), -use a [bundled template](getting_started_part_two.md#use-one-of-the-popular-pages-templates-bundled-with-gitlab), or copy any of our existing example projects: +To get started with GitLab Pages, you can either: -1. Choose an [example project](https://gitlab.com/pages) to [fork](../../../gitlab-basics/fork-project.md#how-to-fork-a-project): - by forking a project, you create a copy of the codebase you're forking from to start from a template instead of starting from scratch. -1. From the left sidebar, navigate to your project's **CI/CD > Pipelines** and click - **Run pipeline** so that GitLab CI/CD will build and deploy your site to the server. -1. Once the pipeline has finished successfully, find the link to visit your website from your - project's **Settings > Pages**. +- [Create a project from scratch](getting_started_part_two.md#create-a-project-from-scratch). +- [Copy an existing example project](getting_started_part_two.md#fork-a-project-to-get-started-from). +- Use a bundled project template that is ready to go ([introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/47857) +in GitLab 11.8), as follows: -<table class="borderless-table center fixed-table middle width-80"> - <tr> - <td style="width: 30%"><img src="img/icons/fork.png" alt="Fork" class="image-noshadow half-width"></td> - <td style="width: 10%"> - <strong> - <i class="fa fa-angle-double-right" aria-hidden="true"></i> - </strong> - </td> - <td style="width: 30%"><img src="img/icons/terminal.png" alt="Deploy" class="image-noshadow half-width"></td> - <td style="width: 10%"> - <strong> - <i class="fa fa-angle-double-right" aria-hidden="true"></i> - </strong> - </td> - <td style="width: 30%"><img src="img/icons/click.png" alt="Visit" class="image-noshadow half-width"></td> - </tr> - <tr> - <td><em>Fork an example project</em></td> - <td></td> - <td><em>Deploy your website</em></td> - <td></td> - <td><em>Visit your website's URL</em></td> - </tr> -</table> - -Your website is then visible on your domain, and you can modify your files -as you wish. For every modification pushed to your repository, GitLab CI/CD will run -a new pipeline to publish your changes to the server. +1. From the top navigation, click the **+** button and select **New project**. +1. Select **Create from Template**. +1. Choose one of the templates starting with **Pages**: -You can also take some optional further steps: +  -- Remove the [fork relationship](getting_started_part_two.md#fork-a-project-to-get-started-from) - (_You don't need the relationship unless you intent to contribute back to the example project you forked from_). -- Make it a [user/group website](getting_started_part_one.md#user-and-group-websites) +1. From the left sidebar, navigate to your project's **CI/CD > Pipelines** +and click **Run pipeline** to trigger GitLab CI/CD to build and deploy your +site to the server. +1. Once the pipeline has finished successfully, find the link to visit your +website from your project's **Settings > Pages**. -**<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Watch a [video tutorial](https://www.youtube.com/watch?v=TWqh9MtT4Bg) with all the steps above!** +Your website is then visible on your domain, and you can modify yourfiles +as you wish. For every modification pushed to your repository, GitLab CI/CD +will run a new pipeline to publish your changes to the server. _Advanced options:_ |
