diff options
74 files changed, 173 insertions, 141 deletions
diff --git a/app/assets/javascripts/registry/explorer/components/quickstart_dropdown.vue b/app/assets/javascripts/registry/explorer/components/quickstart_dropdown.vue index 99361b6e08d..96455496239 100644 --- a/app/assets/javascripts/registry/explorer/components/quickstart_dropdown.vue +++ b/app/assets/javascripts/registry/explorer/components/quickstart_dropdown.vue @@ -1,6 +1,7 @@ <script> import { GlDropdown, GlFormGroup, GlFormInputGroup } from '@gitlab/ui'; import { mapGetters } from 'vuex'; +import Tracking from '~/tracking'; import ClipboardButton from '~/vue_shared/components/clipboard_button.vue'; import { QUICK_START, @@ -19,6 +20,7 @@ export default { GlFormInputGroup, ClipboardButton, }, + mixins: [Tracking.mixin({ label: 'quickstart_dropdown' })], i18n: { dropdownTitle: QUICK_START, loginCommandLabel: LOGIN_COMMAND_LABEL, @@ -34,7 +36,13 @@ export default { }; </script> <template> - <gl-dropdown :text="$options.i18n.dropdownTitle" variant="primary" size="sm" right> + <gl-dropdown + :text="$options.i18n.dropdownTitle" + variant="primary" + size="sm" + right + @shown="track('click_dropdown')" + > <!-- This li is used as a container since gl-dropdown produces a root ul, this mimics the functionality exposed by b-dropdown-form --> <li role="presentation" class="px-2 py-1 dropdown-menu-large"> <form> @@ -49,6 +57,7 @@ export default { class="border" :text="dockerLoginCommand" :title="$options.i18n.copyLoginTitle" + @click.native="track('click_copy_login')" /> </template> </gl-form-input-group> @@ -65,6 +74,7 @@ export default { class="border" :text="dockerBuildCommand" :title="$options.i18n.copyBuildTitle" + @click.native="track('click_copy_build')" /> </template> </gl-form-input-group> @@ -82,6 +92,7 @@ export default { class="border" :text="dockerPushCommand" :title="$options.i18n.copyPushTitle" + @click.native="track('click_copy_push')" /> </template> </gl-form-input-group> diff --git a/changelogs/unreleased/212325-track-the-adoption-and-usage-of-the-quick-setup-button-in-the-cont.yml b/changelogs/unreleased/212325-track-the-adoption-and-usage-of-the-quick-setup-button-in-the-cont.yml new file mode 100644 index 00000000000..bfc35323488 --- /dev/null +++ b/changelogs/unreleased/212325-track-the-adoption-and-usage-of-the-quick-setup-button-in-the-cont.yml @@ -0,0 +1,5 @@ +--- +title: Add event tracking to Container regstry quickstart +merge_request: 27990 +author: +type: changed diff --git a/doc/.vale/gitlab/Substitutions.yml b/doc/.vale/gitlab/Substitutions.yml index 1d4f8faf03f..dd14bdd9b96 100644 --- a/doc/.vale/gitlab/Substitutions.yml +++ b/doc/.vale/gitlab/Substitutions.yml @@ -9,6 +9,9 @@ level: error ignorecase: true swap: GitLabber: GitLab team member + param: parameter + params: parameters + postgres: PostgreSQL self hosted: self-managed self-hosted: self-managed - postgres: PostgreSQL + diff --git a/doc/administration/geo/replication/external_database.md b/doc/administration/geo/replication/external_database.md index ca6acfc01c8..f0fff3c6712 100644 --- a/doc/administration/geo/replication/external_database.md +++ b/doc/administration/geo/replication/external_database.md @@ -151,7 +151,7 @@ the tracking database on port 5432. sudo -i ``` -1. Edit `/etc/gitlab/gitlab.rb` with the connection params and credentials for +1. Edit `/etc/gitlab/gitlab.rb` with the connection parameters and credentials for the machine with the PostgreSQL instance: ```ruby @@ -177,7 +177,7 @@ the tracking database on port 5432. connection and credentials: Save the script below in a file, ex. `/tmp/geo_fdw.sh` and modify the connection - params to match your environment. Execute it to set up the FDW connection. + parameters to match your environment. Execute it to set up the FDW connection. ```shell #!/bin/bash diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md index 39e998800bb..e99c10afaf9 100644 --- a/doc/administration/high_availability/nfs.md +++ b/doc/administration/high_availability/nfs.md @@ -224,7 +224,7 @@ following are the 4 locations need to be shared: | `/var/opt/gitlab/git-data` | Git repository data. This will account for a large portion of your data | `git_data_dirs({"default" => { "path" => "/var/opt/gitlab/git-data"} })` | `/var/opt/gitlab/gitlab-rails/uploads` | User uploaded attachments | `gitlab_rails['uploads_directory'] = '/var/opt/gitlab/gitlab-rails/uploads'` | `/var/opt/gitlab/gitlab-rails/shared` | Build artifacts, GitLab Pages, LFS objects, temp files, etc. If you're using LFS this may also account for a large portion of your data | `gitlab_rails['shared_path'] = '/var/opt/gitlab/gitlab-rails/shared'` -| `/var/opt/gitlab/gitlab-ci/builds` | GitLab CI build traces | `gitlab_ci['builds_directory'] = '/var/opt/gitlab/gitlab-ci/builds'` +| `/var/opt/gitlab/gitlab-ci/builds` | GitLab CI/CD build traces | `gitlab_ci['builds_directory'] = '/var/opt/gitlab/gitlab-ci/builds'` Other GitLab directories should not be shared between nodes. They contain node-specific files and GitLab code that does not need to be shared. To ship diff --git a/doc/api/README.md b/doc/api/README.md index 0a8820747b7..319a697b082 100644 --- a/doc/api/README.md +++ b/doc/api/README.md @@ -82,7 +82,7 @@ There are four ways to authenticate with the GitLab API: 1. [OAuth2 tokens](#oauth2-tokens) 1. [Personal access tokens](#personal-access-tokens) 1. [Session cookie](#session-cookie) -1. [GitLab CI job token](#gitlab-ci-job-token) **(Specific endpoints only)** +1. [GitLab CI/CD job token](#gitlab-ci-job-token) **(Specific endpoints only)** For admins who want to authenticate with the API as a specific user, or who want to build applications or scripts that do so, two options are available: @@ -154,7 +154,7 @@ for example, without needing to explicitly pass an access token. ### GitLab CI job token -With a few API endpoints you can use a [GitLab CI job token](../user/project/new_ci_build_permissions_model.md#job-token) +With a few API endpoints you can use a [GitLab CI/CD job token](../user/project/new_ci_build_permissions_model.md#job-token) to authenticate with the API: - [Get job artifacts](jobs.md#get-job-artifacts) diff --git a/doc/api/api_resources.md b/doc/api/api_resources.md index 0ce4efa7d9f..fea30a2721a 100644 --- a/doc/api/api_resources.md +++ b/doc/api/api_resources.md @@ -150,5 +150,5 @@ Endpoints are available for: - [Dockerfile templates](templates/dockerfiles.md). - [`.gitignore` templates](templates/gitignores.md). -- [GitLab CI YAML templates](templates/gitlab_ci_ymls.md). +- [GitLab CI/CD YAML templates](templates/gitlab_ci_ymls.md). - [Open source license templates](templates/licenses.md). diff --git a/doc/api/container_registry.md b/doc/api/container_registry.md index eb46bcfc457..a41a71808ce 100644 --- a/doc/api/container_registry.md +++ b/doc/api/container_registry.md @@ -17,7 +17,7 @@ GET /projects/:id/registry/repositories | Attribute | Type | Required | Description | | --------- | ---- | -------- | ----------- | | `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) accessible by the authenticated user. | -| `tags` | boolean | no | If the param is included as true, each repository will include an array of `"tags"` in the response. | +| `tags` | boolean | no | If the parameter is included as true, each repository will include an array of `"tags"` in the response. | ```shell curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/registry/repositories" @@ -57,7 +57,7 @@ GET /groups/:id/registry/repositories | Attribute | Type | Required | Description | | --------- | ---- | -------- | ----------- | | `id` | integer/string | yes | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) accessible by the authenticated user. | -| `tags` | boolean | no | If the param is included as true, each repository will include an array of `"tags"` in the response. | +| `tags` | boolean | no | If the parameter is included as true, each repository will include an array of `"tags"` in the response. | ```shell curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups/2/registry/repositories?tags=1" diff --git a/doc/api/group_labels.md b/doc/api/group_labels.md index 37ab2fe48f1..c3b86233836 100644 --- a/doc/api/group_labels.md +++ b/doc/api/group_labels.md @@ -164,7 +164,7 @@ Example response: } ``` -NOTE: **Note:** An older endpoint `PUT /groups/:id/labels` with `name` in the params is still available, but deprecated. +NOTE: **Note:** An older endpoint `PUT /groups/:id/labels` with `name` in the parameters is still available, but deprecated. ## Delete a group label @@ -183,7 +183,7 @@ DELETE /groups/:id/labels/:label_id curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/5/labels/bug ``` -NOTE: **Note:** An older endpoint `DELETE /groups/:id/labels` with `name` in the params is still available, but deprecated. +NOTE: **Note:** An older endpoint `DELETE /groups/:id/labels` with `name` in the parameters is still available, but deprecated. ## Subscribe to a group label diff --git a/doc/api/issues.md b/doc/api/issues.md index d1404efd265..82aa297c12a 100644 --- a/doc/api/issues.md +++ b/doc/api/issues.md @@ -53,7 +53,7 @@ GET /issues?confidential=true | `author_id` | integer | no | Return issues created by the given user `id`. Mutually exclusive with `author_username`. Combine with `scope=all` or `scope=assigned_to_me`. _([Introduced][ce-13004] in GitLab 9.5)_ | | `author_username` | string | no | Return issues created by the given `username`. Similar to `author_id` and mutually exclusive with `author_id`. | | `assignee_id` | integer | no | Return issues assigned to the given user `id`. Mutually exclusive with `assignee_username`. `None` returns unassigned issues. `Any` returns issues with an assignee. _([Introduced][ce-13004] in GitLab 9.5)_ | -| `assignee_username` | string array | no | Return issues assigned to the given `username`. Similar to `assignee_id` and mutually exclusive with `assignee_id`. In CE version `assignee_username` array should only contain a single value or an invalid param error will be returned otherwise. | +| `assignee_username` | string array | no | Return issues assigned to the given `username`. Similar to `assignee_id` and mutually exclusive with `assignee_id`. In CE version `assignee_username` array should only contain a single value or an invalid parameter error will be returned otherwise. | | `my_reaction_emoji` | string | no | Return issues reacted by the authenticated user by the given `emoji`. `None` returns issues not given a reaction. `Any` returns issues given at least one reaction. _([Introduced][ce-14016] in GitLab 10.0)_ | | `weight` **(STARTER)** | integer | no | Return issues with the specified `weight`. `None` returns issues with no weight assigned. `Any` returns issues with a weight assigned. | | `iids[]` | integer array | no | Return only the issues having the given `iid` | @@ -210,7 +210,7 @@ GET /groups/:id/issues?confidential=true | `author_id` | integer | no | Return issues created by the given user `id`. Mutually exclusive with `author_username`. Combine with `scope=all` or `scope=assigned_to_me`. _([Introduced][ce-13004] in GitLab 9.5)_ | | `author_username` | string | no | Return issues created by the given `username`. Similar to `author_id` and mutually exclusive with `author_id`. | | `assignee_id` | integer | no | Return issues assigned to the given user `id`. Mutually exclusive with `assignee_username`. `None` returns unassigned issues. `Any` returns issues with an assignee. _([Introduced][ce-13004] in GitLab 9.5)_ | -| `assignee_username` | string array | no | Return issues assigned to the given `username`. Similar to `assignee_id` and mutually exclusive with `assignee_id`. In CE version `assignee_username` array should only contain a single value or an invalid param error will be returned otherwise. | +| `assignee_username` | string array | no | Return issues assigned to the given `username`. Similar to `assignee_id` and mutually exclusive with `assignee_id`. In CE version `assignee_username` array should only contain a single value or an invalid parameter error will be returned otherwise. | | `my_reaction_emoji` | string | no | Return issues reacted by the authenticated user by the given `emoji`. `None` returns issues not given a reaction. `Any` returns issues given at least one reaction. _([Introduced][ce-14016] in GitLab 10.0)_ | | `weight` **(STARTER)** | integer | no | Return issues with the specified `weight`. `None` returns issues with no weight assigned. `Any` returns issues with a weight assigned. | | `order_by` | string | no | Return issues ordered by `created_at`, `updated_at`, `priority`, `due_date`, `relative_position`, `label_priority`, `milestone_due`, `popularity`, `weight` fields. Default is `created_at` | @@ -365,7 +365,7 @@ GET /projects/:id/issues?confidential=true | `author_id` | integer | no | Return issues created by the given user `id`. Mutually exclusive with `author_username`. Combine with `scope=all` or `scope=assigned_to_me`. _([Introduced][ce-13004] in GitLab 9.5)_ | | `author_username` | string | no | Return issues created by the given `username`. Similar to `author_id` and mutually exclusive with `author_id`. | | `assignee_id` | integer | no | Return issues assigned to the given user `id`. Mutually exclusive with `assignee_username`. `None` returns unassigned issues. `Any` returns issues with an assignee. _([Introduced][ce-13004] in GitLab 9.5)_ | -| `assignee_username` | string array | no | Return issues assigned to the given `username`. Similar to `assignee_id` and mutually exclusive with `assignee_id`. In CE version `assignee_username` array should only contain a single value or an invalid param error will be returned otherwise. | +| `assignee_username` | string array | no | Return issues assigned to the given `username`. Similar to `assignee_id` and mutually exclusive with `assignee_id`. In CE version `assignee_username` array should only contain a single value or an invalid parameter error will be returned otherwise. | | `my_reaction_emoji` | string | no | Return issues reacted by the authenticated user by the given `emoji`. `None` returns issues not given a reaction. `Any` returns issues given at least one reaction. _([Introduced][ce-14016] in GitLab 10.0)_ | | `weight` **(STARTER)** | integer | no | Return issues with the specified `weight`. `None` returns issues with no weight assigned. `Any` returns issues with a weight assigned. | | `order_by` | string | no | Return issues ordered by `created_at`, `updated_at`, `priority`, `due_date`, `relative_position`, `label_priority`, `milestone_due`, `popularity`, `weight` fields. Default is `created_at` | @@ -1190,8 +1190,8 @@ Example response: "id": 112, "project": { "id": 5, - "name": "Gitlab Ci", - "name_with_namespace": "Gitlab Org / Gitlab Ci", + "name": "GitLab CI/CD", + "name_with_namespace": "GitLab Org / GitLab CI/CD", "path": "gitlab-ci", "path_with_namespace": "gitlab-org/gitlab-ci" }, diff --git a/doc/api/issues_statistics.md b/doc/api/issues_statistics.md index 511078f3028..699eda174d2 100644 --- a/doc/api/issues_statistics.md +++ b/doc/api/issues_statistics.md @@ -34,7 +34,7 @@ GET /issues_statistics?confidential=true | `author_id` | integer | no | Return issues created by the given user `id`. Mutually exclusive with `author_username`. Combine with `scope=all` or `scope=assigned_to_me`. | | `author_username` | string | no | Return issues created by the given `username`. Similar to `author_id` and mutually exclusive with `author_id`. | | `assignee_id` | integer | no | Return issues assigned to the given user `id`. Mutually exclusive with `assignee_username`. `None` returns unassigned issues. `Any` returns issues with an assignee. | -| `assignee_username` | string array | no | Return issues assigned to the given `username`. Similar to `assignee_id` and mutually exclusive with `assignee_id`. In CE version `assignee_username` array should only contain a single value or an invalid param error will be returned otherwise. | +| `assignee_username` | string array | no | Return issues assigned to the given `username`. Similar to `assignee_id` and mutually exclusive with `assignee_id`. In CE version `assignee_username` array should only contain a single value or an invalid parameter error will be returned otherwise. | | `my_reaction_emoji` | string | no | Return issues reacted by the authenticated user by the given `emoji`. `None` returns issues not given a reaction. `Any` returns issues given at least one reaction. | | `iids[]` | integer array | no | Return only the issues having the given `iid` | | `search` | string | no | Search issues against their `title` and `description` | @@ -92,7 +92,7 @@ GET /groups/:id/issues_statistics?confidential=true | `author_id` | integer | no | Return issues created by the given user `id`. Mutually exclusive with `author_username`. Combine with `scope=all` or `scope=assigned_to_me`. | | `author_username` | string | no | Return issues created by the given `username`. Similar to `author_id` and mutually exclusive with `author_id`. | | `assignee_id` | integer | no | Return issues assigned to the given user `id`. Mutually exclusive with `assignee_username`. `None` returns unassigned issues. `Any` returns issues with an assignee. | -| `assignee_username` | string array | no | Return issues assigned to the given `username`. Similar to `assignee_id` and mutually exclusive with `assignee_id`. In CE version `assignee_username` array should only contain a single value or an invalid param error will be returned otherwise. | +| `assignee_username` | string array | no | Return issues assigned to the given `username`. Similar to `assignee_id` and mutually exclusive with `assignee_id`. In CE version `assignee_username` array should only contain a single value or an invalid parameter error will be returned otherwise. | | `my_reaction_emoji` | string | no | Return issues reacted by the authenticated user by the given `emoji`. `None` returns issues not given a reaction. `Any` returns issues given at least one reaction. | | `search` | string | no | Search group issues against their `title` and `description` | | `created_after` | datetime | no | Return issues created on or after the given time | @@ -148,7 +148,7 @@ GET /projects/:id/issues_statistics?confidential=true | `author_id` | integer | no | Return issues created by the given user `id`. Mutually exclusive with `author_username`. Combine with `scope=all` or `scope=assigned_to_me`. | | `author_username` | string | no | Return issues created by the given `username`. Similar to `author_id` and mutually exclusive with `author_id`. | | `assignee_id` | integer | no | Return issues assigned to the given user `id`. Mutually exclusive with `assignee_username`. `None` returns unassigned issues. `Any` returns issues with an assignee. | -| `assignee_username` | string array | no | Return issues assigned to the given `username`. Similar to `assignee_id` and mutually exclusive with `assignee_id`. In CE version `assignee_username` array should only contain a single value or an invalid param error will be returned otherwise. | +| `assignee_username` | string array | no | Return issues assigned to the given `username`. Similar to `assignee_id` and mutually exclusive with `assignee_id`. In CE version `assignee_username` array should only contain a single value or an invalid parameter error will be returned otherwise. | | `my_reaction_emoji` | string | no | Return issues reacted by the authenticated user by the given `emoji`. `None` returns issues not given a reaction. `Any` returns issues given at least one reaction. | | `search` | string | no | Search project issues against their `title` and `description` | | `created_after` | datetime | no | Return issues created on or after the given time | diff --git a/doc/api/labels.md b/doc/api/labels.md index 54af6c093b9..e3f367daaca 100644 --- a/doc/api/labels.md +++ b/doc/api/labels.md @@ -191,7 +191,7 @@ DELETE /projects/:id/labels/:label_id curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/labels/bug" ``` -NOTE: **Note:** An older endpoint `DELETE /projects/:id/labels` with `name` in the params is still available, but deprecated. +NOTE: **Note:** An older endpoint `DELETE /projects/:id/labels` with `name` in the parameters is still available, but deprecated. ## Edit an existing label @@ -234,7 +234,7 @@ Example response: } ``` -NOTE: **Note:** An older endpoint `PUT /projects/:id/labels` with `name` or `label_id` in the params is still available, but deprecated. +NOTE: **Note:** An older endpoint `PUT /projects/:id/labels` with `name` or `label_id` in the parameters is still available, but deprecated. ## Promote a project label to a group label @@ -271,7 +271,7 @@ Example response: } ``` -NOTE: **Note:** An older endpoint `PUT /projects/:id/labels/promote` with `name` in the params is still available, but deprecated. +NOTE: **Note:** An older endpoint `PUT /projects/:id/labels/promote` with `name` in the parameters is still available, but deprecated. ## Subscribe to a label diff --git a/doc/api/merge_request_approvals.md b/doc/api/merge_request_approvals.md index 004c10fa70a..8fee23a74e8 100644 --- a/doc/api/merge_request_approvals.md +++ b/doc/api/merge_request_approvals.md @@ -278,7 +278,7 @@ You can update project approval rules using the following endpoint: PUT /projects/:id/approval_rules/:approval_rule_id ``` -**Important:** Approvers and groups not in the `users`/`groups` param will be **removed** +**Important:** Approvers and groups not in the `users`/`groups` parameters will be **removed** **Parameters:** @@ -851,7 +851,7 @@ You can update merge request approval rules using the following endpoint: PUT /projects/:id/merge_requests/:merge_request_iid/approval_rules/:approval_rule_id ``` -**Important:** Approvers and groups not in the `users`/`groups` param will be **removed** +**Important:** Approvers and groups not in the `users`/`groups` parameters will be **removed** **Important:** Updating a `report_approver` or `code_owner` rule is not allowed. These are system generated rules. diff --git a/doc/api/merge_requests.md b/doc/api/merge_requests.md index 0b90b277d6f..881fc27feec 100644 --- a/doc/api/merge_requests.md +++ b/doc/api/merge_requests.md @@ -2088,8 +2088,8 @@ Example response: "id": 113, "project": { "id": 3, - "name": "Gitlab Ci", - "name_with_namespace": "Gitlab Org / Gitlab Ci", + "name": "GitLab CI/CD", + "name_with_namespace": "GitLab Org / GitLab CI/CD", "path": "gitlab-ci", "path_with_namespace": "gitlab-org/gitlab-ci" }, diff --git a/doc/api/packages.md b/doc/api/packages.md index a29e1f99fd3..ebab03662e0 100644 --- a/doc/api/packages.md +++ b/doc/api/packages.md @@ -64,7 +64,7 @@ GET /groups/:id/packages | Attribute | Type | Required | Description | | --------- | ---- | -------- | ----------- | | `id` | integer/string | yes | ID or [URL-encoded path of the group](README.md#namespaced-path-encoding). | -| `exclude_subgroups` | boolean | false | If the param is included as true, packages from projects from subgroups are not listed. Default is `false`. | +| `exclude_subgroups` | boolean | false | If the parameter is included as true, packages from projects from subgroups are not listed. Default is `false`. | | `order_by`| string | no | The field to use as order. One of `created_at` (default), `name`, `version`, `type`, or `project_path`. | | `sort` | string | no | The direction of the order, either `asc` (default) for ascending order or `desc` for descending order. | | `package_type` | string | no | Filter the returned packages by type. One of `conan`, `maven`, `npm` or `nuget`. (_Introduced in GitLab 12.9_) | diff --git a/doc/api/project_import_export.md b/doc/api/project_import_export.md index 476abc18835..32074f9bced 100644 --- a/doc/api/project_import_export.md +++ b/doc/api/project_import_export.md @@ -131,7 +131,7 @@ POST /projects/import | `overwrite` | boolean | no | If there is a project with the same path the import will overwrite it. Default to false | | `override_params` | Hash | no | Supports all fields defined in the [Project API](projects.md) | -The override params passed will take precedence over all values defined inside the export file. +The override parameters passed will take precedence over all values defined inside the export file. To upload a file from your file system, use the `--form` argument. This causes cURL to post data using the header `Content-Type: multipart/form-data`. diff --git a/doc/api/project_templates.md b/doc/api/project_templates.md index 4062df24525..0c1b483600f 100644 --- a/doc/api/project_templates.md +++ b/doc/api/project_templates.md @@ -4,7 +4,7 @@ This API is a project-specific version of these endpoints: - [Dockerfile templates](templates/dockerfiles.md) - [Gitignore templates](templates/gitignores.md) -- [GitLab CI Config templates](templates/gitlab_ci_ymls.md) +- [GitLab CI/CD Config templates](templates/gitlab_ci_ymls.md) - [Open source license templates](templates/licenses.md) It deprecates these endpoints, which will be removed for API version 5. diff --git a/doc/api/services.md b/doc/api/services.md index 8c70033d71d..519448709e9 100644 --- a/doc/api/services.md +++ b/doc/api/services.md @@ -872,7 +872,7 @@ GET /projects/:id/services/packagist ## Pipeline-Emails -Get emails for GitLab CI pipelines. +Get emails for GitLab CI/CD pipelines. ### Create/Edit Pipeline-Emails service diff --git a/doc/api/templates/gitlab_ci_ymls.md b/doc/api/templates/gitlab_ci_ymls.md index c88aee4d9a7..816061c6235 100644 --- a/doc/api/templates/gitlab_ci_ymls.md +++ b/doc/api/templates/gitlab_ci_ymls.md @@ -4,13 +4,13 @@ type: reference # GitLab CI YMLs API -In GitLab, there is an API endpoint available to work with CI YMLs. For more +In GitLab, there is an API endpoint available to work with GitLab CI/CD YMLs. For more information on CI/CD pipeline configuration in GitLab, see the [configuration reference documentation](../../ci/yaml/README.md). ## List GitLab CI YML templates -Get all GitLab CI YML templates. +Get all GitLab CI/CD YML templates. ```plaintext GET /templates/gitlab_ci_ymls @@ -111,7 +111,7 @@ Example response: ## Single GitLab CI YML template -Get a single GitLab CI YML template. +Get a single GitLab CI/CD YML template. ```plaintext GET /templates/gitlab_ci_ymls/:key @@ -119,7 +119,7 @@ GET /templates/gitlab_ci_ymls/:key | Attribute | Type | Required | Description | | ---------- | ------ | -------- | ------------------------------------- | -| `key` | string | yes | The key of the GitLab CI YML template | +| `key` | string | yes | The key of the GitLab CI/CD YML template | Example request: diff --git a/doc/api/v3_to_v4.md b/doc/api/v3_to_v4.md index 758e749e034..07fa7d6d420 100644 --- a/doc/api/v3_to_v4.md +++ b/doc/api/v3_to_v4.md @@ -45,7 +45,7 @@ Below are the changes made between V3 and V4. - Moved `PUT /users/:id/(block|unblock)` to `POST /users/:id/(block|unblock)` [!9371](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/9371) - Make subscription API more RESTful. Use `POST /projects/:id/:subscribable_type/:subscribable_id/subscribe` to subscribe and `POST /projects/:id/:subscribable_type/:subscribable_id/unsubscribe` to unsubscribe from a resource. [!9325](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/9325) - Labels filter on `GET /projects/:id/issues` and `GET /issues` now matches only issues containing all labels (i.e.: Logical AND, not OR) [!8849](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8849) -- Renamed param `branch_name` to `branch` on the following endpoints [!8936](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8936) +- Renamed parameter `branch_name` to `branch` on the following endpoints [!8936](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8936) - `POST /projects/:id/repository/branches` - `POST /projects/:id/repository/commits` - `POST/PUT/DELETE :id/repository/files` @@ -56,7 +56,7 @@ Below are the changes made between V3 and V4. - `POST /projects/user/:user_id` - `PUT /projects/:id` - Renamed `branch_name` to `branch` on `DELETE /projects/:id/repository/branches/:branch` response [!8936](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8936) -- Remove `public` param from create and edit actions of projects [!8736](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8736) +- Remove `public` parameter from create and edit actions of projects [!8736](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8736) - Remove `subscribed` field from responses returning list of issues or merge requests. Fetch individual issues or merge requests to obtain the value of `subscribed` diff --git a/doc/ci/README.md b/doc/ci/README.md index fe88b414702..f902400efc2 100644 --- a/doc/ci/README.md +++ b/doc/ci/README.md @@ -160,11 +160,10 @@ See also: ### Why GitLab CI/CD? -The following articles explain reasons to use GitLab CI/CD -for your CI/CD infrastructure: +Learn more about: -- [Why we chose GitLab CI for our CI/CD solution](https://about.gitlab.com/blog/2016/10/17/gitlab-ci-oohlala/) -- [Building our web-app on GitLab CI](https://about.gitlab.com/blog/2016/07/22/building-our-web-app-on-gitlab-ci/) +- [Why you might chose GitLab CI/CD](https://about.gitlab.com/blog/2016/10/17/gitlab-ci-oohlala/). +- [Reasons you might migrate from another platform](https://about.gitlab.com/blog/2016/07/22/building-our-web-app-on-gitlab-ci/). - [5 Teams that made the switch to GitLab CI/CD](https://about.gitlab.com/blog/2019/04/25/5-teams-that-made-the-switch-to-gitlab-ci-cd/) See also the [Why CI/CD?](https://docs.google.com/presentation/d/1OGgk2Tcxbpl7DJaIOzCX4Vqg3dlwfELC3u2jEeCBbDk) presentation. diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md index 4beec62b36b..f56e7a161ca 100644 --- a/doc/ci/docker/using_docker_images.md +++ b/doc/ci/docker/using_docker_images.md @@ -4,7 +4,7 @@ type: concepts, howto # Using Docker images -GitLab CI in conjunction with [GitLab Runner](../runners/README.md) can use +GitLab CI/CD in conjunction with [GitLab Runner](../runners/README.md) can use [Docker Engine](https://www.docker.com/) to test and build any application. Docker is an open-source project that allows you to use predefined images to @@ -12,7 +12,7 @@ run applications in independent "containers" that are run within a single Linux instance. [Docker Hub][hub] has a rich database of pre-built images that can be used to test and build your applications. -When used with GitLab CI, Docker runs each job in a separate and isolated +When used with GitLab CI/CD, Docker runs each job in a separate and isolated container using the predefined image that is set up in [`.gitlab-ci.yml`](../yaml/README.md). diff --git a/doc/ci/examples/README.md b/doc/ci/examples/README.md index d2333f7e468..64367727371 100644 --- a/doc/ci/examples/README.md +++ b/doc/ci/examples/README.md @@ -37,7 +37,7 @@ The following table lists examples with step-by-step tutorials that are containe | Python on Heroku | [Test and deploy a Python application with GitLab CI/CD](test-and-deploy-python-application-to-heroku.md). | | Ruby on Heroku | [Test and deploy a Ruby application with GitLab CI/CD](test-and-deploy-ruby-application-to-heroku.md). | | Scala on Heroku | [Test and deploy a Scala application to Heroku](test-scala-application.md). | -| Parallel testing Ruby & JS | [GitLab CI parallel jobs testing for Ruby & JavaScript projects](https://docs.knapsackpro.com/2019/how-to-run-parallel-jobs-for-rspec-tests-on-gitlab-ci-pipeline-and-speed-up-ruby-javascript-testing). | +| Parallel testing Ruby & JS | [GitLab CI/CD parallel jobs testing for Ruby & JavaScript projects](https://docs.knapsackpro.com/2019/how-to-run-parallel-jobs-for-rspec-tests-on-gitlab-ci-pipeline-and-speed-up-ruby-javascript-testing). | ### Contributing examples @@ -67,7 +67,7 @@ For examples of setting up GitLab CI/CD for cloud-based environments, see: See also the following video overviews: -- [Containers, Schedulers, and GitLab CI](https://www.youtube.com/watch?v=d-9awBxEbvQ). +- [Kubernetes, GitLab, and Cloud Native](https://www.youtube.com/watch?v=d-9awBxEbvQ). - [Deploying to IBM Cloud with GitLab CI/CD](https://www.youtube.com/watch?v=6ZF4vgKMd-g). ### Customer stories diff --git a/doc/ci/examples/deployment/README.md b/doc/ci/examples/deployment/README.md index 01dca801fbc..2ed1a99e0d9 100644 --- a/doc/ci/examples/deployment/README.md +++ b/doc/ci/examples/deployment/README.md @@ -6,7 +6,7 @@ type: tutorial [Dpl](https://github.com/travis-ci/dpl) (pronounced like the letters D-P-L) is a deploy tool made for continuous deployment that's developed and used by Travis CI, but can also be -used with GitLab CI. +used with GitLab CI/CD. Dpl can be used to deploy to any of the [supported providers](https://github.com/travis-ci/dpl#supported-providers). diff --git a/doc/ci/examples/deployment/composer-npm-deploy.md b/doc/ci/examples/deployment/composer-npm-deploy.md index ae0880adef2..c5f49fd6e59 100644 --- a/doc/ci/examples/deployment/composer-npm-deploy.md +++ b/doc/ci/examples/deployment/composer-npm-deploy.md @@ -100,7 +100,7 @@ Here's the breakdown: 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 -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). +What's the deal with the artifacts? We just tell GitLab CI/CD to keep the `build` directory (later on, you can download that as needed). ### Why we do it this way diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md index 4284038b283..c8f5d48c4ef 100644 --- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md +++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md @@ -608,7 +608,7 @@ If the SSH keys have added successfully, we can run Envoy. As mentioned before, GitLab supports [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-delivery) methods as well. The [environment](../../yaml/README.md#environment) keyword tells GitLab that this job deploys to the `production` environment. The `url` keyword is used to generate a link to our application on the GitLab Environments page. -The `only` keyword tells GitLab CI that the job should be executed only when the pipeline is building the `master` branch. +The `only` keyword tells GitLab CI/CD that the job should be executed only when the pipeline is building the `master` branch. Lastly, `when: manual` is used to turn the job from running automatically to a manual action. ```yaml @@ -679,6 +679,6 @@ As you see, the `.env` is pointing to the `/var/www/app/.env` file and also `sto ## Conclusion -We configured GitLab CI to perform automated tests and used the method of [Continuous Delivery](https://continuousdelivery.com/) to deploy to production a Laravel application with Envoy, directly from the codebase. +We configured GitLab CI/CD to perform automated tests and used the method of [Continuous Delivery](https://continuousdelivery.com/) to deploy to production a Laravel application with Envoy, directly from the codebase. Envoy also was a great match to help us deploy the application without writing our custom bash script and doing Linux magics. diff --git a/doc/ci/examples/test-scala-application.md b/doc/ci/examples/test-scala-application.md index ffdffcc88bd..92fb69286cf 100644 --- a/doc/ci/examples/test-scala-application.md +++ b/doc/ci/examples/test-scala-application.md @@ -4,7 +4,7 @@ type: tutorial # Test and deploy a Scala application to Heroku -This example demonstrates the integration of GitLab CI with Scala +This example demonstrates the integration of GitLab CI/CD with Scala applications using SBT. You can view or fork the [example project](https://gitlab.com/gitlab-examples/scala-sbt) and view the logs of its past [CI jobs](https://gitlab.com/gitlab-examples/scala-sbt/-/jobs?scope=finished). diff --git a/doc/ci/git_submodules.md b/doc/ci/git_submodules.md index cce33c7a6b4..381c0508dea 100644 --- a/doc/ci/git_submodules.md +++ b/doc/ci/git_submodules.md @@ -44,7 +44,7 @@ for all your local checkouts. The `.gitmodules` would look like: The above configuration will instruct Git to automatically deduce the URL that should be used when cloning sources. Whether you use HTTP(S) or SSH, Git will use that same channel and it will allow to make all your CI jobs use HTTP(S) -(because GitLab CI only uses HTTP(S) for cloning your sources), and all your local +(because GitLab CI/CD only uses HTTP(S) for cloning your sources), and all your local clones will continue using SSH. For all other submodules not located on the same GitLab server, use the full diff --git a/doc/ci/jenkins/index.md b/doc/ci/jenkins/index.md index 37d6921c0a5..9b72d0bfb5e 100644 --- a/doc/ci/jenkins/index.md +++ b/doc/ci/jenkins/index.md @@ -243,7 +243,7 @@ default: #### `stages` -GitLab CI also lets you define stages, but is a little bit more free-form to configure. The GitLab [`stages` keyword](../yaml/README.md#stages) +GitLab CI/CD also lets you define stages, but is a little bit more free-form to configure. The GitLab [`stages` keyword](../yaml/README.md#stages) is a top level setting that enumerates the list of stages, but you are not required to nest individual jobs underneath the `stages` section. Any job defined in the `.gitlab-ci.yml` can be made a part of any stage through use of the [`stage:` keyword](../yaml/README.md#stage). diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md index bab03f11aa8..7983dded814 100644 --- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md +++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md @@ -66,7 +66,7 @@ otherwise pipelines for merged results won't run and your merge requests will be > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12996) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3. -GitLab CI can detect the presence of redundant pipelines, +GitLab CI/CD can detect the presence of redundant pipelines, and will cancel them automatically in order to conserve CI resources. When a user merges a merge request immediately within an ongoing merge diff --git a/doc/ci/multi_project_pipelines.md b/doc/ci/multi_project_pipelines.md index 6a4dff635ad..09fb5e3a7b9 100644 --- a/doc/ci/multi_project_pipelines.md +++ b/doc/ci/multi_project_pipelines.md @@ -39,7 +39,7 @@ With Multi-Project Pipelines you can visualize the entire pipeline, including al > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/2121) in [GitLab Premium 9.3](https://about.gitlab.com/releases/2017/06/22/gitlab-9-3-released/#multi-project-pipeline-graphs). -When you configure GitLab CI for your project, you can visualize the stages of your +When you configure GitLab CI/CD for your project, you can visualize the stages of your [jobs](pipelines/index.md#configuring-pipelines) on a [pipeline graph](pipelines/index.md#visualizing-pipelines).  diff --git a/doc/ci/parent_child_pipelines.md b/doc/ci/parent_child_pipelines.md index 2ce69a04939..b39e0b6e540 100644 --- a/doc/ci/parent_child_pipelines.md +++ b/doc/ci/parent_child_pipelines.md @@ -33,7 +33,7 @@ set of concurrently running child pipelines, but within the same project: - Imports are done at the child pipeline level, reducing the likelihood of collisions. - 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/CD features: - Use [`only: changes`](yaml/README.md#onlychangesexceptchanges) to trigger pipelines only when certain files change. This is useful for monorepos, for example. diff --git a/doc/ci/pipelines/schedules.md b/doc/ci/pipelines/schedules.md index b9a2972dc89..0ca794c5411 100644 --- a/doc/ci/pipelines/schedules.md +++ b/doc/ci/pipelines/schedules.md @@ -46,7 +46,7 @@ is installed on. > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12328) in GitLab 9.4. You can pass any number of arbitrary variables and they will be available in -GitLab CI so that they can be used in your [`.gitlab-ci.yml` file](../../ci/yaml/README.md). +GitLab CI/CD so that they can be used in your [`.gitlab-ci.yml` file](../../ci/yaml/README.md).  diff --git a/doc/ci/quick_start/README.md b/doc/ci/quick_start/README.md index 0ea37e26224..8ef78f899c7 100644 --- a/doc/ci/quick_start/README.md +++ b/doc/ci/quick_start/README.md @@ -55,7 +55,7 @@ This guide assumes that you have: - A project in GitLab that you would like to use CI for. - Maintainer or owner access to the project -Let's break it down to pieces and work on solving the GitLab CI puzzle. +Let's break it down to pieces and work on solving the GitLab CI/CD puzzle. ## Creating a `.gitlab-ci.yml` file diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md index 7e1aae4709a..3b9e30e2b96 100644 --- a/doc/ci/runners/README.md +++ b/doc/ci/runners/README.md @@ -4,12 +4,12 @@ type: reference # Configuring GitLab Runners -In GitLab CI, Runners run the code defined in [`.gitlab-ci.yml`](../yaml/README.md). +In GitLab CI/CD, Runners run the code defined in [`.gitlab-ci.yml`](../yaml/README.md). They are isolated (virtual) machines that pick up jobs through the coordinator -API of GitLab CI. +API of GitLab CI/CD. A Runner can be specific to a certain project or serve any project -in GitLab CI. A Runner that serves all projects is called a shared Runner. +in GitLab CI/CD. A Runner that serves all projects is called a shared Runner. Ideally, the GitLab Runner should not be installed on the same machine as GitLab. Read the [requirements documentation](../../install/requirements.md#gitlab-runner) diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md index 00070594ded..98d3a08977c 100644 --- a/doc/ci/triggers/README.md +++ b/doc/ci/triggers/README.md @@ -192,7 +192,7 @@ https://gitlab.example.com/api/v4/projects/9/ref/master/trigger/pipeline?token=T ## Making use of trigger variables You can pass any number of arbitrary variables in the trigger API call and they -will be available in GitLab CI so that they can be used in your `.gitlab-ci.yml` +will be available in GitLab CI/CD so that they can be used in your `.gitlab-ci.yml` file. The parameter is of the form: ```plaintext diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md index 5a6d30a1079..af41d1ab958 100644 --- a/doc/ci/variables/README.md +++ b/doc/ci/variables/README.md @@ -317,7 +317,7 @@ export GITLAB_USER_ID="42" NOTE: **Note:** This feature requires GitLab Runner 0.5.0 or higher and GitLab 7.14 or higher. -GitLab CI allows you to add to `.gitlab-ci.yml` variables that are set in the +GitLab CI/CD allows you to add to `.gitlab-ci.yml` variables that are set in the build environment. The variables are hence saved in the repository, and they are meant to store non-sensitive project configuration. For example, `RAILS_ENV` or `DATABASE_URL`. diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md index c90d2e1aa5e..0fab965a0c0 100644 --- a/doc/ci/variables/predefined_variables.md +++ b/doc/ci/variables/predefined_variables.md @@ -56,7 +56,7 @@ future GitLab releases.** | `CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_SHA` | 12.3 | all | The HEAD SHA of the source branch of the pull request if [the pipelines are for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). Available only if `only: [external_pull_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the pull request is open. | | `CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_NAME` | 12.3 | all | The target branch name of the pull request if [the pipelines are for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). Available only if `only: [external_pull_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the pull request is open. | | `CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_SHA` | 12.3 | all | The HEAD SHA of the target branch of the pull request if [the pipelines are for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). Available only if `only: [external_pull_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the pull request is open. | -| `CI_JOB_ID` | 9.0 | all | The unique id of the current job that GitLab CI uses internally | +| `CI_JOB_ID` | 9.0 | all | The unique id of the current job that GitLab CI/CD uses internally | | `CI_JOB_IMAGE` | 12.9 | 12.9 | The name of the image running the CI job | | `CI_JOB_MANUAL` | 8.12 | all | The flag to indicate that job was manually started | | `CI_JOB_NAME` | 9.0 | 0.5 | The name of the job as defined in `.gitlab-ci.yml` | @@ -87,13 +87,13 @@ future GitLab releases.** | `CI_NODE_TOTAL` | 11.5 | all | Total number of instances of this job running in parallel. If the job is not parallelized, this variable is set to `1`. | | `CI_PAGES_DOMAIN` | 11.8 | all | The configured domain that hosts GitLab Pages. | | `CI_PAGES_URL` | 11.8 | all | URL to GitLab Pages-built pages. Always belongs to a subdomain of `CI_PAGES_DOMAIN`. | -| `CI_PIPELINE_ID` | 8.10 | all | The unique id of the current pipeline that GitLab CI uses internally | +| `CI_PIPELINE_ID` | 8.10 | all | The unique id of the current pipeline that GitLab CI/CD uses internally | | `CI_PIPELINE_IID` | 11.0 | all | The unique id of the current pipeline scoped to project | | `CI_PIPELINE_SOURCE` | 10.0 | all | Indicates how the pipeline was triggered. Possible options are: `push`, `web`, `trigger`, `schedule`, `api`, `pipeline`, `external`, `chat`, `merge_request_event`, and `external_pull_request_event`. For pipelines created before GitLab 9.5, this will show as `unknown` | | `CI_PIPELINE_TRIGGERED` | all | all | The flag to indicate that job was [triggered](../triggers/README.md) | | `CI_PIPELINE_URL` | 11.1 | 0.5 | Pipeline details URL | | `CI_PROJECT_DIR` | all | all | The full path where the repository is cloned and where the job is run. If the GitLab Runner `builds_dir` parameter is set, this variable is set relative to the value of `builds_dir`. For more information, see [Advanced configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) for GitLab Runner. | -| `CI_PROJECT_ID` | all | all | The unique id of the current project that GitLab CI uses internally | +| `CI_PROJECT_ID` | all | all | The unique id of the current project that GitLab CI/CD uses internally | | `CI_PROJECT_NAME` | 8.10 | 0.5 | The name of the directory for the project that is currently being built. For example, if the project URL is `gitlab.example.com/group-name/project-1`, the `CI_PROJECT_NAME` would be `project-1`. | | `CI_PROJECT_NAMESPACE` | 8.10 | 0.5 | The project namespace (username or groupname) that is currently being built | | `CI_PROJECT_PATH` | 8.10 | 0.5 | The namespace with project name | @@ -127,7 +127,7 @@ future GitLab releases.** | `CI_SERVER_VERSION_PATCH` | 11.4 | all | GitLab version patch component | | `CI_SHARED_ENVIRONMENT` | all | 10.1 | Marks that the job is executed in a shared environment (something that is persisted across CI invocations like `shell` or `ssh` executor). If the environment is shared, it is set to true, otherwise it is not defined at all. | | `GET_SOURCES_ATTEMPTS` | 8.15 | 1.9 | Number of attempts to fetch sources running a job | -| `GITLAB_CI` | all | all | Mark that job is executed in GitLab CI environment | +| `GITLAB_CI` | all | all | Mark that job is executed in GitLab CI/CD environment | | `GITLAB_FEATURES` | 10.6 | all | The comma separated list of licensed features available for your instance and plan | | `GITLAB_USER_EMAIL` | 8.12 | all | The email of the user who started the job | | `GITLAB_USER_ID` | 8.12 | all | The id of the user who started the job | diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 5fe0f70b519..0930185371a 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -18,7 +18,7 @@ This topic covers CI/CD pipeline configuration. For other CI/CD configuration in We have complete examples of configuring pipelines: -- For a quick introduction to GitLab CI, follow our [quick start guide](../quick_start/README.md). +- For a quick introduction to GitLab CI/CD, follow our [quick start guide](../quick_start/README.md). - For a collection of examples, see [GitLab CI/CD Examples](../examples/README.md). - To see a large `.gitlab-ci.yml` file used in an enterprise, see the [`.gitlab-ci.yml` file for `gitlab`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml). @@ -58,7 +58,7 @@ independently from each other. ### Validate the `.gitlab-ci.yml` -Each instance of GitLab CI has an embedded debug tool called Lint, which validates the +Each instance of GitLab CI/CD 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 project namespace. For example, `https://gitlab.example.com/gitlab-org/project-123/-/ci/lint`. @@ -312,7 +312,7 @@ 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). - Detailed usage information, refer to [Docker integration](../docker/README.md) documentation. -- For example services, see [GitLab CI Services](../services/README.md). +- For example services, see [GitLab CI/CD Services](../services/README.md). #### `services:name` @@ -3958,7 +3958,7 @@ lines where the job is defined: ``` you can instead start its name with a dot (`.`) and it will not be processed by -GitLab CI. In the following example, `.hidden_job` will be ignored: +GitLab CI/CD. In the following example, `.hidden_job` will be ignored: ```yaml .hidden_job: diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md index 9844dca6bb9..6a88e7b71e2 100644 --- a/doc/development/api_graphql_styleguide.md +++ b/doc/development/api_graphql_styleguide.md @@ -762,7 +762,7 @@ a hash with the input for the mutation. This will return a struct with a mutation query, and prepared variables. This struct can then be passed to the `post_graphql_mutation` helper, -that will post the request with the correct params, like a GraphQL +that will post the request with the correct parameters, like a GraphQL client would do. To access the response of a mutation, the `graphql_mutation_response` diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md index 8537c63a8b7..7c0146017b1 100644 --- a/doc/development/api_styleguide.md +++ b/doc/development/api_styleguide.md @@ -28,7 +28,7 @@ for a good example): - The GitLab version when the endpoint was added. If it is behind a feature flag, mention that instead: _This feature is gated by the :feature\_flag\_symbol feature flag._ - If the endpoint is deprecated, and if so, when will it be removed -- `params` for the method params. This acts as description, +- `params` for the method parameters. This acts as description, [validation, and coercion of the parameters] A good example is as follows: @@ -49,22 +49,22 @@ get do end ``` -## Declared params +## Declared parameters > Grape allows you to access only the parameters that have been declared by your -`params` block. It filters out the params that have been passed, but are not +`params` block. It filters out the parameters that have been passed, but are not allowed. – <https://github.com/ruby-grape/grape#declared> -### Exclude params from parent namespaces +### Exclude parameters from parent namespaces > By default `declared(params)`includes parameters that were defined in all parent namespaces. – <https://github.com/ruby-grape/grape#include-parent-namespaces> -In most cases you will want to exclude params from the parent namespaces: +In most cases you will want to exclude parameters from the parent namespaces: ```ruby declared(params, include_parent_namespaces: false) @@ -72,7 +72,7 @@ declared(params, include_parent_namespaces: false) ### When to use `declared(params)` -You should always use `declared(params)` when you pass the params hash as +You should always use `declared(params)` when you pass the parameters hash as arguments to a method call. For instance: diff --git a/doc/development/architecture.md b/doc/development/architecture.md index 061e910a6d0..d065660be74 100644 --- a/doc/development/architecture.md +++ b/doc/development/architecture.md @@ -150,7 +150,7 @@ Component statuses are linked to configuration documentation for each component. | [Node Exporter](#node-exporter) | Prometheus endpoint with system metrics | [✅][node-exporter-omnibus] | [N/A][node-exporter-charts] | [N/A][node-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE | | [Mattermost](#mattermost) | Open-source Slack alternative | [⚙][mattermost-omnibus] | [⤓][mattermost-charts] | [⤓][mattermost-charts] | [⤓](../user/project/integrations/mattermost.md) | ❌ | ❌ | CE & EE | | [MinIO](#minio) | Object storage service | [⤓][minio-omnibus] | [✅][minio-charts] | [✅][minio-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#storage-architecture) | ❌ | [⚙][minio-gdk] | CE & EE | -| [Runner](#gitlab-runner) | Executes GitLab CI jobs | [⤓][runner-omnibus] | [✅][runner-charts] | [⚙][runner-charts] | [✅](../user/gitlab_com/index.md#shared-runners) | [⚙][runner-source] | [⚙][runner-gdk] | CE & EE | +| [Runner](#gitlab-runner) | Executes GitLab CI/CD jobs | [⤓][runner-omnibus] | [✅][runner-charts] | [⚙][runner-charts] | [✅](../user/gitlab_com/index.md#shared-runners) | [⚙][runner-source] | [⚙][runner-gdk] | CE & EE | | [Database Migrations](#database-migrations) | Database migrations | [✅][database-migrations-omnibus] | [✅][database-migrations-charts] | [✅][database-migrations-charts] | ✅ | [⚙][database-migrations-source] | ✅ | CE & EE | | [Certificate Management](#certificate-management) | TLS Settings, Let's Encrypt | [✅][certificate-management-omnibus] | [✅][certificate-management-charts] | [⚙][certificate-management-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#secrets-management) | [⚙][certificate-management-source] | [⚙][certificate-management-gdk] | CE & EE | | [GitLab Geo Node](#gitlab-geo) | Geographically distributed GitLab nodes | [⚙][geo-omnibus] | [❌][geo-charts] | [❌][geo-charts] | ✅ | ❌ | [⚙][geo-gdk] | EE Only | @@ -263,7 +263,7 @@ You can use it either for personal or business websites, such as portfolios, doc GitLab Runner runs tests and sends the results to GitLab. -GitLab CI is the open-source continuous integration service included with GitLab that coordinates the testing. The old name of this project was GitLab CI Multi Runner but please use "GitLab Runner" (without CI) from now on. +GitLab CI/CD is the open-source continuous integration service included with GitLab that coordinates the testing. The old name of this project was `GitLab CI Multi Runner` but please use `GitLab Runner` (without CI) from now on. #### GitLab Shell diff --git a/doc/development/auto_devops.md b/doc/development/auto_devops.md index fb2992623df..656fb2ed1ad 100644 --- a/doc/development/auto_devops.md +++ b/doc/development/auto_devops.md @@ -5,7 +5,7 @@ This document provides a development guide for contributors to ## Development -Auto DevOps builds on top of GitLab CI to create an automatic pipeline +Auto DevOps builds on top of GitLab CI/CD to create an automatic pipeline based on your project contents. When Auto DevOps is enabled for a project, the user does not need to explicitly include any pipeline configuration through a [`.gitlab-ci.yml` file](../ci/yaml/README.md). diff --git a/doc/development/dangerbot.md b/doc/development/dangerbot.md index b6362f04311..2e4451949aa 100644 --- a/doc/development/dangerbot.md +++ b/doc/development/dangerbot.md @@ -1,6 +1,6 @@ # Danger bot -The GitLab CI pipeline includes a `danger-review` job that uses [Danger](https://github.com/danger/danger) +The GitLab CI/CD pipeline includes a `danger-review` job that uses [Danger](https://github.com/danger/danger) to perform a variety of automated checks on the code under test. Danger is a gem that runs in the CI environment, like any other analysis tool. diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md index 2a5779d2fe3..b386d0e78ff 100644 --- a/doc/development/ee_features.md +++ b/doc/development/ee_features.md @@ -506,17 +506,17 @@ end Note that due to namespace differences, we need to use the full qualifier for some constants. -#### EE params +#### EE parameters We can define `params` and utilize `use` in another `params` definition to -include params defined in EE. However, we need to define the "interface" first +include parameters defined in EE. However, we need to define the "interface" first in CE in order for EE to override it. We don't have to do this in other places due to `prepend_if_ee`, but Grape is complex internally and we couldn't easily do that, so we'll follow regular object-oriented practices that we define the interface first here. -For example, suppose we have a few more optional params for EE. We can move the -params out of the `Grape::API` class to a helper module, so we can inject it +For example, suppose we have a few more optional parameters for EE. We can move the +paramters out of the `Grape::API` class to a helper module, so we can inject it before it would be used in the class. ```ruby diff --git a/doc/development/fe_guide/style/scss.md b/doc/development/fe_guide/style/scss.md index 6d378db417b..83dd7990951 100644 --- a/doc/development/fe_guide/style/scss.md +++ b/doc/development/fe_guide/style/scss.md @@ -245,7 +245,7 @@ ruleset in `.scss-lint.yml`, which is located in the home directory of the project. To check if any warnings will be produced by your changes, you can run `rake -scss_lint` in the GitLab directory. SCSS Lint will also run in GitLab CI to +scss_lint` in the GitLab directory. SCSS Lint will also run in GitLab CI/CD to catch any warnings. If the Rake task is throwing warnings you don't understand, SCSS Lint's diff --git a/doc/development/feature_flags/development.md b/doc/development/feature_flags/development.md index b3fc9c291c6..d1b1bd00e1b 100644 --- a/doc/development/feature_flags/development.md +++ b/doc/development/feature_flags/development.md @@ -81,7 +81,7 @@ Feature groups must be defined statically in `lib/feature.rb` (in the dynamic (querying the DB etc.). Once defined in `lib/feature.rb`, you will be able to activate a -feature for a given feature group via the [`feature_group` param of the features API](../../api/features.md#set-or-create-a-feature) +feature for a given feature group via the [`feature_group` parameter of the features API](../../api/features.md#set-or-create-a-feature) ### Frontend diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md index e5392af1c2e..3b5071f767c 100644 --- a/doc/development/integrations/secure.md +++ b/doc/development/integrations/secure.md @@ -170,7 +170,7 @@ it is recommended to expose configuration as environment variables, not files. ### Output file -Like any artifact uploaded to the GitLab CI, +Like any artifact uploaded to the GitLab CI/CD, the Secure report generated by the scanner must be written in the project directory, given by the `CI_PROJECT_DIR` environment variable. diff --git a/doc/development/internal_api.md b/doc/development/internal_api.md index 60aec3a720a..e8fca7535b0 100644 --- a/doc/development/internal_api.md +++ b/doc/development/internal_api.md @@ -15,7 +15,7 @@ default this is in the root of the rails app named `.gitlab_shell_secret` To authenticate using that token, clients read the contents of that -file, and include the token Base64 encoded in a `secret_token` param +file, and include the token Base64 encoded in a `secret_token` parameter or in the `Gitlab-Shared-Secret` header. NOTE: **Note:** diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md index d395bf13982..a285d30d7a5 100644 --- a/doc/development/merge_request_performance_guidelines.md +++ b/doc/development/merge_request_performance_guidelines.md @@ -377,7 +377,7 @@ Examples: in service degradation as the system will try to process all schedules assigned the the project. -1. GitLab CI includes: We started with the limit of maximum of 50 nested includes. +1. GitLab CI/CD includes: We started with the limit of maximum of 50 nested includes. We understood that performance of the feature was acceptable at that level. We received a request from the community that the limit is too small. We had a time to understand the customer requirement, and implement an additional diff --git a/doc/integration/jenkins.md b/doc/integration/jenkins.md index 77912a543d0..fee30578be4 100644 --- a/doc/integration/jenkins.md +++ b/doc/integration/jenkins.md @@ -13,7 +13,7 @@ document. ## Overview [Jenkins](https://jenkins.io/) is a great Continuous Integration tool, similar to our built-in -[GitLab CI](../ci/README.md). +[GitLab CI/CD](../ci/README.md). GitLab's Jenkins integration allows you to trigger a Jenkins build when you push code to a repository, or when a merge request is created. Additionally, @@ -26,7 +26,7 @@ and [Migrating from Jenkins to GitLab](https://www.youtube.com/watch?v=RlEVGOpYF - Suppose you are new to GitLab, and want to keep using Jenkins until you prepare your projects to build with [GitLab CI/CD](../ci/README.md). You set up the - integration between GitLab and Jenkins, then you migrate to GitLab CI later. While + integration between GitLab and Jenkins, then you migrate to GitLab CI/CD later. While you organize yourself and your team to onboard GitLab, you keep your pipelines running with Jenkins, but view the results in your project's repository in GitLab. - Your team uses [Jenkins Plugins](https://plugins.jenkins.io/) for other proceedings, diff --git a/doc/intro/README.md b/doc/intro/README.md index 58cb11423d5..879d406d144 100644 --- a/doc/intro/README.md +++ b/doc/intro/README.md @@ -35,7 +35,7 @@ Create merge requests and review code. Use the built-in continuous integration in GitLab. -- [Get started with GitLab CI](../ci/quick_start/README.md) +- [Get started with GitLab CI/CD](../ci/quick_start/README.md) ## Install and Update diff --git a/doc/push_rules/push_rules.md b/doc/push_rules/push_rules.md index 86826141b8b..eca1f8c24a4 100644 --- a/doc/push_rules/push_rules.md +++ b/doc/push_rules/push_rules.md @@ -40,7 +40,7 @@ will be accepted. Let's assume there's a strict policy for branch names in your company, and you want the branches to start with a certain name because you have different -GitLab CI jobs (`feature`, `hotfix`, `docker`, `android`, etc.) that rely on the +GitLab CI/CD jobs (`feature`, `hotfix`, `docker`, `android`, etc.) that rely on the branch name. Your developers however, don't always remember that policy, so they push diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index 8af5b6321f1..093f595258d 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -799,7 +799,7 @@ networkPolicy: ``` For more information on how to install Network Policies, see -[Install Cilium using GitLab CI](../../user/clusters/applications.md#install-cilium-using-gitlab-cicd). +[Install Cilium using GitLab CI/CD](../../user/clusters/applications.md#install-cilium-using-gitlab-cicd). #### Web Application Firewall (ModSecurity) customization diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md index 0fab4de8454..fb47899c585 100644 --- a/doc/topics/gitlab_flow.md +++ b/doc/topics/gitlab_flow.md @@ -309,7 +309,7 @@ In old workflows, the continuous integration (CI) server commonly ran tests on t Developers had to ensure their code did not break the `master` branch. When using GitLab flow, developers create their branches from this `master` branch, so it is essential that it never breaks. Therefore, each merge request must be tested before it is accepted. -CI software like Travis CI and GitLab CI show the build results right in the merge request itself to make this easy. +CI software like Travis CI and GitLab CI/CD show the build results right in the merge request itself to make this easy. There is one drawback to testing merge requests: the CI server only tests the feature branch itself, not the merged result. Ideally, the server could also test the `master` branch after each change. diff --git a/doc/topics/index.md b/doc/topics/index.md index 71048ec5aa4..e2749b58b03 100644 --- a/doc/topics/index.md +++ b/doc/topics/index.md @@ -9,7 +9,7 @@ tutorials, technical overviews, blog posts) and videos. - [Auto DevOps](autodevops/index.md) - [Authentication](authentication/index.md) -- [Continuous Integration (GitLab CI)](../ci/README.md) +- [Continuous Integration (GitLab CI/CD)](../ci/README.md) - [Git](git/index.md) - [GitLab Flow](gitlab_flow.md) - [GitLab Installation](../install/README.md) diff --git a/doc/university/README.md b/doc/university/README.md index 2275130b3ab..9d3d3b33560 100644 --- a/doc/university/README.md +++ b/doc/university/README.md @@ -107,7 +107,7 @@ The GitLab University curriculum is composed of GitLab videos, screencasts, pres ### 2.3. Continuous Integration 1. [Operating Systems, Servers, VMs, Containers and Unix - Video](https://www.youtube.com/watch?v=V61kL6IC-zY&index=8&list=PLFGfElNsQthbQu_IWlNOxul0TbS_2JH-e) -1. [GitLab CI - Product Page](https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/) +1. [GitLab CI/CD - Product Page](https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/) 1. [Getting started with GitLab and GitLab CI](https://about.gitlab.com/blog/2015/12/14/getting-started-with-gitlab-and-gitlab-ci/) 1. [GitLab Container Registry](https://about.gitlab.com/blog/2016/05/23/gitlab-container-registry/) 1. [GitLab and Docker - Video](https://www.youtube.com/watch?v=ugOrCcbdHko&index=12&list=PLFGfElNsQthbQu_IWlNOxul0TbS_2JH-e) diff --git a/doc/university/support/README.md b/doc/university/support/README.md index ebdd453ff3c..ab40f1b3610 100644 --- a/doc/university/support/README.md +++ b/doc/university/support/README.md @@ -173,7 +173,7 @@ Move on to understanding some of GitLab's more advanced features. You can make u - Set up and try [Git LFS](../../administration/lfs/manage_large_binaries_with_git_lfs.md) - Get to know the [GitLab API](../../api/README.md), its capabilities and shortcomings - Learn how to [migrate from SVN to Git](../../user/project/import/svn.md) -- Set up [GitLab CI](../../ci/quick_start/README.md) +- Set up [GitLab CI/CD](../../ci/quick_start/README.md) - Create your first [GitLab Page](../../administration/pages/index.md) - Get to know the GitLab Codebase by reading through the source code: - Find the differences between the [EE codebase](https://gitlab.com/gitlab-org/gitlab-foss) diff --git a/doc/user/analytics/value_stream_analytics.md b/doc/user/analytics/value_stream_analytics.md index 5d621fb7faf..f54cf84af5d 100644 --- a/doc/user/analytics/value_stream_analytics.md +++ b/doc/user/analytics/value_stream_analytics.md @@ -72,9 +72,9 @@ Each stage of Value Stream Analytics is further described in the table below. | Issue | Measures the median time between creating an issue and taking action to solve it, by either labeling it or adding it to a milestone, whatever comes first. The label will be tracked only if it already has an [Issue Board list](../project/issue_board.md#creating-a-new-list) created for it. | | Plan | Measures the median time between the action you took for the previous stage, and pushing the first commit to the branch. The very first commit of the branch is the one that triggers the separation between **Plan** and **Code**, and at least one of the commits in the branch needs to contain the related issue number (e.g., `#42`). If none of the commits in the branch mention the related issue number, it is not considered to the measurement time of the stage. | | Code | Measures the median time between pushing a first commit (previous stage) and creating a merge request (MR) related to that commit. The key to keep the process tracked is to include the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically) to the description of the merge request (for example, `Closes #xxx`, where `xxx` is the number of the issue related to this merge request). If the issue closing pattern is not present in the merge request description, the MR is not considered to the measurement time of the stage. | -| Test | Measures the median time to run the entire pipeline for that project. It's related to the time GitLab CI takes to run every job for the commits pushed to that merge request defined in the previous stage. It is basically the start->finish time for all pipelines. | +| Test | Measures the median time to run the entire pipeline for that project. It's related to the time GitLab CI/CD takes to run every job for the commits pushed to that merge request defined in the previous stage. It is basically the start->finish time for all pipelines. | | Review | Measures the median time taken to review the merge request that has a closing issue pattern, between its creation and until it's merged. | -| Staging | Measures the median time between merging the merge request with a closing issue pattern until the very first deployment to production. It's tracked by the environment set to `production` or matching `production/*` (case-sensitive, `Production` won't work) in your GitLab CI configuration. If there isn't a production environment, this is not tracked. | +| Staging | Measures the median time between merging the merge request with a closing issue pattern until the very first deployment to production. It's tracked by the environment set to `production` or matching `production/*` (case-sensitive, `Production` won't work) in your GitLab CI/CD configuration. If there isn't a production environment, this is not tracked. | | Total | The sum of all time (medians) taken to run the entire process, from issue creation to deploying the code to production. [Previously known](https://gitlab.com/gitlab-org/gitlab/issues/38317) as **Production**. | How this works, behind the scenes: diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md index ff4ea13c392..dcbaff70633 100644 --- a/doc/user/application_security/dast/index.md +++ b/doc/user/application_security/dast/index.md @@ -86,7 +86,7 @@ There are two ways to define the URL to be scanned by DAST: 1. Add it in an `environment_url.txt` file at the root of your project. This is great for testing in dynamic environments. In order to run DAST against - an app that is dynamically created during a GitLab CI pipeline, have the app + an app that is dynamically created during a GitLab CI/CD pipeline, have the app persist its domain in an `environment_url.txt` file, and DAST will automatically parse that file to find its scan target. You can see an [example](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml) diff --git a/doc/user/packages/conan_repository/index.md b/doc/user/packages/conan_repository/index.md index 3b993303391..aa81b3d056e 100644 --- a/doc/user/packages/conan_repository/index.md +++ b/doc/user/packages/conan_repository/index.md @@ -268,7 +268,7 @@ The GitLab Conan repository supports the following Conan CLI commands: > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/11678) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.7. -To work with Conan commands within [GitLab CI](./../../../ci/README.md), you can use +To work with Conan commands within [GitLab CI/CD](./../../../ci/README.md), you can use `CI_JOB_TOKEN` in place of the personal access token in your commands. It is easiest to provide the `CONAN_LOGIN_USERNAME` and `CONAN_PASSWORD` with each diff --git a/doc/user/packages/maven_repository/index.md b/doc/user/packages/maven_repository/index.md index f4e2b71dd3c..58f0f46052d 100644 --- a/doc/user/packages/maven_repository/index.md +++ b/doc/user/packages/maven_repository/index.md @@ -481,7 +481,7 @@ Docker container), and Maven will utilize the configured CI ### Useful Maven command line options There's some [maven command line options](https://maven.apache.org/ref/current/maven-embedder/cli.html) -which maybe useful when doing tasks with GitLab CI. +which maybe useful when doing tasks with GitLab CI/CD. - File transfer progress can make the CI logs hard to read. Option `-ntp,--no-transfer-progress` was added in diff --git a/doc/user/packages/npm_registry/index.md b/doc/user/packages/npm_registry/index.md index e5cd45ee707..373e399d56f 100644 --- a/doc/user/packages/npm_registry/index.md +++ b/doc/user/packages/npm_registry/index.md @@ -285,7 +285,7 @@ page. ## Publishing a package with CI/CD -To work with NPM commands within [GitLab CI](./../../../ci/README.md), you can use +To work with NPM commands within [GitLab CI/CD](./../../../ci/README.md), you can use `CI_JOB_TOKEN` in place of the personal access token in your commands. A simple example `.gitlab-ci.yml` file for publishing NPM packages: diff --git a/doc/user/project/clusters/serverless/aws.md b/doc/user/project/clusters/serverless/aws.md index cd8f7e049a3..3df57e3a7a5 100644 --- a/doc/user/project/clusters/serverless/aws.md +++ b/doc/user/project/clusters/serverless/aws.md @@ -119,7 +119,7 @@ production: This example code does the following: -1. Uses the `node:latest` image for all GitLab CI builds +1. Uses the `node:latest` image for all GitLab CI/CD builds 1. The `deploy` stage: - Installs the Serverless Framework. - Deploys the serverless function to your AWS account using the AWS credentials @@ -164,7 +164,7 @@ That should output: } ``` -Hooray! You now have a AWS Lambda function deployed via GitLab CI. +Hooray! You now have a AWS Lambda function deployed via GitLab CI/CD. Nice work! @@ -222,7 +222,7 @@ provider: ``` From there, you can reference them in your functions as well. -Remember to add `A_VARIABLE` to your GitLab CI variables under **Settings > CI/CD > Variables**, and it will get picked up and deployed with your function. +Remember to add `A_VARIABLE` to your GitLab CI/CD variables under **Settings > CI/CD > Variables**, and it will get picked up and deployed with your function. NOTE: **Note:** Anyone with access to the AWS environment may be able to see the values of those diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md index efffdaab8e5..418e16aa0c1 100644 --- a/doc/user/project/clusters/serverless/index.md +++ b/doc/user/project/clusters/serverless/index.md @@ -14,7 +14,7 @@ GitLab supports several ways deploy Serverless applications in both Kubernetes E Currently we support: - [Knative](#knative): Build Knative applications with Knative and `gitlabktl` on GKE and EKS. -- [AWS Lambda](aws.md): Create serverless applications via the Serverless Framework and GitLab CI. +- [AWS Lambda](aws.md): Create serverless applications via the Serverless Framework and GitLab CI/CD. ## Knative diff --git a/doc/user/project/deploy_boards.md b/doc/user/project/deploy_boards.md index c2d7fe89833..daeca8aa614 100644 --- a/doc/user/project/deploy_boards.md +++ b/doc/user/project/deploy_boards.md @@ -140,7 +140,7 @@ version of your application. ## Further reading - [GitLab Autodeploy][autodeploy] -- [GitLab CI environment variables][variables] +- [GitLab CI/CD environment variables][variables] - [Environments and deployments][environment] - [Kubernetes deploy example][kube-deploy] @@ -153,7 +153,7 @@ version of your application. [kube-exec]: https://docs.gitlab.com/runner/executors/kubernetes.html "GitLab Runner Kubernetes executor" [kube-service]: integrations/kubernetes.md "Kubernetes project service" [review apps]: ../../ci/review_apps/index.md "Review Apps documentation" -[variables]: ../../ci/variables/README.md "GitLab CI variables" +[variables]: ../../ci/variables/README.md "GitLab CI/CD variables" [autodeploy]: ../../topics/autodevops/index.md#auto-deploy "GitLab Autodeploy" [kube-image]: https://gitlab.com/gitlab-examples/kubernetes-deploy/container_registry "Kubernetes deploy Container Registry" [runners]: ../../ci/runners/README.md diff --git a/doc/user/project/index.md b/doc/user/project/index.md index 3a356ec0418..f5bb2ee78d9 100644 --- a/doc/user/project/index.md +++ b/doc/user/project/index.md @@ -65,7 +65,7 @@ When you create a project in GitLab, you'll have access to a large number of images out-of-the-box - [Auto Deploy](../../topics/autodevops/index.md#auto-deploy): Configure GitLab CI/CD to automatically set up your app's deployment - - [Enable and disable GitLab CI](../../ci/enable_or_disable_ci.md) + - [Enable and disable GitLab CI/CD](../../ci/enable_or_disable_ci.md) - [Pipelines](../../ci/pipelines/index.md): Configure and visualize your GitLab CI/CD pipelines from the UI - [Scheduled Pipelines](../../ci/pipelines/schedules.md): Schedule a pipeline diff --git a/doc/user/project/new_ci_build_permissions_model.md b/doc/user/project/new_ci_build_permissions_model.md index 51ea070f60a..9ecfcd12b80 100644 --- a/doc/user/project/new_ci_build_permissions_model.md +++ b/doc/user/project/new_ci_build_permissions_model.md @@ -186,7 +186,7 @@ echo -e "machine gitlab.com\nlogin gitlab-ci-token\npassword ${CI_JOB_TOKEN}" > ### Git submodules -To properly configure submodules with GitLab CI, read the +To properly configure submodules with GitLab CI/CD, read the [Git submodules documentation][gitsub]. ### Container Registry diff --git a/doc/user/project/pages/getting_started_part_four.md b/doc/user/project/pages/getting_started_part_four.md index d6b34f4319e..645cc1c5795 100644 --- a/doc/user/project/pages/getting_started_part_four.md +++ b/doc/user/project/pages/getting_started_part_four.md @@ -40,7 +40,7 @@ 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 [Yaml](https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html) file, with its own syntax. You can always check your CI syntax with -the [GitLab CI Lint Tool](https://gitlab.com/ci/lint). +the [GitLab CI/CD Lint Tool](https://gitlab.com/ci/lint). ## Practical example @@ -48,7 +48,7 @@ Let's consider you have a [Jekyll](https://jekyllrb.com/) site. To build it locally, you would open your terminal, and run `jekyll build`. Of course, before building it, you had to install Jekyll in your computer. For that, you had to open your terminal and run `gem install jekyll`. -Right? GitLab CI + GitLab Runner do the same thing. But you need to +Right? GitLab CI/CD + GitLab Runner do the same thing. But you need to write in the `.gitlab-ci.yml` the script you want to run so GitLab Runner will do it for you. It looks more complicated than it is. What you need to tell the Runner: @@ -144,7 +144,7 @@ pages: That's it! A `.gitlab-ci.yml` with the content above would deploy your Jekyll 3.4.0 site with GitLab Pages. This is the minimum configuration for our example. On the steps below, we'll refine -the script by adding extra options to our GitLab CI. +the script by adding extra options to our GitLab CI/CD. Artifacts will be automatically deleted once GitLab Pages got deployed. You can preserve artifacts for limited time by specifying the expiry time. @@ -216,7 +216,7 @@ pages: Another interesting concept to keep in mind are build stages. Your web app can pass through a lot of tests and other tasks until it's deployed to staging or production environments. -There are three default stages on GitLab CI: build, test, +There are three default stages on GitLab CI/CD: build, test, and deploy. To specify which stage your _job_ is running, simply add another line to your CI: @@ -279,7 +279,7 @@ parallel. So, if your web app needs more than one test before being deployed, you can run all your test at the same time, it's not necessary to wait one test to finish to run the other. Of course, this is just a brief -introduction of GitLab CI and GitLab Runner, which are +introduction of GitLab CI/CD and GitLab Runner, which are tools much more powerful than that. This is what you need to be able to create and tweak your builds for your GitLab Pages site. @@ -369,22 +369,22 @@ exclude: - vendor ``` -There we go! Now our GitLab CI not only builds our website, +There we go! Now our GitLab CI/CD not only builds our website, but also **continuously test** pushes to feature-branches, **caches** dependencies installed with Bundler, and **continuously deploy** every push to the `master` branch. ## Advanced GitLab CI for GitLab Pages -What you can do with GitLab CI is pretty much up to your +What you can do with GitLab CI/CD is pretty much up to your creativity. Once you get used to it, you start creating awesome scripts that automate most of tasks you'd do manually in the past. Read through the -[documentation of GitLab CI](../../../ci/yaml/README.md) +[documentation of GitLab CI/CD](../../../ci/yaml/README.md) to understand how to go even further on your scripts. - On this blog post, understand the concept of - [using GitLab CI `environments` to deploy your + [using GitLab CI/CD `environments` to deploy your web app to staging and production](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/). - On this post, learn [how to run jobs sequentially, in parallel, or build a custom pipeline](https://about.gitlab.com/blog/2016/07/29/the-basics-of-gitlab-ci/) diff --git a/doc/user/project/pages/index.md b/doc/user/project/pages/index.md index 4ebe37394b4..02bb8e13f4a 100644 --- a/doc/user/project/pages/index.md +++ b/doc/user/project/pages/index.md @@ -95,7 +95,7 @@ To learn more about configuration options for GitLab Pages, read the following: | --- | --- | | [GitLab Pages domain names, URLs, and baseurls](getting_started_part_one.md) | Understand how GitLab Pages default domains work. | | [GitLab CI/CD for GitLab Pages](getting_started_part_four.md) | Understand how to create your own `.gitlab-ci.yml` for your site. | -| [Exploring GitLab Pages](introduction.md) | Requirements, technical aspects, specific GitLab CI's configuration options, Access Control, custom 404 pages, limitations, FAQ. | +| [Exploring GitLab Pages](introduction.md) | Requirements, technical aspects, specific GitLab CI/CD's configuration options, Access Control, custom 404 pages, limitations, FAQ. | |---+---| | [Custom domains and SSL/TLS Certificates](custom_domains_ssl_tls_certification/index.md) | How to add custom domains and subdomains to your website, configure DNS records and SSL/TLS certificates. | | [Let's Encrypt integration](custom_domains_ssl_tls_certification/lets_encrypt_integration.md) | Secure your Pages sites with Let's Encrypt certificates automatically obtained and renewed by GitLab. | diff --git a/doc/user/project/pages/introduction.md b/doc/user/project/pages/introduction.md index f95ee26a226..798efe6fa1d 100644 --- a/doc/user/project/pages/introduction.md +++ b/doc/user/project/pages/introduction.md @@ -288,17 +288,6 @@ No, you don't. You can create your project first and it will be accessed under For a list of known issues, visit GitLab's [public issue tracker]. -[jekyll]: http://jekyllrb.com/ -[pages-daemon]: https://gitlab.com/gitlab-org/gitlab-pages -[gitlab ci]: https://about.gitlab.com/gitlab-ci -[gitlab runner]: https://docs.gitlab.com/runner/ [pages]: ../../../ci/yaml/README.md#pages -[yaml]: ../../../ci/yaml/README.md -[staticgen]: https://www.staticgen.com/ -[pages-jekyll]: https://gitlab.com/pages/jekyll [metarefresh]: https://en.wikipedia.org/wiki/Meta_refresh [public issue tracker]: https://gitlab.com/gitlab-org/gitlab/-/issues?label_name[]=Category%3APages -[quick start guide]: ../../../ci/quick_start/README.md -[pages-index-guide]: index.md -[pages-quick]: getting_started_part_one.md -[video-pages-fork]: https://youtu.be/TWqh9MtT4Bg diff --git a/doc/user/project/repository/index.md b/doc/user/project/repository/index.md index 6b0c58e60bd..a9647a9ed0f 100644 --- a/doc/user/project/repository/index.md +++ b/doc/user/project/repository/index.md @@ -157,7 +157,7 @@ Via command line, you can commit multiple times before pushing. - **Skip pipelines:** You can add to you commit message the keyword [`[ci skip]`](../../../ci/yaml/README.md#skipping-jobs) - and GitLab CI will skip that pipeline. + and GitLab CI/CD will skip that pipeline. - **Cross-link issues and merge requests:** [Cross-linking](../issues/crosslinking_issues.md#from-commit-messages) is great to keep track of what's is somehow related in your workflow. diff --git a/doc/user/project/service_desk.md b/doc/user/project/service_desk.md index a0a4a9f55ea..f18a202c63b 100644 --- a/doc/user/project/service_desk.md +++ b/doc/user/project/service_desk.md @@ -24,7 +24,7 @@ For an overview, check the video demonstration on [GitLab Service Desk](https:// For instance, let's assume you develop a game for iOS or Android. The codebase is hosted in your GitLab instance, built and deployed -with GitLab CI. +with GitLab CI/CD. Here's how Service Desk will work for you: diff --git a/spec/frontend/registry/explorer/components/quickstart_dropdown_spec.js b/spec/frontend/registry/explorer/components/quickstart_dropdown_spec.js index 3dfe50ebe13..0c3baefbc58 100644 --- a/spec/frontend/registry/explorer/components/quickstart_dropdown_spec.js +++ b/spec/frontend/registry/explorer/components/quickstart_dropdown_spec.js @@ -1,6 +1,7 @@ import Vuex from 'vuex'; import { mount, createLocalVue } from '@vue/test-utils'; import { GlDropdown, GlFormGroup, GlFormInputGroup } from '@gitlab/ui'; +import Tracking from '~/tracking'; import * as getters from '~/registry/explorer/stores/getters'; import QuickstartDropdown from '~/registry/explorer/components/quickstart_dropdown.vue'; import ClipboardButton from '~/vue_shared/components/clipboard_button.vue'; @@ -42,6 +43,7 @@ describe('quickstart_dropdown', () => { }; beforeEach(() => { + jest.spyOn(Tracking, 'event'); mountComponent(); }); @@ -55,12 +57,21 @@ describe('quickstart_dropdown', () => { expect(findDropdownButton().text()).toContain(QUICK_START); }); + it('clicking on the dropdown emit a tracking event', () => { + findDropdownButton().vm.$emit('shown'); + expect(Tracking.event).toHaveBeenCalledWith( + undefined, + 'click_dropdown', + expect.objectContaining({ label: 'quickstart_dropdown' }), + ); + }); + describe.each` - index | id | labelText | titleText | getter - ${0} | ${'docker-login-btn'} | ${LOGIN_COMMAND_LABEL} | ${COPY_LOGIN_TITLE} | ${'dockerLoginCommand'} - ${1} | ${'docker-build-btn'} | ${BUILD_COMMAND_LABEL} | ${COPY_BUILD_TITLE} | ${'dockerBuildCommand'} - ${2} | ${'docker-push-btn'} | ${PUSH_COMMAND_LABEL} | ${COPY_PUSH_TITLE} | ${'dockerPushCommand'} - `('form group at $index', ({ index, id, labelText, titleText, getter }) => { + index | id | labelText | titleText | getter | trackedEvent + ${0} | ${'docker-login-btn'} | ${LOGIN_COMMAND_LABEL} | ${COPY_LOGIN_TITLE} | ${'dockerLoginCommand'} | ${'click_copy_login'} + ${1} | ${'docker-build-btn'} | ${BUILD_COMMAND_LABEL} | ${COPY_BUILD_TITLE} | ${'dockerBuildCommand'} | ${'click_copy_build'} + ${2} | ${'docker-push-btn'} | ${PUSH_COMMAND_LABEL} | ${COPY_PUSH_TITLE} | ${'dockerPushCommand'} | ${'click_copy_push'} + `('form group at $index', ({ index, id, labelText, titleText, getter, trackedEvent }) => { let formGroup; const findFormInputGroup = parent => parent.find(GlFormInputGroup); @@ -91,5 +102,19 @@ describe('quickstart_dropdown', () => { expect(clipBoardButton.props('title')).toBe(titleText); expect(clipBoardButton.props('text')).toBe(store.getters[getter]); }); + + it('clipboard button tracks click event', () => { + const clipBoardButton = findClipboardButton(formGroup); + clipBoardButton.trigger('click'); + /* This expect to be called with first argument undefined so that + * the function internally can default to document.body.dataset.page + * https://docs.gitlab.com/ee/telemetry/frontend.html#tracking-within-vue-components + */ + expect(Tracking.event).toHaveBeenCalledWith( + undefined, + trackedEvent, + expect.objectContaining({ label: 'quickstart_dropdown' }), + ); + }); }); }); |