From c8489a149e99123aa1d7425677eb720c31ae7dd8 Mon Sep 17 00:00:00 2001 From: GitLab Bot Date: Thu, 3 Sep 2020 00:10:28 +0000 Subject: [PATCH] Add latest changes from gitlab-org/gitlab@master --- GITALY_SERVER_VERSION | 2 +- .../components/delete_account_modal.vue | 6 +- doc/ci/runners/README.md | 286 +++++++++--------- doc/development/cicd/index.md | 2 +- doc/development/telemetry/snowplow.md | 16 +- doc/development/telemetry/usage_ping.md | 2 - doc/ssh/README.md | 2 +- qa/qa/page/profile/accounts/show.rb | 7 +- vendor/gitignore/C++.gitignore | 0 vendor/gitignore/Java.gitignore | 0 10 files changed, 161 insertions(+), 162 deletions(-) mode change 100755 => 100644 vendor/gitignore/C++.gitignore mode change 100755 => 100644 vendor/gitignore/Java.gitignore diff --git a/GITALY_SERVER_VERSION b/GITALY_SERVER_VERSION index 93471b43e4b..e7ceb275bc4 100644 --- a/GITALY_SERVER_VERSION +++ b/GITALY_SERVER_VERSION @@ -1 +1 @@ -10ef65465876db3a9539dba1aa4d789f1cf2cb3b +a783958be5ae0797dac9041bdfb884440e0e6306 diff --git a/app/assets/javascripts/profile/account/components/delete_account_modal.vue b/app/assets/javascripts/profile/account/components/delete_account_modal.vue index 24b142050d6..b99dd32c7b6 100644 --- a/app/assets/javascripts/profile/account/components/delete_account_modal.vue +++ b/app/assets/javascripts/profile/account/components/delete_account_modal.vue @@ -63,7 +63,11 @@ Once you confirm %{deleteAccount}, it cannot be undone or recovered.`), primaryProps() { return { text: s__('Delete account'), - attributes: [{ variant: 'danger' }, { category: 'primary' }, { disabled: !this.canSubmit }], + attributes: [ + { variant: 'danger', 'data-qa-selector': 'confirm_deletion_button' }, + { category: 'primary' }, + { disabled: !this.canSubmit }, + ], }; }, cancelProps() { diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md index 71c107d32a6..f64561b3249 100644 --- a/doc/ci/runners/README.md +++ b/doc/ci/runners/README.md @@ -5,62 +5,62 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: reference --- -# Configuring GitLab Runners +# Configuring runners in GitLab - + -In GitLab CI/CD, Runners run the code defined in [`.gitlab-ci.yml`](../yaml/README.md). -A GitLab Runner is a lightweight, highly-scalable agent that picks up a CI job through +In GitLab CI/CD, runners run the code defined in [`.gitlab-ci.yml`](../yaml/README.md). +A runner is a lightweight, highly-scalable agent that picks up a CI job through the coordinator API of GitLab CI/CD, runs the job, and sends the result back to the GitLab instance. Runners are created by an administrator and are visible in the GitLab UI. Runners can be specific to certain projects or available to all projects. -## Types of Runners +## Types of runners -There are three types of Runners: +There are three types of runners: - [Shared](#shared-runners) (for all projects) - [Group](#group-runners) (for all projects in a group) - [Specific](#specific-runners) (for specific projects) -If you are running self-managed GitLab, you can create your own Runners. +If you are running self-managed GitLab, you can create your own runners. -If you are using GitLab.com, you can use the shared Runners provided by GitLab or -create your own group or specific Runners. +If you are using GitLab.com, you can use the shared runners provided by GitLab or +create your own group or specific runners. -### Shared Runners +### Shared runners -*Shared Runners* are available to every project in a GitLab instance. +*Shared runners* are available to every project in a GitLab instance. -Use shared Runners when you have multiple jobs with similar requirements. Rather than -having multiple Runners idling for many projects, you can have a few Runners that handle +Use shared runners when you have multiple jobs with similar requirements. Rather than +having multiple runners idling for many projects, you can have a few runners that handle multiple projects. If you are using a self-managed instance of GitLab: -- Your administrator can install and register shared Runners by viewing the instructions +- Your administrator can install and register shared runners by viewing the instructions [here](https://docs.gitlab.com/runner/install/index.html). + -- The administrator can also configure a maximum number of shared Runner [pipeline minutes for +- The administrator can also configure a maximum number of shared runner [pipeline minutes for each group](../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota-starter-only). If you are using GitLab.com: -- You can select from a list of [shared Runners that GitLab maintains](../../user/gitlab_com/index.md#shared-runners). -- The shared Runners consume the [pipelines minutes](../../subscriptions/index.md#ci-pipeline-minutes) +- You can select from a list of [shared runners that GitLab maintains](../../user/gitlab_com/index.md#shared-runners). +- The shared runners consume the [pipelines minutes](../../subscriptions/index.md#ci-pipeline-minutes) included with your account. -#### How shared Runners pick jobs +#### How shared runners pick jobs -Shared Runners process jobs by using a fair usage queue. This queue prevents +Shared runners process jobs by using a fair usage queue. This queue prevents projects from creating hundreds of jobs and using all available -shared Runner resources. +shared runner resources. The fair usage queue algorithm assigns jobs based on the projects that have the -fewest number of jobs already running on shared Runners. +fewest number of jobs already running on shared runners. **Example 1** @@ -106,241 +106,241 @@ The fair usage algorithm assigns jobs in this order: 1. Job 6 is next, because Project 3 is the only project left with no running jobs. 1. Lastly we choose Job 3... because, again, it's the only job left. -#### Enable shared Runners +#### Enable shared runners -On GitLab.com, [shared Runners](#shared-runners) are enabled in all projects by +On GitLab.com, [shared runners](#shared-runners) are enabled in all projects by default. On self-managed instances of GitLab, an administrator must [install](https://docs.gitlab.com/runner/install/index.html) and [register](https://docs.gitlab.com/runner/register/index.html) them. -You can also enable shared Runners for individual projects. +You can also enable shared runners for individual projects. -To enable shared Runners: +To enable shared runners: 1. Go to the project's **Settings > CI/CD** and expand the **Runners** section. -1. Click **Allow shared Runners**. +1. Click **Allow shared runners**. -#### Disable shared Runners +#### Disable shared runners -You can disable shared Runners for individual projects. +You can disable shared runners for individual projects. You must have Owner permissions for the project. -To disable shared Runners for a project: +To disable shared runners for a project: 1. Go to the project's **Settings > CI/CD** and expand the **Runners** section. -1. In the **Shared Runners** area, click **Disable shared Runners**. +1. In the **Shared runners** area, click **Disable shared runners**. - -### Group Runners +### Group runners -Use *Group Runners* when you want all projects in a group -to have access to a set of Runners. +Use *Group runners* when you want all projects in a group +to have access to a set of runners. -Group Runners process jobs by using a first in, first out ([FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics))) queue. +Group runners process jobs by using a first in, first out ([FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics))) queue. -#### Create a group Runner +#### Create a group runner -You can create a group Runner for your self-managed GitLab instance or for GitLab.com. +You can create a group runner for your self-managed GitLab instance or for GitLab.com. You must have [Owner permissions](../../user/permissions.md#group-members-permissions) for the group. -To create a group Runner: +To create a group runner: -1. [Install Runner](https://docs.gitlab.com/runner/install/). -1. Go to the group you want to make the Runner work for. +1. [Install GitLab Runner](https://docs.gitlab.com/runner/install/). +1. Go to the group you want to make the runner work for. 1. Go to **Settings > CI/CD** and expand the **Runners** section. 1. Note the URL and token. -1. [Register the Runner](https://docs.gitlab.com/runner/register/). +1. [Register the runner](https://docs.gitlab.com/runner/register/). -#### View and manage group Runners +#### View and manage group runners > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/37366/) in GitLab 13.2. -You can view and manage all Runners for a group, its subgroups, and projects. +You can view and manage all runners for a group, its subgroups, and projects. You can do this for your self-managed GitLab instance or for GitLab.com. You must have [Owner permissions](../../user/permissions.md#group-members-permissions) for the group. -1. Go to the group where you want to view the Runners. +1. Go to the group where you want to view the runners. 1. Go to **Settings > CI/CD** and expand the **Runners** section. 1. The following fields are displayed. | Attribute | Description | | ------------ | ----------- | | Type | One or more of the following states: shared, group, specific, locked, or paused | - | Runner token | Token used to identify the Runner, and which the Runner uses to communicate with the GitLab instance | - | Description | Description given to the Runner when it was created | + | Runner token | Token used to identify the runner, and that the runner uses to communicate with the GitLab instance | + | Description | Description given to the runner when it was created | | Version | GitLab Runner version | - | IP address | IP address of the host on which the Runner is registered | - | Projects | The count of projects to which the Runner is assigned | - | Jobs | Total of jobs run by the Runner | - | Tags | Tags associated with the Runner | - | Last contact | Timestamp indicating when the GitLab instance last contacted the Runner | + | IP address | IP address of the host on which the runner is registered | + | Projects | The count of projects to which the runner is assigned | + | Jobs | Total of jobs run by the runner | + | Tags | Tags associated with the runner | + | Last contact | Timestamp indicating when the GitLab instance last contacted the runner | -From this page, you can edit, pause, and remove Runners from the group, its subgroups, and projects. +From this page, you can edit, pause, and remove runners from the group, its subgroups, and projects. -#### Pause or remove a group Runner +#### Pause or remove a group runner -You can pause or remove a group Runner for your self-managed GitLab instance or for GitLab.com. +You can pause or remove a group runner for your self-managed GitLab instance or for GitLab.com. You must have [Owner permissions](../../user/permissions.md#group-members-permissions) for the group. -1. Go to the group you want to remove or pause the Runner for. +1. Go to the group you want to remove or pause the runner for. 1. Go to **Settings > CI/CD** and expand the **Runners** section. -1. Click **Pause** or **Remove Runner**. - - If you pause a group Runner that is used by multiple projects, the Runner pauses for all projects. - - From the group view, you cannot remove a Runner that is assigned to more than one project. +1. Click **Pause** or **Remove runner**. + - If you pause a group runner that is used by multiple projects, the runner pauses for all projects. + - From the group view, you cannot remove a runner that is assigned to more than one project. You must remove it from each project first. 1. On the confirmation dialog, click **OK**. -### Specific Runners +### Specific runners -Use *Specific Runners* when you want to use Runners for specific projects. For example, +Use *Specific runners* when you want to use runners for specific projects. For example, when you have: - Jobs with specific requirements, like a deploy job that requires credentials. -- Projects with a lot of CI activity that can benefit from being separate from other Runners. +- Projects with a lot of CI activity that can benefit from being separate from other runners. -You can set up a specific Runner to be used by multiple projects. Specific Runners +You can set up a specific runner to be used by multiple projects. Specific runners must be enabled for each project explicitly. -Specific Runners process jobs by using a first in, first out ([FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics))) queue. +Specific runners process jobs by using a first in, first out ([FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics))) queue. NOTE: **Note:** -Specific Runners do not get shared with forked projects automatically. +Specific runners do not get shared with forked projects automatically. A fork *does* copy the CI / CD settings of the cloned repository. -#### Create a specific Runner +#### Create a specific runner -You can create a specific Runner for your self-managed GitLab instance or for GitLab.com. +You can create a specific runner for your self-managed GitLab instance or for GitLab.com. You must have [Owner permissions](../../user/permissions.md#project-members-permissions) for the project. -To create a specific Runner: +To create a specific runner: -1. [Install Runner](https://docs.gitlab.com/runner/install/). +1. [Install runner](https://docs.gitlab.com/runner/install/). 1. Go to the project's **Settings > CI/CD** and expand the **Runners** section. 1. Note the URL and token. -1. [Register the Runner](https://docs.gitlab.com/runner/register/). +1. [Register the runner](https://docs.gitlab.com/runner/register/). -#### Enable a specific Runner for a specific project +#### Enable a specific runner for a specific project -A specific Runner is available in the project it was created for. An administrator can -enable a specific Runner to apply to additional projects. +A specific runner is available in the project it was created for. An administrator can +enable a specific runner to apply to additional projects. - You must have Owner permissions for the project. -- The specific Runner must not be [locked](#prevent-a-specific-runner-from-being-enabled-for-other-projects). +- The specific runner must not be [locked](#prevent-a-specific-runner-from-being-enabled-for-other-projects). -To enable or disable a specific Runner for a project: +To enable or disable a specific runner for a project: 1. Go to the project's **Settings > CI/CD** and expand the **Runners** section. 1. Click **Enable for this project** or **Disable for this project**. -#### Prevent a specific Runner from being enabled for other projects +#### Prevent a specific runner from being enabled for other projects -You can configure a specific Runner so it is "locked" and cannot be enabled for other projects. -This setting can be enabled when you first [register a Runner](https://docs.gitlab.com/runner/register/), +You can configure a specific runner so it is "locked" and cannot be enabled for other projects. +This setting can be enabled when you first [register a runner](https://docs.gitlab.com/runner/register/), but can also be changed later. -To lock or unlock a Runner: +To lock or unlock a runner: 1. Go to the project's **Settings > CI/CD** and expand the **Runners** section. -1. Find the Runner you want to lock or unlock. Make sure it's enabled. +1. Find the runner you want to lock or unlock. Make sure it's enabled. 1. Click the pencil button. 1. Check the **Lock to current projects** option. 1. Click **Save changes**. -## Manually clear the Runner cache +## Manually clear the runner cache Read [clearing the cache](../caching/index.md#clearing-the-cache). -## Set maximum job timeout for a Runner +## Set maximum job timeout for a runner -For each Runner, you can specify a *maximum job timeout*. This timeout, +For each runner, you can specify a *maximum job timeout*. This timeout, if smaller than the [project defined timeout](../pipelines/settings.md#timeout), takes precedence. -This feature can be used to prevent your shared Runner from being overwhelmed +This feature can be used to prevent your shared runner from being overwhelmed by a project that has jobs with a long timeout (for example, one week). -When not configured, Runners do not override the project timeout. +When not configured, runners do not override the project timeout. How this feature works: **Example 1 - Runner timeout bigger than project timeout** -1. You set the _maximum job timeout_ for a Runner to 24 hours +1. You set the _maximum job timeout_ for a runner to 24 hours 1. You set the _CI/CD Timeout_ for a project to **2 hours** 1. You start a job 1. The job, if running longer, will be timed out after **2 hours** **Example 2 - Runner timeout not configured** -1. You remove the _maximum job timeout_ configuration from a Runner +1. You remove the _maximum job timeout_ configuration from a runner 1. You set the _CI/CD Timeout_ for a project to **2 hours** 1. You start a job 1. The job, if running longer, will be timed out after **2 hours** **Example 3 - Runner timeout smaller than project timeout** -1. You set the _maximum job timeout_ for a Runner to **30 minutes** +1. You set the _maximum job timeout_ for a runner to **30 minutes** 1. You set the _CI/CD Timeout_ for a project to 2 hours 1. You start a job 1. The job, if running longer, will be timed out after **30 minutes** ## Be careful with sensitive information -With some [Runner Executors](https://docs.gitlab.com/runner/executors/README.html), -if you can run a job on the Runner, you can get full access to the file system, -and thus any code it runs as well as the token of the Runner. With shared Runners, this means that anyone -that runs jobs on the Runner, can access anyone else's code that runs on the -Runner. +With some [runner executors](https://docs.gitlab.com/runner/executors/README.html), +if you can run a job on the runner, you can get full access to the file system, +and thus any code it runs as well as the token of the runner. With shared runners, this means that anyone +that runs jobs on the runner, can access anyone else's code that runs on the +runner. -In addition, because you can get access to the Runner token, it is possible -to create a clone of a Runner and submit false jobs, for example. +In addition, because you can get access to the runner token, it is possible +to create a clone of a runner and submit false jobs, for example. -The above is easily avoided by restricting the usage of shared Runners +The above is easily avoided by restricting the usage of shared runners on large public GitLab instances, controlling access to your GitLab instance, -and using more secure [Runner Executors](https://docs.gitlab.com/runner/executors/README.html). +and using more secure [runner executors](https://docs.gitlab.com/runner/executors/README.html). -### Prevent Runners from revealing sensitive information +### Prevent runners from revealing sensitive information > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/13194) in GitLab 10.0. -You can protect Runners so they don't reveal sensitive information. -When a Runner is protected, the Runner picks jobs created on +You can protect runners so they don't reveal sensitive information. +When a runner is protected, the runner picks jobs created on [protected branches](../../user/project/protected_branches.md) or [protected tags](../../user/project/protected_tags.md) only, and ignores other jobs. -To protect or unprotect a Runner: +To protect or unprotect a runner: 1. Go to the project's **Settings > CI/CD** and expand the **Runners** section. -1. Find the Runner you want to protect or unprotect. Make sure it's enabled. +1. Find the runner you want to protect or unprotect. Make sure it's enabled. 1. Click the pencil button. 1. Check the **Protected** option. 1. Click **Save changes**. -![specific Runners edit icon](img/protected_runners_check_box.png) +![specific runners edit icon](img/protected_runners_check_box.png) ### Forks Whenever a project is forked, it copies the settings of the jobs that relate -to it. This means that if you have shared Runners set up for a project and -someone forks that project, the shared Runners serve jobs of this project. +to it. This means that if you have shared runners set up for a project and +someone forks that project, the shared runners serve jobs of this project. -### Attack vectors in Runners +### Attack vectors in runners -Mentioned briefly earlier, but the following things of Runners can be exploited. +Mentioned briefly earlier, but the following things of runners can be exploited. We're always looking for contributions that can mitigate these [Security Considerations](https://docs.gitlab.com/runner/security/). -### Reset the Runner registration token for a project +### Reset the runner registration token for a project If you think that a registration token for a project was revealed, you should -reset it. A token can be used to register another Runner for the project. That new Runner +reset it. A token can be used to register another runner for the project. That new runner may then be used to obtain the values of secret variables or to clone project code. To reset the token: @@ -353,106 +353,106 @@ To reset the token: and check the registration token - it should be changed. From now on the old token is no longer valid and does not register -any new Runners to the project. If you are using any tools to provision and -register new Runners, the tokens used in those tools should be updated to reflect the +any new runners to the project. If you are using any tools to provision and +register new runners, the tokens used in those tools should be updated to reflect the value of the new token. -## Determine the IP address of a Runner +## Determine the IP address of a runner > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17286) in GitLab 10.6. -It may be useful to know the IP address of a Runner so you can troubleshoot -issues with that Runner. GitLab stores and displays the IP address by viewing +It may be useful to know the IP address of a runner so you can troubleshoot +issues with that runner. GitLab stores and displays the IP address by viewing the source of the HTTP requests it makes to GitLab when polling for jobs. The -IP address is always kept up to date so if the Runner IP changes it will be +IP address is always kept up to date so if the runner IP changes it will be automatically updated in GitLab. -The IP address for shared Runners and specific Runners can be found in +The IP address for shared runners and specific runners can be found in different places. -### Determine the IP address of a shared Runner +### Determine the IP address of a shared runner -To view the IP address of a shared Runner you must have admin access to +To view the IP address of a shared runner you must have admin access to the GitLab instance. To determine this: 1. Visit **Admin Area > Overview > Runners**. -1. Look for the Runner in the table and you should see a column for **IP Address**. +1. Look for the runner in the table and you should see a column for **IP Address**. -![shared Runner IP address](img/shared_runner_ip_address.png) +![shared runner IP address](img/shared_runner_ip_address.png) -### Determine the IP address of a specific Runner +### Determine the IP address of a specific runner -To can find the IP address of a Runner for a specific project, +To can find the IP address of a runner for a specific project, you must have Owner [permissions](../../user/permissions.md#project-members-permissions) for the project. 1. Go to the project's **Settings > CI/CD** and expand the **Runners** section. 1. On the details page you should see a row for **IP Address**. -![specific Runner IP address](img/specific_runner_ip_address.png) +![specific runner IP address](img/specific_runner_ip_address.png) -## Use tags to limit the number of jobs using the Runner +## Use tags to limit the number of jobs using the runner -You must set up a Runner to be able to run all the different types of jobs +You must set up a runner to be able to run all the different types of jobs that it may encounter on the projects it's shared over. This would be problematic for large amounts of projects, if it weren't for tags. -By tagging a Runner for the types of jobs it can handle, you can make sure -shared Runners will [only run the jobs they are equipped to run](../yaml/README.md#tags). +By tagging a runner for the types of jobs it can handle, you can make sure +shared runners will [only run the jobs they are equipped to run](../yaml/README.md#tags). -For instance, at GitLab we have Runners tagged with `rails` if they contain +For instance, at GitLab we have runners tagged with `rails` if they contain the appropriate dependencies to run Rails test suites. -When you [register a Runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick** +When you [register a runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick** [tagged jobs](../yaml/README.md#tags). To change this, you must have Owner [permissions](../../user/permissions.md#project-members-permissions) for the project. -To make a Runner pick untagged jobs: +To make a runner pick untagged jobs: 1. Go to the project's **Settings > CI/CD** and expand the **Runners** section. -1. Find the Runner you want to pick untagged jobs and make sure it's enabled. +1. Find the runner you want to pick untagged jobs and make sure it's enabled. 1. Click the pencil button. 1. Check the **Run untagged jobs** option. 1. Click the **Save changes** button for the changes to take effect. NOTE: **Note:** -The Runner tags list can not be empty when it's not allowed to pick untagged jobs. +The runner tags list can not be empty when it's not allowed to pick untagged jobs. Below are some example scenarios of different variations. -### Runner runs only tagged jobs +### runner runs only tagged jobs -The following examples illustrate the potential impact of the Runner being set +The following examples illustrate the potential impact of the runner being set to run only tagged jobs. Example 1: -1. The Runner is configured to run only tagged jobs and has the `docker` tag. +1. The runner is configured to run only tagged jobs and has the `docker` tag. 1. A job that has a `hello` tag is executed and stuck. Example 2: -1. The Runner is configured to run only tagged jobs and has the `docker` tag. +1. The runner is configured to run only tagged jobs and has the `docker` tag. 1. A job that has a `docker` tag is executed and run. Example 3: -1. The Runner is configured to run only tagged jobs and has the `docker` tag. +1. The runner is configured to run only tagged jobs and has the `docker` tag. 1. A job that has no tags defined is executed and stuck. -### Runner is allowed to run untagged jobs +### runner is allowed to run untagged jobs -The following examples illustrate the potential impact of the Runner being set +The following examples illustrate the potential impact of the runner being set to run tagged and untagged jobs. Example 1: -1. The Runner is configured to run untagged jobs and has the `docker` tag. +1. The runner is configured to run untagged jobs and has the `docker` tag. 1. A job that has no tags defined is executed and run. 1. A second job that has a `docker` tag defined is executed and run. Example 2: -1. The Runner is configured to run untagged jobs and has no tags defined. +1. The runner is configured to run untagged jobs and has no tags defined. 1. A job that has no tags defined is executed and run. 1. A second job that has a `docker` tag defined is stuck. diff --git a/doc/development/cicd/index.md b/doc/development/cicd/index.md index c8c8c8b1ab7..38f7c391313 100644 --- a/doc/development/cicd/index.md +++ b/doc/development/cicd/index.md @@ -58,7 +58,7 @@ successfully or fail. Each status transition for job within a pipeline triggers looks for the next jobs to be transitioned towards completion. While doing that, `ProcessPipelineService` updates the status of jobs, stages and the overall pipeline. -On the right side of the diagram we have a list of [Runners](../../ci/runners/README.md#configuring-gitlab-runners) +On the right side of the diagram we have a list of [Runners](../../ci/runners/README.md) connected to the GitLab instance. These can be Shared Runners, Group Runners or Project-specific Runners. The communication between Runners and the Rails server occurs through a set of API endpoints, grouped as the `Runner API Gateway`. diff --git a/doc/development/telemetry/snowplow.md b/doc/development/telemetry/snowplow.md index 18257c5ac44..f427d7d1488 100644 --- a/doc/development/telemetry/snowplow.md +++ b/doc/development/telemetry/snowplow.md @@ -40,7 +40,7 @@ Snowplow is an enterprise-grade marketing and product analytics platform which h We have many definitions of Snowplow's schema. We have an active issue to [standardize this schema](https://gitlab.com/gitlab-org/gitlab/-/issues/207930) including the following definitions: - Frontend and backend taxonomy as listed below -- [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/product/product-processes/#taxonomy) +- [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/business-ops/data-team/programs/data-for-product-managers/#sts=Taxonomy) - [Self describing events](https://github.com/snowplow/snowplow/wiki/Custom-events#self-describing-events) - [Iglu schema](https://gitlab.com/gitlab-org/iglu/) - [Snowplow authored events](https://github.com/snowplow/snowplow/wiki/Snowplow-authored-events) @@ -98,13 +98,13 @@ sequenceDiagram ## Implementing Snowplow JS (Frontend) tracking -GitLab provides `Tracking`, an interface that wraps the [Snowplow JavaScript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilize tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/product/product-processes/#taxonomy). +GitLab provides `Tracking`, an interface that wraps the [Snowplow JavaScript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilize tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/business-ops/data-team/programs/data-for-product-managers/#sts=Taxonomy). | field | type | default value | description | |:-----------|:-------|:---------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `category` | string | document.body.dataset.page | Page or subsection of a page that events are being captured within. | | `action` | string | 'generic' | Action the user is taking. Clicks should be `click` and activations should be `activate`, so for example, focusing a form field would be `activate_form_input`, and clicking a button would be `click_button`. | -| `data` | object | {} | Additional data such as `label`, `property`, `value`, and `context` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/product-processes/#taxonomy). | +| `data` | object | {} | Additional data such as `label`, `property`, `value`, and `context` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/business-ops/data-team/programs/data-for-product-managers/#sts=Taxonomy). | ### Tracking in HAML (or Vue Templates) @@ -131,10 +131,10 @@ Below is a list of supported `data-track-*` attributes: | attribute | required | description | |:----------------------|:---------|:------------| | `data-track-event` | true | Action the user is taking. Clicks must be prepended with `click` and activations must be prepended with `activate`. For example, focusing a form field would be `activate_form_input` and clicking a button would be `click_button`. | -| `data-track-label` | false | The `label` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/product-processes/#taxonomy). | -| `data-track-property` | false | The `property` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/product-processes/#taxonomy). | -| `data-track-value` | false | The `value` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/product-processes/#taxonomy). If omitted, this is the element's `value` property or an empty string. For checkboxes, the default value is the element's checked attribute or `false` when unchecked. | -| `data-track-context` | false | The `context` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/product-processes/#taxonomy). | +| `data-track-label` | false | The `label` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/business-ops/data-team/programs/data-for-product-managers/#sts=Taxonomy). | +| `data-track-property` | false | The `property` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/business-ops/data-team/programs/data-for-product-managers/#sts=Taxonomy). | +| `data-track-value` | false | The `value` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/business-ops/data-team/programs/data-for-product-managers/#sts=Taxonomy). If omitted, this is the element's `value` property or an empty string. For checkboxes, the default value is the element's checked attribute or `false` when unchecked. | +| `data-track-context` | false | The `context` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/business-ops/data-team/programs/data-for-product-managers/#sts=Taxonomy). | ### Tracking within Vue components @@ -278,7 +278,7 @@ Custom event tracking and instrumentation can be added by directly calling the ` |:-----------|:-------|:--------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `category` | string | 'application' | Area or aspect of the application. This could be `HealthCheckController` or `Lfs::FileTransformer` for instance. | | `action` | string | 'generic' | The action being taken, which can be anything from a controller action like `create` to something like an Active Record callback. | -| `data` | object | {} | Additional data such as `label`, `property`, `value`, and `context` as described in [Instrumentation at GitLab](https://about.gitlab.com/handbook/product/product-processes/#taxonomy). These are set as empty strings if you don't provide them. | +| `data` | object | {} | Additional data such as `label`, `property`, `value`, and `context` as described in [Instrumentation at GitLab](https://about.gitlab.com/handbook/business-ops/data-team/programs/data-for-product-managers/#sts=Taxonomy). These are set as empty strings if you don't provide them. | Tracking can be viewed as either tracking user behavior, or can be utilized for instrumentation to monitor and visualize performance over time in an area or aspect of code. diff --git a/doc/development/telemetry/usage_ping.md b/doc/development/telemetry/usage_ping.md index 771486944c6..87eb3c5234a 100644 --- a/doc/development/telemetry/usage_ping.md +++ b/doc/development/telemetry/usage_ping.md @@ -434,8 +434,6 @@ When adding, changing, or updating metrics, please update the [Event Dictionary' Check if new metrics need to be added to the Versions Application. See `usage_data` [schema](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/db/schema.rb#L147) and usage data [parameters accepted](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/app/services/usage_ping.rb). Any metrics added under the `counts` key are saved in the `counts` column. -For further details, see the [Process to add additional instrumentation to the Usage Ping](https://about.gitlab.com/handbook/product/product-processes/#process-to-add-additional-instrumentation-to-the-usage-ping). - ### 6. Add the feature label Add the `feature` label to the Merge Request for new Usage Ping metrics. These are user-facing changes and are part of expanding the Usage Ping feature. diff --git a/doc/ssh/README.md b/doc/ssh/README.md index 9e8d92c6cd9..1c5654ae96c 100644 --- a/doc/ssh/README.md +++ b/doc/ssh/README.md @@ -215,7 +215,7 @@ Now you can copy the SSH key you created to your GitLab account. To do so, follo If you're using an RSA key, substitute accordingly. -1. Navigate to `http://gitlab.com` and sign in. +1. Navigate to `https://gitlab.com` and sign in. 1. Select your avatar in the upper right corner, and click **Settings** 1. Click **SSH Keys**. 1. Paste the public key that you copied into the **Key** text box. diff --git a/qa/qa/page/profile/accounts/show.rb b/qa/qa/page/profile/accounts/show.rb index eec4efe1734..2cd2d4597dc 100644 --- a/qa/qa/page/profile/accounts/show.rb +++ b/qa/qa/page/profile/accounts/show.rb @@ -11,17 +11,14 @@ module QA view 'app/assets/javascripts/profile/account/components/delete_account_modal.vue' do element :password_confirmation_field - end - - view 'app/assets/javascripts/vue_shared/components/deprecated_modal.vue' do - element :save_changes_button + element :confirm_deletion_button end def delete_account(password) click_element(:delete_account_button) find_element(:password_confirmation_field).set password - click_element(:save_changes_button) + click_element(:confirm_deletion_button) end end end diff --git a/vendor/gitignore/C++.gitignore b/vendor/gitignore/C++.gitignore old mode 100755 new mode 100644 diff --git a/vendor/gitignore/Java.gitignore b/vendor/gitignore/Java.gitignore old mode 100755 new mode 100644 -- GitLab