Commit 90b2cb31 authored by Marcel Amirault's avatar Marcel Amirault 🌴 Committed by Evan Read

Improve capitalization and backticks in ci docs

Clean up capitalization of product names, as well
as improve backtick use in /ci docs
parent 3a4cf015
......@@ -113,7 +113,7 @@ Its feature set is listed on the table below according to DevOps stages.
| [Browser Performance Testing](../user/project/merge_requests/browser_performance_testing.md) | Quickly determine the performance impact of pending code changes. |
| [CI services](services/README.md) | Link Docker containers with your base image.|
| [Code Quality](../user/project/merge_requests/code_quality.md) **(STARTER)** | Analyze your source code quality. |
| [GitLab CI/CD for external repositories](ci_cd_for_external_repos/index.md) **(PREMIUM)** | Get the benefits of GitLab CI/CD combined with repositories in GitHub and BitBucket Cloud. |
| [GitLab CI/CD for external repositories](ci_cd_for_external_repos/index.md) **(PREMIUM)** | Get the benefits of GitLab CI/CD combined with repositories in GitHub and Bitbucket Cloud. |
| [Interactive Web Terminals](interactive_web_terminal/index.md) **(CORE ONLY)** | Open an interactive web terminal to debug the running jobs. |
| [JUnit tests](junit_test_reports.md) | Identify script failures directly on merge requests. |
| [Using Docker images](docker/using_docker_images.md) | Use GitLab and GitLab Runner with Docker to build and test applications. |
......
......@@ -202,7 +202,7 @@ For more fine tuning, read also about the
The most common use case of cache is to preserve contents between subsequent
runs of jobs for things like dependencies and commonly used libraries
(Nodejs packages, PHP packages, rubygems, python libraries, etc.),
(Nodejs packages, PHP packages, rubygems, Python libraries, etc.),
so they don't have to be re-fetched from the public internet.
NOTE: **Note:**
......@@ -268,7 +268,7 @@ test:
### Caching Python dependencies
Assuming your project is using [pip](https://pip.pypa.io/en/stable/) to install
the python dependencies, the following example defines `cache` globally so that
the Python dependencies, the following example defines `cache` globally so that
all jobs inherit it. Python libraries are installed in a virtualenv under `venv/`,
pip's cache is defined under `.cache/pip/` and both are cached per-branch:
......
......@@ -19,7 +19,7 @@ GitLab ChatOps is built upon two existing features:
- [GitLab CI/CD](../README.md).
- [Slack Slash Commands](../../user/project/integrations/slack_slash_commands.md).
A new `run` action has been added to the [slash commands](../../integration/slash_commands.md), which takes two arguments: a `<job name>` to execute and the `<job arguments>`. When executed, ChatOps will look up the specified job name and attempt to match it to a corresponding job in [.gitlab-ci.yml](../yaml/README.md). If a matching job is found on `master`, a pipeline containing just that job is scheduled. Two additional [CI/CD variables](../variables/README.md#predefined-environment-variables) are passed to the job: `CHAT_INPUT` contains any additional arguments, and `CHAT_CHANNEL` is set to the name of channel the action was triggered in.
A new `run` action has been added to the [slash commands](../../integration/slash_commands.md), which takes two arguments: a `<job name>` to execute and the `<job arguments>`. When executed, ChatOps will look up the specified job name and attempt to match it to a corresponding job in [`.gitlab-ci.yml`](../yaml/README.md). If a matching job is found on `master`, a pipeline containing just that job is scheduled. Two additional [CI/CD variables](../variables/README.md#predefined-environment-variables) are passed to the job: `CHAT_INPUT` contains any additional arguments, and `CHAT_CHANNEL` is set to the name of channel the action was triggered in.
After the job has finished, its output is sent back to Slack provided it has completed within 30 minutes. If a job takes more than 30 minutes to run it must use the Slack API to manually send data back to a channel.
......
......@@ -73,4 +73,4 @@ A directed acyclic graph is a complicated feature, and as of the initial MVC the
are certain use cases that you may need to work around. For more information:
- [`needs` requirements and limitations](../yaml/README.md#requirements-and-limitations).
- Related epic [gitlab-org#1716](https://gitlab.com/groups/gitlab-org/-/epics/1716).
- Related epic [#1716](https://gitlab.com/groups/gitlab-org/-/epics/1716).
......@@ -526,7 +526,7 @@ Some things you should be aware of:
longer, but means you don’t get stuck without security patches to base images.
- Doing an explicit `docker pull` before each `docker run` fetches
the latest image that was just built. This is especially important if you are
using multiple runners that cache images locally. Using the git SHA in your
using multiple runners that cache images locally. Using the Git SHA in your
image tag makes this less necessary since each job will be unique and you
shouldn't ever have a stale image. However, it's still possible to have a
stale image if you re-build a given commit after a dependency has changed.
......
......@@ -679,7 +679,7 @@ fetch = +refs/environments/*:refs/remotes/origin/environments/*
### Scoping environments with specs
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/2112) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.4.
> - [Scoping for environment variables was moved to Core](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/30779) to Core in Gitlab 12.2.
> - [Scoping for environment variables was moved to Core](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/30779) to Core in GitLab 12.2.
You can limit the environment scope of a variable by
defining which environments it can be available for.
......
......@@ -13,7 +13,7 @@ Examples are available in several forms. As a collection of:
- `.gitlab-ci.yml` [template files](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/lib/gitlab/ci/templates) maintained in GitLab. When you create a new file via the UI,
GitLab will give you the option to choose one of these templates. This will allow you to quickly bootstrap your project for CI/CD.
If your favorite programming language or framework are missing, we would love your help by sending a merge request with a new `.gitlab-ci.yml` to this project.
- Repositories with [example projects](https://gitlab.com/gitlab-examples) for various languages. You can fork and adjust them to your own needs. Projects include demonstrations of [multi-project pipelines](https://gitlab.com/gitlab-examples/multi-project-pipelines) and using [Review Apps with a static site served by nginx](https://gitlab.com/gitlab-examples/review-apps-nginx/).
- Repositories with [example projects](https://gitlab.com/gitlab-examples) for various languages. You can fork and adjust them to your own needs. Projects include demonstrations of [multi-project pipelines](https://gitlab.com/gitlab-examples/multi-project-pipelines) and using [Review Apps with a static site served by NGINX](https://gitlab.com/gitlab-examples/review-apps-nginx/).
- Examples and [other resources](#other-resources) listed below.
## CI/CD examples
......
......@@ -46,7 +46,7 @@ staging:
- dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY
```
In the above example we use Dpl to deploy `my-app-staging` to Heroku server with api-key stored in `HEROKU_STAGING_API_KEY` secure variable.
In the above example we use Dpl to deploy `my-app-staging` to Heroku server with API key stored in `HEROKU_STAGING_API_KEY` secure variable.
To use different provider take a look at long list of [Supported Providers](https://github.com/travis-ci/dpl#supported-providers).
......
......@@ -46,7 +46,7 @@ All these operations will put all files into a `build` folder, which is ready to
You have multiple options: rsync, scp, sftp and so on. For now, we will use scp.
To make this work, you need to add a GitLab CI/CD Variable (accessible on _gitlab.example/your-project-name/variables_). That variable will be called `STAGING_PRIVATE_KEY` and it's the **private** ssh key of your server.
To make this work, you need to add a GitLab CI/CD Variable (accessible on `gitlab.example/your-project-name/variables`). That variable will be called `STAGING_PRIVATE_KEY` and it's the **private** SSH key of your server.
### Security tip
......@@ -98,7 +98,7 @@ Here's the breakdown:
1. We will connect via `ssh` and create a new `_tmp` folder
1. We will connect via `scp` and upload the `build` folder (which was generated by a `npm` script) to our previously created `_tmp` folder
1. We will connect again via `ssh` and move the `live` folder to an `_old` folder, then move `_tmp` to `live`.
1. We connect to ssh and remove the `_old` folder
1. We connect to SSH and remove the `_old` folder
What's the deal with the artifacts? We just tell GitLab CI to keep the `build` directory (later on, you can download that as needed).
......
......@@ -28,7 +28,7 @@ layers of your application, from the frontend to the database.
In this article, we will discuss how
to write such end-to-end tests, and how to set up GitLab CI/CD to automatically run these tests
against your new code, on a branch-by-branch basis. For the scope of this article, we will walk you
through the process of setting up GitLab CI/CD for end-to-end testing Javascript-based applications
through the process of setting up GitLab CI/CD for end-to-end testing JavaScript-based applications
with WebdriverIO, but the general strategy should carry over to other languages.
We assume you are familiar with GitLab, [GitLab CI/CD](../../README.md), [Review Apps](../../review_apps/index.md), and running your app locally, e.g., on `localhost:8000`.
......@@ -47,7 +47,7 @@ infrastructure is up and running, and that your units of code work well together
[Selenium](http://www.seleniumhq.org/) is a piece of software that can control web browsers, e.g., to make them
visit a specific URL or interact with elements on the page. It can be programmatically controlled
from a variety of programming languages. In this article we're going to be using the
[WebdriverIO](http://webdriver.io/) Javascript bindings, but the general concept should carry over
[WebdriverIO](http://webdriver.io/) JavaScript bindings, but the general concept should carry over
pretty well to
[other programming languages supported by Selenium](http://docs.seleniumhq.org/about/platforms.jsp#programming-languages).
......
......@@ -82,7 +82,7 @@ git push -u origin master
## Configure the production server
Before we begin setting up Envoy and GitLab CI/CD, let's quickly make sure the production server is ready for deployment.
We have installed LEMP stack which stands for Linux, Nginx, MySQL and PHP on our Ubuntu 16.04.
We have installed LEMP stack which stands for Linux, NGINX, MySQL and PHP on our Ubuntu 16.04.
### Create a new user
......@@ -151,11 +151,11 @@ git clone [email protected]:<USERNAME>/laravel-sample.git
Answer **yes** if asked `Are you sure you want to continue connecting (yes/no)?`.
It adds GitLab.com to the known hosts.
### Configuring Nginx
### Configuring NGINX
Now, let's make sure our web server configuration points to the `current/public` rather than `public`.
Open the default Nginx server block configuration file by typing:
Open the default NGINX server block configuration file by typing:
```bash
sudo nano /etc/nginx/sites-available/default
......
......@@ -86,6 +86,6 @@ gitlab-runner register \
--docker-postgres latest
```
With the command above, you create a runner that uses the [python:3.5](https://hub.docker.com/r/_/python/) image and uses a [postgres](https://hub.docker.com/r/_/postgres/) database.
With the command above, you create a runner that uses the [`python:3.5`](https://hub.docker.com/r/_/python/) image and uses a [PostgreSQL](https://hub.docker.com/r/_/postgres/) database.
To access the PostgreSQL database, connect to `host: postgres` as user `postgres` with no password.
......@@ -205,7 +205,7 @@ when running our Phoenix in our `localhost`.
As our project is still fresh, we don't have any data on our database, so, the `migrations`
directory will be empty.
Without `.gitkeep`, git will not upload this empty directory and we'll got an error when running our
Without `.gitkeep`, Git will not upload this empty directory and we'll got an error when running our
test on GitLab.
> **Note:** If we add a folder via the GitLab UI, GitLab itself will add the `.gitkeep` to that new dir.
......
......@@ -30,7 +30,7 @@ Two things need to be configured for the interactive web terminal to work:
NOTE: **Note:**
Interactive web terminals are not yet supported by
[`gitlab-runner` helm chart](https://docs.gitlab.com/charts/charts/gitlab/gitlab-runner/index.html),
[`gitlab-runner` Helm chart](https://docs.gitlab.com/charts/charts/gitlab/gitlab-runner/index.html),
but support [is planned](https://gitlab.com/gitlab-org/charts/gitlab-runner/issues/79).
## Debugging a running job
......
......@@ -202,7 +202,7 @@ can provide any variables they like.
#### `triggers` / `cron`
Because GitLab is integrated tightly with git, SCM polling options for triggers are not needed. We support an easy to use
Because GitLab is integrated tightly with Git, SCM polling options for triggers are not needed. We support an easy to use
[syntax for scheduling pipelines](../../user/project/pipelines/schedules.md).
#### `tools`
......
......@@ -111,7 +111,7 @@ machines, and have an existing worktree that you can re-use for builds.
For exact parameters accepted by
[`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags), see the documentation
for [git clean](https://git-scm.com/docs/git-clean). The available parameters
for [`git clean`](https://git-scm.com/docs/git-clean). The available parameters
are dependent on Git version.
## Fork-based workflow
......
......@@ -22,7 +22,7 @@ GitLab offers a [continuous integration][ci] service. If you
and configure your GitLab project to use a [Runner], then each commit or
push triggers your CI [pipeline].
The `.gitlab-ci.yml` file tells the GitLab runner what to do. By default it runs
The `.gitlab-ci.yml` file tells the GitLab Runner what to do. By default it runs
a pipeline with three [stages]: `build`, `test`, and `deploy`. You don't need to
use all three stages; stages with no jobs are simply ignored.
......@@ -126,7 +126,7 @@ a "CI Lint" button to go to this page under **CI/CD ➔ Pipelines** and
**Pipelines ➔ Jobs** in your project.
For more information and a complete `.gitlab-ci.yml` syntax, please read
[the reference documentation on .gitlab-ci.yml](../yaml/README.md).
[the reference documentation on `.gitlab-ci.yml`](../yaml/README.md).
### Push `.gitlab-ci.yml` to GitLab
......
......@@ -25,10 +25,10 @@ with any type of [executor](https://docs.gitlab.com/runner/executors/)
## How it works
1. Create a new SSH key pair locally with [ssh-keygen](http://linux.die.net/man/1/ssh-keygen)
1. Create a new SSH key pair locally with [`ssh-keygen`](http://linux.die.net/man/1/ssh-keygen)
1. Add the private key as a [variable](../variables/README.md) to
your project
1. Run the [ssh-agent](http://linux.die.net/man/1/ssh-agent) during job to load
1. Run the [`ssh-agent`](http://linux.die.net/man/1/ssh-agent) during job to load
the private key.
1. Copy the public key to the servers you want to have access to (usually in
`~/.ssh/authorized_keys`) or add it as a [deploy key](../../ssh/README.md#deploy-keys)
......
......@@ -108,7 +108,7 @@ future GitLab releases.**
| `CI_RUNNER_VERSION` | all | 10.6 | GitLab Runner version that is executing the current job |
| `CI_RUNNER_SHORT_TOKEN` | all | 12.3 | First eight characters of GitLab Runner's token used to authenticate new job requests. Used as Runner's unique ID |
| `CI_SERVER` | all | all | Mark that job is executed in CI environment |
| `CI_SERVER_HOST` | 12.1 | all | Host component of the GitLab instance URL, without protocol and port (like gitlab.example.com) |
| `CI_SERVER_HOST` | 12.1 | all | Host component of the GitLab instance URL, without protocol and port (like `gitlab.example.com`) |
| `CI_SERVER_NAME` | all | all | The name of CI server that is used to coordinate jobs |
| `CI_SERVER_REVISION` | all | all | GitLab revision that is used to schedule jobs |
| `CI_SERVER_VERSION` | all | all | GitLab version that is used to schedule jobs |
......
......@@ -56,7 +56,7 @@ Jobs are picked up by [Runners](../runners/README.md) and executed within the
environment of the Runner. What is important, is that each job is run
independently from each other.
### Validate the .gitlab-ci.yml
### Validate the `.gitlab-ci.yml`
Each instance of GitLab CI has an embedded debug tool called Lint, which validates the
content of your `.gitlab-ci.yml` files. You can find the Lint under the page `ci/lint` of your
......@@ -187,7 +187,7 @@ Used to specify [a Docker image](../docker/using_docker_images.md#what-is-an-ima
For:
- Simple definition examples, see [Define `image` and `services` from .gitlab-ci.yml](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
- Simple definition examples, see [Define `image` and `services` from `.gitlab-ci.yml`](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
- Detailed usage information, refer to [Docker integration](../docker/README.md) documentation.
#### `image:name`
......@@ -208,7 +208,7 @@ Used to specify a [service Docker image](../docker/using_docker_images.md#what-i
For:
- Simple definition examples, see [Define `image` and `services` from .gitlab-ci.yml](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
- Simple definition examples, see [Define `image` and `services` from `.gitlab-ci.yml`](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
- Detailed usage information, refer to [Docker integration](../docker/README.md) documentation.
- For example services, see [GitLab CI Services](../services/README.md).
......@@ -379,8 +379,8 @@ In addition, `only` and `except` allow the use of special keywords:
| **Value** | **Description** |
| --------- | ---------------- |
| `branches` | When a git reference of a pipeline is a branch. |
| `tags` | When a git reference of a pipeline is a tag. |
| `branches` | When a Git reference of a pipeline is a branch. |
| `tags` | When a Git reference of a pipeline is a tag. |
| `api` | When pipeline has been triggered by a second pipelines API (not triggers API). |
| `external` | When using CI services other than GitLab. |
| `pipelines` | For multi-project triggers, created using the API with `CI_JOB_TOKEN`. |
......@@ -530,15 +530,15 @@ single conjoined expression. That is:
With `only`, individual keys are logically joined by an AND:
> (any of refs) AND (any of variables) AND (any of changes) AND (if kubernetes is active)
> (any of refs) AND (any of variables) AND (any of changes) AND (if Kubernetes is active)
`except` is implemented as a negation of this complete expression:
> NOT((any of refs) AND (any of variables) AND (any of changes) AND (if kubernetes is active))
> NOT((any of refs) AND (any of variables) AND (any of changes) AND (if Kubernetes is active))
This, more intuitively, means the keys join by an OR. A functionally equivalent expression:
> (any of refs) OR (any of variables) OR (any of changes) OR (if kubernetes is active)
> (any of refs) OR (any of variables) OR (any of changes) OR (if Kubernetes is active)
#### `only:refs`/`except:refs`
......@@ -612,7 +612,7 @@ Learn more about [variables expressions](../variables/README.md#environment-vari
> `changes` policy [introduced][ce-19232] in GitLab 11.4.
Using the `changes` keyword with `only` or `except` makes it possible to define if
a job should be created based on files modified by a git push event.
a job should be created based on files modified by a Git push event.
For example:
......@@ -1047,7 +1047,7 @@ You can stop the active timer of a delayed job by clicking the **Unschedule** bu
This job will never be executed in the future unless you execute the job manually.
You can start a delayed job immediately by clicking the **Play** button.
GitLab runner will pick your job soon and start the job.
GitLab Runner will pick your job soon and start the job.
### `environment`
......@@ -1894,12 +1894,12 @@ This example creates three paths of execution:
- 50 if the `ci_dag_limit_needs` feature flag is disabled.
- It is impossible for now to have `needs: []` (empty needs),
the job always needs to depend on something, unless this is the job
in the first stage (see [gitlab-foss#65504](https://gitlab.com/gitlab-org/gitlab-foss/issues/65504)).
in the first stage (see [issue #65504](https://gitlab.com/gitlab-org/gitlab-foss/issues/65504)).
- If `needs:` refers to a job that is marked as `parallel:`.
the current job will depend on all parallel jobs created.
- `needs:` is similar to `dependencies:` in that it needs to use jobs from
prior stages, meaning it is impossible to create circular
dependencies or depend on jobs in the current stage (see [gitlab-foss#65505](https://gitlab.com/gitlab-org/gitlab-foss/issues/65505)).
dependencies or depend on jobs in the current stage (see [issue #65505](https://gitlab.com/gitlab-org/gitlab-foss/issues/65505)).
- Related to the above, stages must be explicitly defined for all jobs
that have the keyword `needs:` or are referred to by one.
......@@ -2831,7 +2831,7 @@ The `GIT_CLEAN_FLAGS` variable is used to control the default behavior of
`git clean` after checking out the sources. You can set it globally or per-job in the
[`variables`](#variables) section.
`GIT_CLEAN_FLAGS` accepts all possible options of the [git clean](https://git-scm.com/docs/git-clean)
`GIT_CLEAN_FLAGS` accepts all possible options of the [`git clean`](https://git-scm.com/docs/git-clean)
command.
`git clean` is disabled if `GIT_CHECKOUT: "false"` is specified.
......@@ -2946,7 +2946,7 @@ default:
## Custom build directories
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1267) in Gitlab Runner 11.10
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1267) in GitLab Runner 11.10
NOTE: **Note:**
This can only be used when `custom_build_dir` is enabled in the [Runner's
......
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