Commit 6b1ba27e authored by GitLab Bot's avatar GitLab Bot

Add latest changes from gitlab-org/gitlab@master

parent 6435f44b
...@@ -321,7 +321,7 @@ cache: ...@@ -321,7 +321,7 @@ cache:
before_script: before_script:
- ruby -v # Print out ruby version for debugging - ruby -v # Print out ruby version for debugging
- bundle install -j $(nproc) --path vendor # Install dependencies into ./vendor/ruby - bundle install -j $(nproc) --path vendor/ruby # Install dependencies into ./vendor/ruby
rspec: rspec:
script: script:
......
...@@ -31,14 +31,14 @@ it often results in receiving extra commit logs. ...@@ -31,14 +31,14 @@ it often results in receiving extra commit logs.
Ideally, you should always use `GIT_DEPTH` with a small number Ideally, you should always use `GIT_DEPTH` with a small number
like 10. This will instruct GitLab Runner to perform shallow clones. like 10. This will instruct GitLab Runner to perform shallow clones.
Shallow clones makes Git request only the latest set of changes for a given branch, Shallow clones make Git request only the latest set of changes for a given branch,
up to desired number of commits as defined by the `GIT_DEPTH` variable. up to desired number of commits as defined by the `GIT_DEPTH` variable.
This significantly speeds up fetching of changes from Git repositories, This significantly speeds up fetching of changes from Git repositories,
especially if the repository has a very long backlog consisting of number especially if the repository has a very long backlog consisting of number
of big files as we effectively reduce amount of data transfer. of big files as we effectively reduce amount of data transfer.
The following example makes GitLab Runner shallow clone to fetch only a given branch, The following example makes GitLab Runner shallow clone to fetch only a given branch;
it does not fetch any other branches nor tags. it does not fetch any other branches nor tags.
```yaml ```yaml
...@@ -107,7 +107,7 @@ clean` is disk I/O intensive. Controlling that with `GIT_CLEAN_FLAGS: -ffdx ...@@ -107,7 +107,7 @@ clean` is disk I/O intensive. Controlling that with `GIT_CLEAN_FLAGS: -ffdx
-e .build/`, for example, allows you to control and disable removal of some -e .build/`, for example, allows you to control and disable removal of some
directories within the worktree between subsequent runs, which can speed-up directories within the worktree between subsequent runs, which can speed-up
the incremental builds. This has the biggest effect if you re-use existing the incremental builds. This has the biggest effect if you re-use existing
machines, and have an existing worktree that you can re-use for builds. machines and have an existing worktree that you can re-use for builds.
For exact parameters accepted by For exact parameters accepted by
[`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags), see the documentation [`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags), see the documentation
...@@ -118,19 +118,19 @@ are dependent on Git version. ...@@ -118,19 +118,19 @@ are dependent on Git version.
> Introduced in GitLab Runner 11.10. > Introduced in GitLab Runner 11.10.
Following the guidelines above, lets imagine that we want to: Following the guidelines above, let's imagine that we want to:
- Optimize for a big project (more than 50k files in directory). - Optimize for a big project (more than 50k files in directory).
- Use forks-based workflow for contributing. - Use forks-based workflow for contributing.
- Reuse existing worktrees. Have preconfigured runners that are pre-cloned with repositories. - Reuse existing worktrees. Have preconfigured runners that are pre-cloned with repositories.
- Runner assigned only to project and all forks. - Runner assigned only to project and all forks.
Lets consider the following two examples, one using `shell` executor and Let's consider the following two examples, one using `shell` executor and
other using `docker` executor. other using `docker` executor.
### `shell` executor example ### `shell` executor example
Lets assume that you have the following [config.toml](https://docs.gitlab.com/runner/configuration/advanced-configuration.html). Let's assume that you have the following [config.toml](https://docs.gitlab.com/runner/configuration/advanced-configuration.html).
```toml ```toml
concurrent = 4 concurrent = 4
...@@ -155,7 +155,7 @@ This `config.toml`: ...@@ -155,7 +155,7 @@ This `config.toml`:
### `docker` executor example ### `docker` executor example
Lets assume that you have the following [config.toml](https://docs.gitlab.com/runner/configuration/advanced-configuration.html). Let's assume that you have the following [config.toml](https://docs.gitlab.com/runner/configuration/advanced-configuration.html).
```toml ```toml
concurrent = 4 concurrent = 4
...@@ -238,5 +238,5 @@ concurrent = 4 ...@@ -238,5 +238,5 @@ concurrent = 4
volumes = ["/builds:/builds", "/cache:/cache"] volumes = ["/builds:/builds", "/cache:/cache"]
``` ```
This makes the cloning configuration to be part of given Runner, This makes the cloning configuration to be part of given Runner
and does not require us to update each `.gitlab-ci.yml`. and does not require us to update each `.gitlab-ci.yml`.
...@@ -31,7 +31,7 @@ set of concurrently running child pipelines, but within the same project: ...@@ -31,7 +31,7 @@ set of concurrently running child pipelines, but within the same project:
- The configuration is split up into smaller child pipeline configurations, which are - The configuration is split up into smaller child pipeline configurations, which are
easier to understand. This reduces the cognitive load to understand the overall configuration. easier to understand. This reduces the cognitive load to understand the overall configuration.
- Imports are done at the child pipeline level, reducing the likelihood of collisions. - Imports are done at the child pipeline level, reducing the likelihood of collisions.
- Each pipeline has only the steps relevant steps, making it easier to understand what's going on. - Each pipeline has only relevant steps, making it easier to understand what's going on.
Child pipelines work well with other GitLab CI features: Child pipelines work well with other GitLab CI features:
...@@ -40,7 +40,7 @@ Child pipelines work well with other GitLab CI features: ...@@ -40,7 +40,7 @@ Child pipelines work well with other GitLab CI features:
- Since the parent pipeline in `.gitlab-ci.yml` and the child pipeline run as normal - Since the parent pipeline in `.gitlab-ci.yml` and the child pipeline run as normal
pipelines, they can have their own behaviors and sequencing in relation to triggers. pipelines, they can have their own behaviors and sequencing in relation to triggers.
All of this will work with [`include:`](yaml/README.md#include) feature so you can compose All of this will work with the [`include:`](yaml/README.md#include) feature so you can compose
the child pipeline configuration. the child pipeline configuration.
## Examples ## Examples
......
This diff is collapsed.
...@@ -740,6 +740,7 @@ running: ...@@ -740,6 +740,7 @@ running:
```shell ```shell
sudo gitlab-ctl stop unicorn sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq sudo gitlab-ctl stop sidekiq
# Verify # Verify
sudo gitlab-ctl status sudo gitlab-ctl status
......
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