diff options
Diffstat (limited to 'doc/ci')
| -rw-r--r-- | doc/ci/README.md | 1 | ||||
| -rw-r--r-- | doc/ci/autodeploy/img/autodeploy_button.png | bin | 0 -> 41799 bytes | |||
| -rw-r--r-- | doc/ci/autodeploy/img/autodeploy_dropdown.png | bin | 0 -> 46761 bytes | |||
| -rw-r--r-- | doc/ci/autodeploy/index.md | 39 | ||||
| -rw-r--r-- | doc/ci/environments.md | 45 | ||||
| -rw-r--r-- | doc/ci/img/environments_terminal_button_on_index.png | bin | 0 -> 79725 bytes | |||
| -rw-r--r-- | doc/ci/img/environments_terminal_button_on_show.png | bin | 0 -> 73210 bytes | |||
| -rw-r--r-- | doc/ci/img/environments_terminal_page.png | bin | 0 -> 117863 bytes | |||
| -rw-r--r-- | doc/ci/pipelines.md | 31 |
9 files changed, 115 insertions, 1 deletions
diff --git a/doc/ci/README.md b/doc/ci/README.md index 73bd2516d46..6a9495f8892 100644 --- a/doc/ci/README.md +++ b/doc/ci/README.md @@ -23,6 +23,7 @@ - [CI/CD pipelines settings](../user/project/pipelines/settings.md) - [Review Apps](review_apps/index.md) - [Git submodules](git_submodules.md) Using Git submodules in your CI jobs +- [Autodeploy](autodeploy/index.md) ## Breaking changes diff --git a/doc/ci/autodeploy/img/autodeploy_button.png b/doc/ci/autodeploy/img/autodeploy_button.png Binary files differnew file mode 100644 index 00000000000..9e2cd57a0ba --- /dev/null +++ b/doc/ci/autodeploy/img/autodeploy_button.png diff --git a/doc/ci/autodeploy/img/autodeploy_dropdown.png b/doc/ci/autodeploy/img/autodeploy_dropdown.png Binary files differnew file mode 100644 index 00000000000..1486a8ec0ea --- /dev/null +++ b/doc/ci/autodeploy/img/autodeploy_dropdown.png diff --git a/doc/ci/autodeploy/index.md b/doc/ci/autodeploy/index.md new file mode 100644 index 00000000000..503a00969d5 --- /dev/null +++ b/doc/ci/autodeploy/index.md @@ -0,0 +1,39 @@ +# Autodeploy + +> [Introduced][mr-8135] in GitLab 8.15. + +Autodeploy is an easy way to configure GitLab CI for the deployment of your +application. GitLab Community maintains a list of `.gitlab-ci.yml` +templates for various infrastructure providers and deployment scripts +powering them. These scripts are responsible for packaging your application, +setting up the infrastructure and spinning up necessary services (for +example a database). + +You can use [project services][project-services] to store credentials to +your infrastructure provider and they will be available during the +deployment. + +## Supported templates + +The list of supported autodeploy templates is available [here][autodeploy-templates]. + +## Configuration + +1. Enable a deployment [project service][project-services] to store your +credentials. For example, if you want to deploy to a Kubernetes cluster +you have to enable [Kubernetes service][kubernetes-service]. +1. Configure GitLab Runner to use [docker-in-docker executor][docker-in-docker]. +1. Navigate to the "Project" tab and click "Set up autodeploy" button. +  +1. Select a template. +  +1. Commit your changes and create a merge request. +1. Test your deployment configuration using a [Review App][review-app] that was +created automatically for you. + +[mr-8135]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8135 +[project-services]: ../../project_services/project_services.md +[autodeploy-templates]: https://gitlab.com/gitlab-org/gitlab-ci-yml/tree/master/autodeploy +[kubernetes-service]: ../../project_services/kubernetes.md +[docker-in-docker]: ../docker/using_docker_build.md#use-docker-in-docker-executor +[review-app]: ../review_apps/index.md diff --git a/doc/ci/environments.md b/doc/ci/environments.md index bad0233a9ce..98cd29c9567 100644 --- a/doc/ci/environments.md +++ b/doc/ci/environments.md @@ -25,7 +25,9 @@ Environments are like tags for your CI jobs, describing where code gets deployed Deployments are created when [jobs] deploy versions of code to environments, so every environment can have one or more deployments. GitLab keeps track of your deployments, so you always know what is currently being deployed on your -servers. +servers. If you have a deployment service such as [Kubernetes][kubernetes-service] +enabled for your project, you can use it to assist with your deployments, and +can even access a web terminal for your environment from within GitLab! To better understand how environments and deployments work, let's consider an example. We assume that you have already created a project in GitLab and set up @@ -233,6 +235,46 @@ Remember that if your environment's name is `production` (all lowercase), then it will get recorded in [Cycle Analytics](../user/project/cycle_analytics.md). Double the benefit! +## Web terminals + +>**Note:** +Web terminals were added in GitLab 8.15 and are only available to project +masters and owners. + +If you deploy to your environments with the help of a deployment service (e.g., +the [Kubernetes](../project_services/kubernetes.md) service), GitLab can open +a terminal session to your environment! This is a very powerful feature that +allows you to debug issues without leaving the comfort of your web browser. To +enable it, just follow the instructions given in the service documentation. + +Once enabled, your environments will gain a "terminal" button: + + + +You can also access the terminal button from the page for a specific environment: + + + +Wherever you find it, clicking the button will take you to a separate page to +establish the terminal session: + + + +This works just like any other terminal - you'll be in the container created +by your deployment, so you can run shell commands and get responses in real +time, check the logs, try out configuration or code tweaks, etc. You can open +multiple terminals to the same environment - they each get their own shell +session - and even a multiplexer like `screen` or `tmux`! + +>**Note:** +Container-based deployments often lack basic tools (like an editor), and may +be stopped or restarted at any time. If this happens, you will lose all your +changes! Treat this as a debugging tool, not a comprehensive online IDE. You +can use [Koding](../administration/integration/koding.md) for online +development. + +--- + While this is fine for deploying to some stable environments like staging or production, what happens for branches? So far we haven't defined anything regarding deployments for branches other than `master`. Dynamic environments @@ -524,6 +566,7 @@ Below are some links you may find interesting: [Pipelines]: pipelines.md [jobs]: yaml/README.md#jobs [yaml]: yaml/README.md +[kubernetes-service]: ../project_services/kubernetes.md] [environments]: #environments [deployments]: #deployments [permissions]: ../user/permissions.md diff --git a/doc/ci/img/environments_terminal_button_on_index.png b/doc/ci/img/environments_terminal_button_on_index.png Binary files differnew file mode 100644 index 00000000000..6f05b2aa343 --- /dev/null +++ b/doc/ci/img/environments_terminal_button_on_index.png diff --git a/doc/ci/img/environments_terminal_button_on_show.png b/doc/ci/img/environments_terminal_button_on_show.png Binary files differnew file mode 100644 index 00000000000..9469fab99ab --- /dev/null +++ b/doc/ci/img/environments_terminal_button_on_show.png diff --git a/doc/ci/img/environments_terminal_page.png b/doc/ci/img/environments_terminal_page.png Binary files differnew file mode 100644 index 00000000000..fde1bf325a6 --- /dev/null +++ b/doc/ci/img/environments_terminal_page.png diff --git a/doc/ci/pipelines.md b/doc/ci/pipelines.md index 03b9c4bb444..f91b9d350f7 100644 --- a/doc/ci/pipelines.md +++ b/doc/ci/pipelines.md @@ -36,6 +36,37 @@ Clicking on a pipeline will show the builds that were run for that pipeline. Clicking on an individual build will show you its build trace, and allow you to cancel the build, retry it, or erase the build trace. +## How the pipeline duration is calculated + +Total running time for a given pipeline would exclude retries and pending +(queue) time. We could reduce this problem down to finding the union of +periods. + +So each job would be represented as a `Period`, which consists of +`Period#first` as when the job started and `Period#last` as when the +job was finished. A simple example here would be: + +* A (1, 3) +* B (2, 4) +* C (6, 7) + +Here A begins from 1, and ends to 3. B begins from 2, and ends to 4. +C begins from 6, and ends to 7. Visually it could be viewed as: + +``` +0 1 2 3 4 5 6 7 + AAAAAAA + BBBBBBB + CCCC +``` + +The union of A, B, and C would be (1, 4) and (6, 7), therefore the +total running time should be: + +``` +(4 - 1) + (7 - 6) => 4 +``` + ## Badges Build status and test coverage report badges are available. You can find their |
